macOS #define - global or local?

[dantherevelator]

Howdy all.

I'm working through Kochan's book and I've been stymied by a couple sentences in the chapter 12, on the preprocessor. They are on p.240:

"There is no such thing as a local define. After a name has been defined, it can subsequently be used anywhere in the program. Most programmers place their defines inside header files so they can be used by more than one source file."​

Near as I can figure those are in pretty clear conflict with each other. If there's no such thing as a local define, why should it matter where they're located? I looked at the errata but didn't see anything on this. Can anyone help me out a bit?

Many thanks in advance.

 

[iShater]

If you use a define in the header file, any source file that includes that header will be able to use that define.

It is just a way of organizing your code. Not sure where the conflict in that statement is.

edit: I think you are confused because they are putting it in the header file? that is a code organization advice. It doesn't mean the define is LOCAL in scope.

 

[dantherevelator]

Ah. I think I'm on it. So the defines are placed in the header file for organizational and reference reasons--for the benefit of, say, other programmers? Other classes would know about them whether they were shown the header file or not, correct?

 

[notjustjay]

Ah. I think I'm on it. So the defines are placed in the header file for organizational and reference reasons--for the benefit of, say, other programmers? Other classes would know about them whether they were shown the header file or not, correct?

Yes. You can define things in one file, and then include that file in any other file that will need to make reference to what you defined. This is commonly done to set up whatever constants or other definitions you need in just one file, and then include that file in every source file in your project that needs to know about it. If you don't specifically #include the file which contains the #define's, the source file you're compiling won't know about it.

 

[Guiyon]

Ah. I think I'm on it. So the defines are placed in the header file for organizational and reference reasons--for the benefit of, say, other programmers? Other classes would know about them whether they were shown the header file or not, correct?

If I am understanding you correctly, no. For example, take the file "my_constants.h" and three class header/source pairs: class0, class1 and class2. Assume class0.h includes "my_constants.h", therefore it has access to any #defines in that header file. Now say that class1 includes the class0 header file; since class0.h also includes the "my_constants.h" it would also be available to class1.

Assuming class2 has nothing to do with class0, class1 or my_constants.h, it would not be able to use any of the #defines in any of those files.

Edit: A bit more direct (just in case...)
constants.h defines TEST
class0.h includes constants.h
class1.h includes class0.h

Therefore both class0 and class1 can use TEST. Since class2 is nowhere in the include tree, it has no idea TEST even exists.

 

[Sander]

I agree that the wording is a little confusing. I would even phrase it the other way around: There is no such thing as a "global" define! When you #define something, it will be visible to the rest of the compilation unit from that point on. A compilation unit is "everything the compiler gets to see": what's become of your .c file once the preprocessor is done with it (i.e., the .c file with all its #includes and #defines etc.).

Perhaps the book was referring to definitions made as command line options to the compiler. It's one common use of the preprocessor to allow building several different versions of a program from the same source code, for example a "debug" version and a "release" version. You'd then have code snippets like

#ifdef DEBUG
OutputSomeExtraInformation();
#endif

You could then compile a specal debugging version of the program by compiling with something like

gcc -Wall -DDEBUG -o myprogram myprogram.c

However, since the compiler only ever deals with one compilation unit at a time, you still couldn't call this a "global" thing. On the other hand, the compiler switches are usually re-used for every compile step so the point is perhaps a little moot.

I hope I didn't confuse you further...

 

[dantherevelator]

Therefore both class0 and class1 can use TEST. Since class2 is nowhere in the include tree, it has no idea TEST even exists.

I agree that the wording is a little confusing. I would even phrase it the other way around: There is no such thing as a "global" define! When you #define something, it will be visible to the rest of the compilation unit from that point on.

Thank you. I just wrote a little test case that demonstrated this is so, which is what I should have done at the outset. I wonder why Kochan even broached the subject, as this is the behavior I would have expected anyways.

Thanks again everyone.

 

[skochan]

Haha! Boy, I didn't mean to cause such a stir from a couple of sentences.

What I was trying to say (obviously not well) was that unlike variables, if you write a #define inside a function, it doesn't matter. It's not local to that function. It can be used anywhere subsequent in that file after that #define appeared.

Cheers,

Steve Kochan

 

[dantherevelator]

Ah, of course. Thanks or the clarification, Steve. Love the book--aside from this one sticky spot, that is.