Need clarification on #ifndef #define

Question

The code I am working has multiple headers and source files for different classes face.cc, face.hh, cell.cc, cell.hh edge.cc edge.hh and the headers contain includes like this,

#ifndef cellINCLUDED
#define cellINCLUDED

#ifndef faceINCLUDED
#define faceINCLUDED

I saw through http://www.cplusplus.com/forum/articles/10627/ and saw the way to write include guard is

#ifndef __MYCLASS_H_INCLUDED__
#define __MYCLASS_H_INCLUDED__

So in above code that I am working on, does compiler automatically understands it is looking for face.hh or cell.hh files?

better question : Is writing __CELL_H_INCLUDED__ same as cellINCLUDED ?

It's not clear what the macro definitions have to do with your question. The macros are used to avoid including the same header twice (this is now deprecated in favour of `#pragma once`). Please clarify what you want to know. — trojanfoe, Apr 25 '16 at 09:17
sorry. my question is quite basic. I am just reading up on this thus I am confused on if `cellINCLUDED` works same as `_CELL_H_INCLUDED_` — jkhadka, Apr 25 '16 at 09:19
Yes it does. The only requirement is that the macro is unique. The recommended system is better, I would say. — trojanfoe, Apr 25 '16 at 09:20
Do not use double underscores. http://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier — Benjamin Lindley, Apr 25 '16 at 09:26

score 3 · Accepted Answer · edited May 23 '17 at 12:07

#ifndef __MYCLASS_H_INCLUDED__
#define __MYCLASS_H_INCLUDED__
So in above code that I am working on, does compiler automatically understands it is looking for face.hh or cell.hh files?

No, the compiler doesn't automatically understand what you mean.

What really happens is that, when compiling a translation unit, the Compiler holds a list of globally defined MACROs. And so, what you are doing is defining the MACRO __MYCLASS_H_INCLUDED__ if it doesn't already exists.

If that macro is defined, that #ifndef until #endif will not be parsed by the actual compiler. Hence you can test for the existence of that MACRO to determine if the Compiler has parsed that header file to include it once and only once in the translation unit... This is because the compiler compiles each translation unit as one flattened file (after merging all the #includes)

See https://en.wikipedia.org/wiki/Include_guard

Is writing __CELL_H_INCLUDED__ same as cellINCLUDED ?

Yes it is.... The reason some prefer using underscored prefixed and suffixed MACROs for include guards is because they have extremely low probability of ever being used as identifiers... but again, underscore could clash with the compiler...

I prefer something like this: CELL_H_INCLUDED

If you use cellINCLUDED, there are chances that someday, somebody may use it as an identifier in that translation unit

You shouldn't prefer using underscores, especially not leading underscores(followed by capital letters) and double underscores, since those are reserved for the implementation. If you want a macro that's extremely unlikely to be used as an identifier, append a GUID to it. Or if you don't have easy access to a GUID generator, append the date and time to it. It's not like you have to remember it. — Benjamin Lindley, Apr 25 '16 at 09:44
hey @WhiZTiM thanks for the elaborate description. I see that I had holes in my understanding of macros, now I know better :) also I had not gone through the wikipedia article on include guard that you linked. it was also quite helpful. thanks again :) — jkhadka, Apr 25 '16 at 11:46

score 1 · Answer 2 · answered Apr 25 '16 at 09:24

The preprocessor definitions have no special meaning. The only requirement is that they stay unique across the modules, and that's why the file name is typically a part of them.

In particular, the mechanics for preventing double inclusion aren't "baked in" the language and simply use the mechanics of the preprocessor.

That being said, every compiler worth attention nowadays supports #pragma once, and you could probably settle on that.

score 0 · Answer 3 · answered Apr 25 '16 at 09:24

As the link you have referenced says, "compilers do not have brains of their own" - so to answer your question, no, the compile does not understand which particular files are involved. It would not even understand that '__cellINCLUDED' has anything conceptually to do with a specific file.

Instead, the include guard simply prevents the logic contained between its opening #ifndef and closing #endif from being included multiple times. You, as the programmer, are telling the compiler not to include that code multiple times - the compiler is not doing anything 'intelligent' on its own.

score 0 · Answer 4 · answered Apr 25 '16 at 09:27

Nope, This is essentially telling the compiler/parser that if this has already been put into the program, don't puthave already been loaded.

This should be at the top (and have an #endif at the bottom) of your .h file.

Lets say you have mainProgram.cpp and Tools.cpp, with each of these files loading fileReader.h. As the compiler compiles each cpp file it will attempt to load the fileReader.h. unless you tell it not to it will load all of the fileReader file in twice.

ifndef = if not defined

so when you use these (and the #endif AFTER all your code in the .h file) you are saying:

if not defined: cellINCLUDED
then define: cellINCLUDED with the following code:
[code]
end of code

so this way when it goes to load the code in your .h file a second time it hits the if not defined bit and ignores the code on the second time.

This reduces compile time and also means if you are using a poor/old compiler it isn't trying to shove the code in again.

Need clarification on #ifndef #define

4 Answers4