10

Here is the structure declare code. 

struct list_el {
    int val;
    struct list_el * next;
};

typedef struct list_el item;

And when I write a function like this, the compiler gives a error. It says cur undeclared before first use. 

bool delete(item* item)
{
    assert(item != NULL);

    item* cur = NULL;
    cur = head;
    item* prev = NULL;
    while (cur) {
        if (cur == item) {
            if (prev == NULL) {
                head = item->next;
            } else {
                prev->next = item->next;
            }
            free(item);
            return true;
        }

        prev = cur;
        cur = cur->next;
    }
    return false;
}

After I look up the reference, it says the typedef works out just a bit like #define. It simply makes a substitution at compile time. Is that the reason the code can't be compiled?

Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
Frank Cheng
  • 5,928
  • 9
  • 52
  • 80

5 Answers5

17

In this code:

bool delete(item* item)
{
    item *cur = NULL;

the item in the third line is taken to be the name of the variable item (the parameter to the function), and not the type. Consequently, the third line looks as if it starts out as an expression that multiplies item by the undefined variable cur, which leads to problems; the rest of the expression is also bogus.

If this isn't what you want, don't use the same name for a type and a variable. You'll confuse other people even if you don't confuse yourself and the compiler.

Whichever reference source said that typedef and #define are 'the same' should be dropped from your list of references now! If it can't differentiate two such fundamentally different constructs, it is dangerous because you won't know when it is misleading you (but this is one case where it is misleading you).

Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
  • @Jonathan Leffler `(item* item)` will create compilation error? – Grijesh Chauhan Nov 14 '12 at 07:27
  • 1
    @GrijeshChauhan: It doesn't cause a compilation error under GCC. I'm a little surprised. I think it comes down to scope. There's a new scope with the function definition, and in that scope, the plain name `item` now means the variable. I'm not certain that's how you scrape by, but it looks semi-plausible. You can see it with: `int x = 0; int func(void) { int y = x; int x = y + 1; ... }` which is legitimate. The first `x` in the function is the global variable; the second is a new local variable that shadows the global. The situation in the function in the question is similar, I hypothesize. – Jonathan Leffler Nov 14 '12 at 07:30
  • You are correct, I also checked it myself, And yes due to scope ...also its correct in C but not in Java. : Thanks – Grijesh Chauhan Nov 14 '12 at 07:35
  • You changed your answer!...you wrote something about c99 and c89 – Grijesh Chauhan Nov 14 '12 at 07:36
  • @GrijeshChauhan: I gave an answer to a different problem (and mentioned C89 vs C99). The compiler is stipulated by the tags to be GCC; I was thinking it might be MSVC, in which case `assert()` could not precede a declaration. However, the problem starts before that, and the complaint wasn't about a variable definition appearing where it isn't allowed but about the absence of a variable definition. – Jonathan Leffler Nov 14 '12 at 07:38
  • hi, @JonathanLeffler, gcc will give you a warning if you use `gcc -Wshadow`. Just like my answer in this question. – madper Nov 14 '12 at 07:44
  • Thanks for your answer. @Jonathan Leffler. The book says it like #define but not the same, my mistake. But i am kind of curious about how do you get the reason that the compiler look the item in item *cur as the first parameter. Have you read the source code of gcc? I am not suspecting your answer, just curious. – Frank Cheng Nov 14 '12 at 07:46
  • Basically, because of the error it generated. If it was still treating `item` as a type name, it would be a variable definition (of `cur`). (The code is missing a declaration for `head`, incidentally.) So it was the mere fact that you got the error that tipped me off to what was going on. As I said in an earlier comment, I was a little surprised that the function definition line compiled, but GCC (tested: 4.7.1 on Mac OS X 10.7.5) is quite happy with it, leaving the conclusion I came to as the logical answer to the problem. – Jonathan Leffler Nov 14 '12 at 07:54
2

A typedef is just a new name for an already existing type. defines are handled by the preprocessor while typedefs are handled by the C compiler itself. [copied from this link]

check this question: Are typedef and #define the same in c?

Community
  • 1
  • 1
MOHAMED
  • 41,599
  • 58
  • 163
  • 268
  • Moreover, forcing the compiler to guess from context whether you were referring to an instance of object, or the type name is at the very least a pathetic approach and should not be allowed by the compiler. A little insane example typedef int b; double b; b = 4; - compilation error – fkl Nov 14 '12 at 07:32
1

typedef is not completely same as #define

Here is the difference by example:

#define cptr1 char*

typedef char* cptr2;

In code:

           int main()
            {
             cptr1 c1,c2; // first case : 
        // here c1 will be pointer to char but c2 is only char as cptr 
   // is directly replaced by char* by preprocessor
            cptr2 c3,c4; // second case :
      // here c3 and c4 both are pointers to char 
            }
Omkant
  • 9,018
  • 8
  • 39
  • 59
1

you should use -Wshadow when you compile you code. Then, gcc will tell you where you are wrong. :-) like follows:
declaration of ‘item’ shadows a global declaration [-Wshadow]

madper
  • 806
  • 1
  • 10
  • 25
  • Since i am a newbie to c programming, so should i open as many as warning options in `gcc` as possible? – Frank Cheng Nov 14 '12 at 07:44
  • 1
    @user674199, I think so. you will avoid lots of mistake if you open them. And they will save your debuging time. :-) – madper Nov 14 '12 at 07:46
  • If you're compiling with GCC, as you are, then using `-Wall` will save you from a lot of problems. I use some extra options too — sometimes, but not always, including `-Wshadow`. Because of the retrograde and archaic code I work with, I find `-Wmissing-prototypes -Wstrict-prototypes -Wold-style-definition` useful. I compile with `-Wextra` when I can, but that is a demanding standard of coding; I'd forgive some warnings under `-Wextra` (but very few of the warnings under the other options). Using `-Werror` keeps you honest, too. – Jonathan Leffler Nov 14 '12 at 08:00
1

Jonathan Leffler answered you your question.

I just want to add: if you write your code in c++, you don't need to typedef, so you can implement your list just like this:

struct list_el {
    int val;
    list_el *next;
};

bool delete_element(list_el *item)
{
    list_el *cur = NULL;
    ...
}
kaspersky
  • 3,959
  • 4
  • 33
  • 50