Public Group

# explain #define _SYSTEM_H_ please!

This topic is 4301 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

hello, I landed at the gamecore chapter in my book (programming RPG's with DirectX), and I came across some code I've never heard of. And after searching on google, cprogramming.com and other forums I still didn't know what it meant. So, now I'm asking what it does hére. Here is it:
// file: system_core.h //

#ifndef _SYSTEM_H_
#define _SYSTEM_H_

// some modular classes, to derive from //

#endif


As long as I know, you don't need to define modular classes or something. And please don't link me to any site, unless it explains the _SYSTEM_H_ too, cuz I've seen those enough[grin]. -Stenny

##### Share on other sites
Here it's basically saying: "If _SYSTEM_H_ is not defined, then define it, and the classes that are inside this if statement."

Nothing special. [lol]

##### Share on other sites
Check the #include guard article on Wikipedia for more information.

##### Share on other sites
Its a preprocessor directive ([google] term) that basically tells the compiler that "if this file has already been included, don't include it again."

If this were not set, you would probably get linker errors saying that certain symbols had been defined twice. Some newer compilers, such as Microsoft Visual C++ 2005, have the same thing with a #pragma once directive, which basically does the same thing. The only difference is that the version you posted will work on all standards compliant C++ compiler.

##### Share on other sites
this is most often used to prevent cyclical include errors (if a file is included multiple times, then you will have redefinition errors).

Microsoft has their own way of doing this (exclusive to Visual Studio as far as I know) using a preprocessor command #pragma once

EDIT: Wow, 3 replies before I got done? Damn you guys are getting good.

##### Share on other sites
Ok! Thank you all! :)

-Stenny

##### Share on other sites
You should also note that all names starting with __ or _ followed by an uppercase letter is reserved for the implementation (see 17.4.3.1.2 in the C++ standard), therefore your compiler is allowed to use _SYSTEM_H_ for something else. All names starting with _ in the global namespace or the std namespace is also reserved.

##### Share on other sites
Quote:
 Original post by CTarYou should also note that all names starting with __ or _ followed by an uppercase letter is reserved for the implementation (see 17.4.3.1.2 in the C++ standard), therefore your compiler is allowed to use _SYSTEM_H_ for something else. All names starting with _ in the global namespace or the std namespace is also reserved.

Reserved? Wow, didn't know this. Could you please explain it a little more? I read the part your talking about, but I didn't quite understand what it was saying.

##### Share on other sites
Quote:
Original post by MikeTacular
Quote:
 Original post by CTarYou should also note that all names starting with __ or _ followed by an uppercase letter is reserved for the implementation (see 17.4.3.1.2 in the C++ standard), therefore your compiler is allowed to use _SYSTEM_H_ for something else. All names starting with _ in the global namespace or the std namespace is also reserved.

Reserved? Wow, didn't know this. Could you please explain it a little more? I read the part your talking about, but I didn't quite understand what it was saying.

It's a convention, that is, an implicit agreement. It means that in your code you shouldn't use underscores as prefixes to variable names, preprocessor macro names and so on. If you do, it's likely that your code will still compile, it just won't be in accordance with the standard. In general it's not a good habit to get into.

Now, iirc, the standard doesn't say anything about using underscores as suffixes.

##### Share on other sites
Woah wait... sorry, I don't mean to lead this thread in another direction, but I'm still talking about defining macros (and specifically include guards), so I think its still ok to ask in this thread.

Quote:
 ISO/IEC 14882:1998(E) -- C++ -- Library introduction17.4.3.1.2 - Global names [lib.global.names]-1- Certain sets of names and function signatures are always reserved to the implementation: Each name that contains a double underscore ("__") or begins with an underscore followed by an uppercase letter (lex.key) is reserved to the implementation for any use.Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace.*

I don't know what they mean to by "the implementation", but I'll guess its the STL. So does this mean that everything starts with _ and __ are not following the standard? If so, that sucks, cause everything I've seen would be breaking the standard then.

• 17
• 10
• 19
• 14
• 19