global variable confusion

[agentsmith]

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <ctype.h>
#include <time.h>

#define LEN 20		/* word array size */
#define HASHSIZE 12289		/* hash table size */

typedef struct L { char k[LEN]; struct L *next; } List;		/* list element */

struct hash_list { char *word; struct hash_list *next; } hash_list;		/* hash table element */

does defining LEN and HASHSIZE like that make them global variables?? i don't think it does but i am not sure

[Aia]

They are not variables at all. They are pre-process directives. You can considerate them as constant values.

[dwks]

When the processor sees a line beginning with '#'[1], it processes the command on that line. The preprocessor can do quite a few different things. For example, when it sees "#include <stdio.h>", it opens the file stdio.h and puts that data verbatim into your program where the #include statement was.

When it sees a #define statement, it basically does a search-and-replace throughout your source code for that identifier. (It doesn't substitute inside strings, but otherwise it's basically S&R.) This means that #define values can be anything, not just ints or whatever:

#define SEMICOLON ;
#define TRICKYCODE do { puts("tricky); } while(0)

The bad thing about #defines is that they have no concept of scope or semantic meanings. If you use something like this by accident

#define X 10

int X = 10;

the compiler will see

int 10 = 10;

and you'll get a nasty, likely indecipherable error.

I prefer to use the enum-hack and/or const-ant values myself.

[1] The first non-whitespace character on the line must be a '#'.

[grumpy]

That depends on how you use them, Aia. In reality they are not constants: they are macros that happen to expand to particular text. After the macro is #defined, the preprocessor substitutes every instance of the macro name (eg LEN) with it's replacement text.

In agentsmith's example, there are no constants or variables named LEN or HASHSIZE seen by the compiler.

For example, the typedef that declares List is effectively seen by the compiler as;

typedef struct L { char k[20]; struct L *next; } List;

Unlike a declaration of a constant, a macro can be redefined. For example;

int main()
{
#define LEN 20
    int a[LEN];

#undef LEN
#define LEN 50
    int b[LEN];

    for (i = 0; i < LEN; ++i)  a[i] = 42;
    return 0;
}

will declare a to be an array of 20 elements and b to be an array of 50 elements. The loop also invokes undefined behaviour becase it sets 50 elements of the array a, which only has 20 elements.

[Bleech]

The bad thing about #defines is that they have no concept of scope or semantic meanings. If you use something like this by accident

#define X 10

int X = 10;

the compiler will see

int 10 = 10;

and you'll get a nasty, likely indecipherable error.

I prefer to use the enum-hack and/or const-ant values myself.

[1] The first non-whitespace character on the line must be a '#'.

indeed, be careful when using #define with typedef, as they appear to be handled in the same way by the preprocessor (at least, with MSVC). about a month ago I was stumped with a hard to find error because of this. if you typedef a new type with the name of a constant that you didn't want to #define, you might end up with some unexpected results.

[dwks]

Actually, what happens is that the preprocessor does a search-and-replace over everything, including typedef names and variables and functions and all other identifiers.

Preprocessor directives such as macros are handled by the preprocessor, which is typically separate from the compiler proper. Typedefs are handled by the compiler itself, like enums. This is why they're preferable: the compiler can give you proper errors for misusing these types, and the compiler can even store relevant debugging information into a program such that the debugger can access this information as well. enum values are a sight for sore eyes in a debugger compared with literal numbers. And have you ever tried debugging a macro, especially a really, really long one? Ouch.

[esbo]

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <ctype.h>
#include <time.h>

#define LEN 20		/* word array size */
#define HASHSIZE 12289		/* hash table size */

typedef struct L { char k[LEN]; struct L *next; } List;		/* list element */

struct hash_list { char *word; struct hash_list *next; } hash_list;		/* hash table element */

does defining LEN and HASHSIZE like that make them global variables?? i don't think it does but i am not sure

Firstly as has been said they are not variables, they are definition of a value, hence the name #def (define as).

Mind you do bring up an issue of the scope of the definition, whether it is local to the file it is in or global.

I mean you could define LEN as 20 in one FILE and then define it as 999 in another file!!
(at least I think you can anyway, if you compile them seperately, although it is more normal to put definitions like that in a header file and include that in each file to have a 'global' definiton. I think it would work if you compile them seperately then link them later, eitherway I am sure the compiler/linker will let know if it has a problem with it!

Usually all my code is in one file so I don't have to think about such things but I have worked on a project where finding which definitions to include is harder than writing the code!!

You can end up including everything!!!

This is my opinon, I am not a C compiler.

[Elysia]

I mean you could define LEN as 20 in one FILE and then define it as 999 in another file!!

You could do that if one variable was global and one was local (or both are local), or if one or two of them were defines.
Otherwise you end up with a linking error.

[dwks]

Well, not exactly. You can have static global variables, which are limited to the scope of a file. You could have one of these variables of the same name in two different source files.

[Elysia]

Oooh, another exception. We like exceptions, don't we?

[dwks]

Eh, you want pedantic definitions?

You could do that if one variable was global and one was local (or both are local), or if one or two of them were defines.

It would work with two local variables of the same name, it's true, but not two local variables with the same name in the same scope. Then you get a compiler error, "`foo' redefined" or some such, not a linker error.