// file: system_core.h //
#ifndef _SYSTEM_H_
#define _SYSTEM_H_
// some modular classes, to derive from //
#endif
explain #define _SYSTEM_H_ please!
Author
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:
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
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]
Nothing special. [lol]
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.
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.
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.
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.
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.
Quote:Original post by CTar
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.
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.
Quote:Original post by MikeTacularQuote:Original post by CTar
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.
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.
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.
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.
Quote:ISO/IEC 14882:1998(E) -- C++ -- Library introduction
17.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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
