Need help understanding how this code works.

[eXpl0it3r]

Opps, forgot to ask another question.  What's the "_INCLUDED" suffix on the pre-processor directives for?  I've looked in all of my C++ books and did a bit of Googling but have not found an explanation for why it's needed.

The whole thing is called include guards and they are needed to prevent multiple inclusion/decelrations. If you now add _INCLUDED are not doesn't matter, in fact it should just be a unique name that nothing else in your code does ever #define. For more information just google 'include guards'.

[FRex]

It's not needed but macros(something that was in C so you know it means trouble..) don't respect namespaces so they have to be something extremely ugly/stand out a lot so that you're unlikely to use it in normal code. So include guard usually contain name of file because it's unique but can have even more to be safer. sfml include guards are SFML_filename_HPP

'#define' is 'macro'
the '#ifndef' '#endif' blocks are used to do something called 'conditional compilation'
macros and #ifndef #endif blocks used like that are called 'include guards'
In vc++ you can use #pragma once (it works a bit differently and supposedly faster during compilation than include guards but in the end the effect is same) at the beggining of a header but it's not guaranteed to be on every compiler.

[Raptor88]

Hi eXpl0it3r and FRex,

Thanks for your responses. Prior to posting, I had done intensive Googling on "Include guards", "Preprocessor Directives", and "_INCLUDED".  I found some sample code using it but no real explanations of why "_INCLUDED" is needed.  I did notice that the "_INCLUDED" Google finds were related to C code rather than C++ code.

Would it be safe to say that in C++ there's no need to use the "_INCLUDED" suffix when using #ifndef and #define include guards?

If there's a reason why the "_INCLUDED" suffix is needed in C++ code, could you please explain why it's needed over never using it at all.

Thanks,
Raptor

[FRex]

It's NOT needed. It's not at all significant, macros are not code, it's preprocessor - it works in text, not code, the _INCLUDED can make it more intuitive, it could be whatever but should be in ALL CAPS, long and unique(for safety).
http://www.stroustrup.com/bs_faq2.html#macro - read this to understand why macros are evil and should have extremely unique names.

Conventions such as having macros (and only macros) in ALLCAPS helps, but there is no language-level protection against macros. (...) Macros operate on a program as a stream of characters before the compiler proper sees it

[eXpl0it3r]

http://www.stroustrup.com/bs_faq2.html#macro - read this to understand why macros are evil and should have extremely unique names.

@FRex: Please keep in mind that include guards do not have anything to do with macros. The only thing they have incommon is that they both make use of the preprocessor. It completly okay and even adviced to use include guards with

#ifndef CLASS_HPP
#define CLASS_HPP
// Class decleration
#endif // CALSS_HPP

[FRex]

CLASS_HPP seems like an extremely unique name written in all caps.

[eXpl0it3r]

CLASS_HPP seems like an extremely unique name written in all caps.

Ehrm, why so sarcastic?
I mean it's obvious that you'll have to replace that with your own class name...

[FRex]

It wasn't sarcastic, <own class name>_HPP is extremely unique and in all caps like all macros should be.

[eXpl0it3r]

It wasn't sarcastic, <own class name>_HPP is extremely unique and in all caps like all macros should be.

Oh well then it was kind of hard to figure that out, because it could've been read in both ways.

Yes <own class name>_HPP is good and if you want you can also add _INCLUDED or _RAPTOR88_IS_AWESOME, it really doesn't matter code wise.

[Raptor88]

It's NOT needed. It's not at all significant, macros are not code, it's preprocessor - it works in text, not code, the _INCLUDED can make it more intuitive, it could be whatever but should be in ALL CAPS, long and unique(for safety).
http://www.stroustrup.com/bs_faq2.html#macro - read this to understand why macros are evil and should have extremely unique names.

Conventions such as having macros (and only macros) in ALLCAPS helps, but there is no language-level protection against macros. (...) Macros operate on a program as a stream of characters before the compiler proper sees it

Since it's not needed, I won't use it.  Interesting link you provided.  All sorts of good info in it.

Thanks!
Raptor

[eXpl0it3r]

Interesting link you provided.  All sorts of good info in it.

Yes Bjarne Stroustrup's (FYI, he's the 'inventor' of C++) FAQs are quite a good read.
If you're looking for good C++ books, you can take a look at Stroustrup's 'The C++ Programming Language', which is to some point a bit like a detailed reference manual, thus it's quite an intensive read.