How is this different from a regular #define that's just on it's own? Does containing the #define within the struct definitions means that you can't assign the #define constant to other things besides the struct's members?
I'm talking about something like this:
As opposed toCode:typedef struct STRUCT_NAME { // // some struct member fields. // int a; #define CONSTANT_A 0 . . . // // maybe some more members. // };
Code:#define CONSTANT_A 0 typedel struct STRUCT_NAME { . . . };
As far as I know there's no difference. It's still a precompiler def.
I have no proof though. Other than it wouldn't make any sense and I've never heard of it.
Good class architecture is not like a Swiss Army Knife; it should be more like a well balanced throwing knife.
- Mike McShaffry
A #define only affects everything in the code that's below it in the file (until you reach the end of the file, or a #undef for it). Without looking at a complete example, it's hard to say whether or not it would act the same if you moved the #define to the top of the file.
If you understand what you're doing, you're not learning anything.
You can place a define within a structure declaration. It doesn't have to be special, and you can use it outside of the structure declaration, but it's generally a good idea for the define to be pretty closely related to the structure.
My best code is written with the delete key.
the #define is not limited to file scope. I's valid to the end of the compilation unit ( or up to an #undef ).Originally Posted by itsme86
Kurt
BZZZZZZT!!! Try again. The #define must be part of the file in which you use it (or at least inserted into the file using #include), and it must be be before you use it in that file:
Code:itsme@itsme:~/C$ cat deftest1.c #include <stdio.h> int main(void) { printf("%d\n", MYDEF); return 0; }itsme@itsme:~/C$ gcc -Wall deftest1.c deftest2.c -o deftestCode:itsme@itsme:~/C$ cat deftest2.c #define MYDEF 86
deftest1.c: In function `main':
deftest1.c:5: error: `MYDEF' undeclared (first use in this function)
deftest1.c:5: error: (Each undeclared identifier is reported only once
deftest1.c:5: error: for each function it appears in.)
itsme@itsme:~/C$
Last edited by itsme86; 06-23-2006 at 03:30 PM.
If you understand what you're doing, you're not learning anything.
deftest.c is a different compilation unit
Kurt
But those are separate compilation units, so ZuK's statement stands.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
Well I'm not sure what you mean by "compilation unit", unless you mean file scope plus #included files, which is common sense to me and was implied by statement.
If you understand what you're doing, you're not learning anything.
This example acually calls the compiler twice. once for deftest1.c and once for deftest2.c --> 2 compilation units.Code:gcc -Wall deftest1.c deftest2.c -o deftest
Kurt
Okay then, "compilation unit" was what I originally meant by "file".
If you understand what you're doing, you're not learning anything.
The term used by the C standard is "translation unit".
C89 Draft
A C program need not all be translated at the same time. The text of the program is kept in units called source files in this Standard. A source file together with all the headers and source files included via the preprocessing directive #include , less any source lines skipped by any of the conditional inclusion preprocessing directives, is called a translation unit. Previously translated translation units may be preserved individually or in libraries. The separate translation units of a program communicate by (for example) calls to functions whose identifiers have external linkage, by manipulation of objects whose identifiers have external linkage, and by manipulation of data files. Translation units may be separately translated and then later linked to produce an executable program.
