Posts by deceptikon

I quote each on in a single post, in the order that they appeared.

You can quote one of three ways:

1. Select the text you want to quote and click inside the reply box. The text will be pasted and quoted automagically.
2. Manually paste the text with a Markdown quote tag.
3. Use the quote button on the reply editor.

The easiest is the auto-quote, but it's kind of quirky right now. It takes some getting used to. ;)

Allow me to deconstruct the code into what I believe are the relevant lines:

CImg <float> inImage(inputImage, image_width, image_height);
float *WrappedImage, *UnwrappedImage;
WrappedImage = inImage;
free(WrappedImage);

If CImg handles its memory internally as one would expect, I see nothing good coming out of that call to free().

You're overrunning the end of the array in the sorting algorithm. The inner loop should stop at 8 rather than 9, because inside the loop you're referencing the index at i + 1.

That's a good point deceptikon, do you have a solution?

The OP's exact needs aren't clear, so I'm not confident in offering a concrete solution, but in general for something like this I'd favor wrapping the tediousness inside an object. Something like a matrix class or nested vectors.

Is that vague enough? :D

How about making a temporary 3 x 4 array, initialize it as you have done, then in your for loop, do a memcpy of the 3 x 4 array to the address of element array[T][0][0]?

That's fine for arrays of built-in types, but if you're working with a non-POD type then memcpy() is an exceptionally bad idea because it invokes undefined behavior.

Perhaps point 2 answers that question?

That would be my guess. But that information is also incredibly useful in dealing with spammers and other less savory types. I can't imagine how difficult those spam attacks under vBulletin would have been without that feature.

That totals to 5,978,160 bytes (assuming 8-byte double). Not horrible, but something to think about, especially if you can devise a way to avoid keeping all of those values in memory if you don't really need them.

Now to answer your question:

1. Yes.
2. God yes. Doing this manually is uber painful.

3. Read the following at your own risk:

   #include <vector>
   
   using namespace std;
   
   typedef vector<double> vec1d;
   typedef vector<vec1d> vec2d;
   typedef vector<vec2d> vec3d;
   typedef vector<vec3d> vec4d;
   
   int main()
   {
       vec4d v(115, vec3d(4, vec2d(114, vec1d(114))));
   
       for (int i = 0; i < 115; ++i)
       {
           for (int j = 0; j < 4; ++j)
           {
               for (int x = 0; x < 114; ++x)
               {
                   for (int y = 0; y < 114; ++y)
                   {
                       v[i][j][x][y] = 0.0;
                   }
               }
           }
       }
   
       // ...
   }
   

Reading a delimited file can be super easy or somewhat tricky depending on the format. If you're doing something super basic where the delimiter isn't allowed to be embedded in field data, it's almost trivial:

#include <fstream>
#include <iostream>
#include <iterator>
#include <sstream>
#include <string>
#include <vector>

namespace file_management
{
    using namespace std;

    vector<string> read_fields(istream& in, char delimiter)
    {
        vector<string> fields;
        string line;

        if (getline(in, line))
        {
            istringstream iss(line);
            string field;

            while (getline(iss, field, delimiter))
            {
                fields.push_back(field);
            }
        }

        return fields;
    }
}

int main()
{
    using namespace file_management;
    using namespace std;

    ifstream in("test.txt");

    if (in)
    {
        vector<string> fields;

        while (fields = read_fields(in, '\t'), !fields.empty())
        {
            for (int i = 0; i < fields.size(); ++i)
            {
                cout << '"' << fields[i] << '"' << (i < fields.size() - 1 ? ", " : "\n");
            }
        }
    }
}

If embedded delimiters are allowed, such as with the full CSV format, then you need to do a bit more parsing to handle the escape sequences.

i have gone through some books and sites but, the explanation is very complex......:(

Try this one.

Rather than list out everything I did, I'll just post the code:

#include <stdio.h>
#include <stdlib.h>

typedef struct tree {
    int data;
    struct tree *right, *left;
} TREE;

TREE *insert(TREE *, int);
TREE *findmax(TREE *);
void order(TREE *);
void structure(TREE *root, int depth);

int main() {
    TREE *root = NULL; 
    int option, element, n, i;
    do {
        printf("\n       1-Create a Binary Search Tree");
        printf("\n       2-Order");
        printf("\n       3-Find Largest");
        printf("\n       4-Tree Structure");
        printf("\n       5-Quit\n");
        scanf("%d", &option);
        switch (option) {
        case 1:
            root = NULL;
            printf("\nEnter n number of nodes\n");
            scanf("%d", &n);
            for (i = 1; i <= n; i++) {
                printf("\nEnter a number for node %d\n", i);
                scanf("%d", &element);
                root = insert(root, element);
            }
            printf("\nBinary Search Tree with %d nodes created\n", n);
            break;
        case 2:
            printf("\nOrder\n");
            order(root);
            break;
        case 3:
            printf("\nFind Largest\n");
            printf("%d\n", findmax(root)->data);
            break;
        case 4:
            printf("\nTree Structure\n");
            structure(root, 0);
            break;
        case 5:
            printf("\nQuitting...\n");
            break;
        default:
            printf("\nError\n");
            break;
        }
        printf("\n\n\n");

    } while (option != 5);
}

TREE *insert(TREE *root, int element) {
    if (root == NULL) {
        root = (TREE *) malloc(sizeof(TREE));
        root->left = root->right = NULL;
        root->data = element;
        return root;
    } else {
        if (element < root->data)
            root->left = insert(root->left, element);
        else if (element > root->data)
            root->right = insert(root->right, element);

        return (root);
    }
}

TREE *findmax(TREE *temp)
{
    if(temp==NULL || temp->right==NULL)
        return temp;
    return findmax(temp->right);
}

void order(TREE *root) {
    if (root != NULL) {
        order(root->left);
        printf(" %d ", root->data);
        order(root->right);
    }
}

void structure(TREE *root, int depth) {
    int i;

    if (root == NULL) {
        for …

I work for a consulting firm rather than freelance, but technically the work is still contract. So....

1. We charge the same base hourly rate across the board, with business and after hours charges for support.
2. Work is work. As long as you can show a steady stream of contracts as opposed to sporadic contracts, I wouldn't look down on a span of contract work.
3. This is outside of my experience, but I wouldn't imagine that being a sole proprietor would be terribly risky as long as you have a lawyer draw up or review your contracts. The important part of liability is knowing when to take the reigns/make decisions and when to step back and allow others to take the risks.
4. Prospective employers should understand that there may be a poor fit in the mix. The real red flag is a lot of short term permanent jobs on your resume. This suggests a job hopper who's more of a drain on the company's resources.

Makes a change from when it was all the C/C++ people :)

I'm curious to see what kind of attitude shift will result from this. The C/C++ folks can be a nasty and unrelenting bunch (*cough*Narue*cough*). ;)

I just asked for a link for these so-called federal guidelines.

That's fine, and to ensure that you get exactly what you asked for, I'm leaving the answer to the person who has all of the specifics.

I also asked for something reasonable: an explanation of exactly what bothers you so much about our policy.

I'll defer to Dani for quoting chapter and verse of the laws.

But since we're now demanding things, I'd like to know what part of the information we keep rustles your jimmies so much. Looking at the terms of service (noting also that you don't have to register to read the TOS) you'll find this clause:

To comply with federal anti-spam guidelines, DaniWeb stores the registration email address, current email address, all IP addresses used to register with and post, date of registration, and date last visited of all members as confirmation and proof of opt-in status.

Now let's make a happy little list of the pieces of information so that you can more easily explain exactly how each one is objectionable:

1. Registration email address
2. Current email address
3. All IP addresses used to register and post
4. Date of registration
5. Date of last visit

For the record, you can change your current email address from your profile edit page. The registration email must be valid to complete registration, but it's otherwise unused and serves only as proof that you requested an activation email.

Tested, confirmed, fixed, and pushed to staging. It should make it to production today or tomorrow. Thanks for the report. :)

What operating system are you using? I'm running Chrome on Windows 7 64-bit and selection seems to work as expected.

I feel like being forced. Not a good feeling.

Forced into what, exactly? Pretty much the only "personal" information we keep that can't be explicitly changed in your profile is registration IP address. We just added a feature wherein members can even change their name without the help of an admin, so I fail to see how there's a problem with retaining accounts. If you're worried about personal information, just edit it all away: we don't store profile change history.

And if you're worried about your IP address identifying you, you should either be behind an anonymous proxy, or abstain from internet activity. ;)

The end result looks like this:

Input number: 34
array[0] = 34

Input number: 23
array[0] = 34
array[1] = 23

...
and it keeps going until your desired break loop condition.

That seems like a situation where a linked list is better suited than a dynamic array.

The problem I have with the funcion, is that I am unable to read the "Float" and "Double" type parameters

Varargs are always promoted, so there's no such thing as a float type parameter. That's your biggest problem: instead of trying to extract an object of type float, you need to look for type double. You'll notice that printf() works the same way; there's not a specifier for float, all of the ones that mention floating-point work with double.

Here's the code cleaned up a little bit and fixed:

#include <stdio.h>
#include <stdarg.h>
#include <stdlib.h>
#include <string.h>

char* convert(unsigned int, int);
void echo(char*,...);
void ftoa(double Fnum);

int main()
{
    int i=65;
    float k=5.75;
    char str[]="This is my string";

    echo("Message = %f", k);

    return 0;
}

void echo(char* fmt, ...)
{
    char* p = fmt;
    int i;

    va_list argp;
    va_start(argp, fmt);

    for (; *p != '\0'; ++p)
    {
        if (*p != '%')
        {
            putchar(*p);
            continue;
        }

        switch (*++p)
        {
            case 'c':
                putchar(va_arg(argp, char));
                break;
            case 'd':
                i = va_arg(argp, int);

                if (i < 0)
                {
                    i = -i;
                    putchar('-');
                }

                puts(convert(i, 10));
                break;
            case 's': 
                puts(va_arg(argp, char*));
                break;
            case 'f': 
                ftoa(va_arg(argp, double));
                break;
            case '%':
                putchar('%');
                break;
        }
    }

    va_end(argp);
}

char *convert(unsigned int num, int base)
{
    static char buff[33];
    char *ptr;

    ptr=&buff[sizeof(buff)];
    *ptr='\0';

    do
    {
        *--ptr="0123456789"[num%base];
        num/=base;
    }
    while(num!=0);

    return(ptr);
}

void ftoa(double Fnum)
{
    int wholeNum=Fnum;
    int decimalNum=((Fnum - wholeNum) * 10000000);
    char wholeNumStr[13];
    char decNumStr[13];
    char numStr[13];

    itoa(wholeNum, wholeNumStr,10);
    itoa(decimalNum, decNumStr,10);
    strcpy(numStr, wholeNumStr);
    strcat(numStr, …

I just checked the code, and backslashes are indeed an explicit escape character, so I guess there's no problem openly recommending their use for the rare cases where you don't want Markdown tags to be processed.

I think the sql use case was a fair point (SOS and myself).

My bad, I totally missed that example.

So from what I read, Deceptikon needs to confirm the backslash for escaping purposes

Yup.

not our job to second guess the needs of the poster, right?

Actually, it is our job as developers. ;) Sometimes there's a way to do what's wanted without adding a new feature. Sometimes a new feature is needed but what the poster requests isn't an optimal solution to the problem. By "second guesing", we can verify what the real needs of the poster are and act accordingly.

In particular, while I'm definitely going to see if the backslash is an explicitly allowed escaping mechanism and not just something that falls out of the parser, I have no intention of adding a new feature until I'm confident that the new feature is truly needed and how best to implement it given use cases (that both I and Dani have asked for in this thread...still waiting).

Fair enough, though coming from a C and C++ background I find it odd that C# would scare you more than C++. ;)

Well.. m sorry to go against what u just said zeroliken, but it isnt undefined... Its how the prefix and postfix operators work..

Nope, it's definitely undefined because i is modified more than once between sequence points. The commas in a function call don't count as sequence points.

Try this and this should give u the output as 1,2,3.

Undefined behavior includes doing what you expect, so empirical "it works for me" evidence is completely worthless. In the case of undefined behavior, we must refer to what the language standard says.

As mentioned, I'm not in a position to check the code presently (but I will be come Monday). If there's not any blessed method in our current version of extended Markdown to disable parsing of a "tag", I can work on adding that capability.

Try calling perror() after fopen(). I notice you're not checking to see if the file was successfully opened before trying to read from it.

But note that T** is not a compatible type with T[M][N], so a function expecting the former will not accept an object of the latter.

Dev-C++ uses MinGW as the back end (by default), which ultimately means you're using the GCC compiler. GCC doesn't support clrscr() at all even though MinGW's version of GCC does support getch() after a fashion. Typically, you can only find clrscr() on Borland compilers, so even if the OP includes <conio.h>, it still won't work.

42

Why do you hate C#?

how do you prefer your code ?

I'm a code aestheticist, so beauty comes a close second to function. Typically I favor transparent code rather than comments because comments tend to make the code uglier unless you do it well. I like consistency (such as indentation and general code style stuff) and balance (one long line in a file full of short lines chafes, for example).

Honestly, I think that if you're worried about the structure of your code, being consistent and balanced is a fantastic start toward writing "pretty" (aka. readable) code.

You're getting that error because pointers aren't magic. If you want a pointer to point to N bytes of memory, you must ensure yourself that the memory exists and assign the base address of that memory to the pointer.

The specific problem here is that you're using uninitialized pointers as the destination objects for scanf(). scanf() expects there to be sufficient memory (which in and of itself is problematic with the %s specifier and no field width) when no such memory exists.

erik's suggestion will work, though it will certainly lead to that problem I mentioned briefly concerning %s without a field width. Alternatively you can allocate memory to the pointers with malloc(). However, I think a better solution would be using "large" buffers to hold each string and then allocate just enough on a case by case basis:

char login[1024];
char pwd[1024];

while (fscanf(fp, "%1023s[^=]=%1023s\n", login, pwd) == 2) {
    user[u].login = strdup(login);
    user[u].pwd = strdup(pwd);
    ++u;
}

I made a few changes:

1. Each %s is now given a field width to ensure that buffer overflow doesn't occur.
2. Instead of testing for EOF, I test for 2 (the number of expected matches) to account for formatting errors in the file.
3. Two input buffers are used instead of the destinations at user[u]. Then user[u] is filled in using the non-standard strdup().
4. A minor nit: while it's unlikely to make a difference, prefix increment is conceptually faster and more intuitive.

Since strdup() is a non-standard function, here's an …

I'm not sure the backslash is an "official" solution. Unfortunately I'm not in a place where I can peruse the code at the moment, but I don't recall any provisions in the parser for such a thing, so it may simply be an unintended feature that could potentially go away after upgrades.

If I may ask, what's the use case for no parse here? Is it still the auto-linkification of URLs or something different?

And now for the obligatory question: why do you think you need to clear the screen? There are only a handful of reasons where it makes sense outside of a GUI environment, and quite a few reasons why it's a bad idea in a textual environment (the kind of environment where clrscr() accomplishes anything meaningful).

Here are a couple of good ones:

1. Clearing the screen also clears the output from previous programs. The implcit assumption that your program owns the output window is not safe. Nothing kills a user's interest in a program you wrote like anti-social behavior.

2. Clearing the screen is inherently non-portable. If you can get away with an interface that doesn't require a non-portable solution, the task of porting your code can be simplified. And there's a side benefit of not having to hear purists (such as yours truly) rail on about lack of portability when you discuss your code in places like Daniweb. ;)

For future reference, errors and warnings are not synonymous. Errors must be fixed because they halt compilation. Warnings can be ignored, though in some cases they suggest problems that are likely to occur at runtime.

Since your compiler clearly supports the modern headers, it's recommended that you use them.

It's not "working". When you lie to printf() you invoke undefined behavior, which could result in a seemingly valid value being printed.

Posts are retained forever unless they break the rules and are subsequently deleted. As for how long it takes to get a response, it very much depends on the nature of the question and the forum. Some forums are very active while others are less so.

If you don't get answers promptly, it could be because nobody knows the answer, nobody has time to answer, your question wasn't clear, or not many people have seen it yet. I notice you posted a question in the C forum, which is fairly active. You've also got a reply to that thread asking for clarification. ;)

Not that we can tell. The over 200 with a huge portion being spambots was before migrating to the new system.

I'm asking because the second one returns an error,but I don't get why.

You should study up on pointers, because I sense a lot of confusion. Here's a tutorial that will get you started.

Cool story, bro.

Am I correct in inferring that you don't want that to happen? Because you neglected to ask any kind of question.

What I need is to pass that pointer when I call the function above as void** the way you suggested.

As I said, void** is not generic. Given my previous example and your added information, you would do this:

void* p = a; // Create a pointer to void
functionName(&p); // Pass its address to create a void**

But at this point I'd question your use of void** in the first place when you're clearly not working with a pointer to void.

void* p; // Create a pointer to void
functionName(&p); // Pass its address to create a void**

Note that a void** isn't generic like void*, so you can't pass the address of a char* or int* when void** is expected.

The initialization is fine; the problem is a typo in your printf() calls. The closing paren is misplaced. Try this instead:

printf("%d\n", p[0].var1);
printf("%d\n", p[0].var2);
printf("%d\n", p[0].var3);
printf("%d\n", p[0].var4[0]);
printf("%d\n", p[0].var5);
printf("%d\n", p[0].var6);

Ok, that's a lot of stuff you haven't done. How about picking just one feature to work on? Taking an overwhelming project and breaking it down into manageable pieces is one of the skills a developer needs to learn. It's especially easy to do when there are multiple largely independent features.

Let's start by working on the find feature, since modify depends on it. Do you know how to loop through an array of objects and test for a matching data member? The basic algorithm is like so for names:

int find_entry(string const& search_key)
{
    for (int x = 0; x < size; ++x)
    {
        if (entry[x].name == search_key)
        {
            return x;
        }
    }

    return -1;
}

As you can probably imagine, it's kind of tedious like that when there are many possible data members. There's a way to get around that, but it's somewhat advanced. In case you're interested, the solution is a pointer to member:

#include <iostream>
#include <string>

using namespace std;

struct Contact
{
    string name;
    string address;
};

int find_entry(Contact entry[], int size, string Contact::*field, string const& search_key)
{
    for (int x = 0; x < size; ++x)
    {
        if (entry[x].*field == search_key)
        {
            return x;
        }
    }

    return -1;
}

int main()
{
    Contact entry[] =
    {
        {"a", "b"},
        {"c", "d"}
    };

    cout << find_entry(entry, 2, &Contact::name, "c") << '\n';
    cout << find_entry(entry, 2, &Contact::name, "a") << '\n';
    cout << find_entry(entry, 2, &Contact::name, "q") << '\n';

    cout << find_entry(entry, 2, &Contact::address, "b") …

it's pity, by the way, who can help me with this problem?

Well, you could debug the code yourself. Or you could write your own BST instead of nicking one that's highly likely to be buggy.

Here's a tutorial with tested code that you can learn from (and steal, since it's all public domain). If you still have issues, I'd recommend starting a new thread with specific questions and noting any errors you're getting to help others help you.

What kind of help do you want? Simply posting an assignment verbatim without any evidence of thought or effort on your part is against Daniweb's rules. But I'll give you the benefit of the doubt and kindly request that you ask a specific question and prove that you've made some kind of attempt at doing this assignment.

volscolts16 hasn't visited Daniweb for 2 years. You're not likely to get any answer in this thread.

Ok, you've said the same thing three times now, but that's not what I want to know.

• Why does that part need to be in a loop?
• What is this program meant to accomplish?
• What do res1, res2, and res3 represent?
• Do you intend to have more than 3 results?
• What are c, d, and e meant for?

Your code has no comments, you didn't post any assignment requirements, and didn't explain what the program actually does. Without knowing all of these things, there's really no way I can help you add a loop, because I have no idea what the loop is supposed to do.

It seems to me that the biggest issue here is the contents of the file being any possible type. C doesn't do dynamic typing very well, so at the very least you'll want to pare the problem down by selecting supported types and devising a file format that supports easy parsing. For example:

# Test file
I   1
S   this is a test
F   123.456

Then parsing the file is almost trivial:

#include <stdio.h>
#include <string.h>

#define DEBUG 1

typedef struct Record
{
    char type;
    char value[BUFSIZ];
} Record;

int main(void)
{
    FILE* in = fopen("test.txt", "r");

    if (in)
    {
        char line[BUFSIZ], fmt[BUFSIZ];

        sprintf(fmt, "%%c %%%ds", BUFSIZ);

        while (fgets(line, sizeof line, in))
        {
            char type, value[BUFSIZ];
            Record rec;

            if (line[0] == '#')
            {
                continue;
            }

            if (sscanf(line, fmt, &type, value) == 2)
            {
                rec.type = type;
                strcpy(rec.value, value);
            }

#if DEBUG
            printf("Created record: {'%c', \"%s\"}\n", rec.type, rec.value);
#endif

            // Add the record to a collection for later use
        }

        fclose(in);
    }

    return 0;
}

The key here is that I'm storing the value as a string and taking note of its type. This way the value can later be converted to its corresponding type as necessary, without having to jump through hoops to store the value in its actual destination type.

though I have yet to learn how to do nested lists

You'll do a facepalm when I say this, but it's as simple as indenting the nested list by any amount.

• adsf

  • qwer
  • qwer

• asdf

  1. qwer
  2. qwer
• asdf

Since the OP found the problem but didn't explain what happened for readers of this thread, allow me:

int total[SIZE];
printf("%d",total);

The %d specifier expects an integer value, yet an unadorned total is equivalent to &total[0]. Thus the argument tied to %d is a pointer to int rather than an int, and the compiler is warning that it's probably not what the programmer wanted.

The total array was also not initialized, so trying to print any of it's elements is undefined behavior. Perhaps the OP wanted scanf() instead of printf(), but that's not a safe bet due to the use of fflush(stdout).

All in all, I'm not sure what the purpose of this function is, and that information is necessary to truly fix the problems.