• Be wary (i.e. don't do it) of using identifiers which start with an underscore and a capital letter (_Likethis) - they're reserved for the implementation, so e.g. the standard library can feel free to use helpers without conflicting with identifiers in the user's code. Similar story for anything starting with a double underscore (__Likethis but also __likethis).
  
• You don't want to include the header if you can avoid it - instead, include it in the source file that needs it (getnumber.cpp, doublenumber.cpp, printresult.cpp). This way you don't drag unnecessary things into files that don't need them, cluttering namespaces and perhaps increasing compile times.
  
• You want to protect the header as a whole, not the individual declarations: #ifndef DOUBLE_H
#define DOUBLE_H

int GetNumber();
int DoubleNumber(int nUserNumber);
int PrintResult(int nDoubleNumber);

#endif
  
• I wouldn't generally restrict myself to a single function per source file. It can actually make things harder to read. I try to keep the content of both headers and source files grouped into what I see as logical clumps of code, with no hard-and-fast rule. So I'd have at least GetNumber and PrintResult in the same file, for example.
  

Thanks a lot for the quick reply. The things you write make sense to me, but I am wondering where I am supposed to include iostream. If I include iostream in my main.cpp, my other cpp files does not seem to find it, but if I include it in every .cpp-file (that uses cout or cin) in the project it seems logical to me that I would end up with having multiple "copies" of iostream. Is this the case, or am I missing something?

The reason that including iostream in main.cpp isn't enough is that each source file is compiled separately. It's worth reading up on the C++ compilation model, but basically each source file is individually compiled to an object file. Each object file can refer to symbols which are defined in another. To compile, you just need a declaration - it's enough to say "there's a function called foo with the signature bar", but to actually execute the program, you obviously need the actual definition. So the linker takes these object files, resolves all the references to symbols including across files, and produces a single, coherent executable.

If you include a file, that file is substituted (copied-and-pasted) into the file containing the #include directive. So if you include iostream in main, the other source files know literally nothing about it when they're compiled. So iostream must be somewhere in a chain of includes from the source file that requires it, but ideally as near the bottom as possible, so that it's only visible to stuff that really needs it. In your example, the 'as near the bottom as possible' would be directly in each of the two source files, yes.

• Be wary (i.e. don't do it) of using identifiers which start with an underscore and a capital letter (_Likethis) - they're reserved for the implementation, so e.g. the standard library can feel free to use helpers without conflicting with identifiers in the user's code. Similar story for anything starting with a double underscore (__Likethis but also __likethis).
  
• You don't want to include the header if you can avoid it - instead, include it in the source file that needs it (getnumber.cpp, doublenumber.cpp, printresult.cpp). This way you don't drag unnecessary things into files that don't need them, cluttering namespaces and perhaps increasing compile times.
  
• You want to protect the header as a whole, not the individual declarations: #ifndef DOUBLE_H
#define DOUBLE_H

int GetNumber();
int DoubleNumber(int nUserNumber);
int PrintResult(int nDoubleNumber);

#endif
  
• I wouldn't generally restrict myself to a single function per source file. It can actually make things harder to read. I try to keep the content of both headers and source files grouped into what I see as logical clumps of code, with no hard-and-fast rule. So I'd have at least GetNumber and PrintResult in the same file, for example.
  

If you are targeting a compiler that supports "#pragma once" and never have to be able to compile in one that doesn't you can use that directive instead of the include guard. Be aware that not all compilers support this directive as it is non-standard.
http://en.wikipedia....iki/Pragma_once

A way arround you having to include all common headers everywhere is making one header that just includes the ones you need everywhere and only include that one at the top of your cpps. Precompiled headers might help as well with compile times in bigger projects.

To be honest, I don't really understand why people continue to mess around with include guards in this day and age.

#pragma once


Done.

Granted, pragma's aren't by nature portable, but I can't think of a C++ compiler in the last decade that didn't properly support #pragma once. Using pragma once removes the chance of a name collision and simply make life easier.


That said, especially in game sources, I almost never see it used, seems silly to me.

[quote name='TheUnbeliever' timestamp='1330600605' post='4918132']

• Be wary (i.e. don't do it) of using identifiers which start with an underscore and a capital letter (_Likethis) - they're reserved for the implementation, so e.g. the standard library can feel free to use helpers without conflicting with identifiers in the user's code. Similar story for anything starting with a double underscore (__Likethis but also __likethis).
  
• You don't want to include the header if you can avoid it - instead, include it in the source file that needs it (getnumber.cpp, doublenumber.cpp, printresult.cpp). This way you don't drag unnecessary things into files that don't need them, cluttering namespaces and perhaps increasing compile times.
  
• You want to protect the header as a whole, not the individual declarations: #ifndef DOUBLE_H
#define DOUBLE_H

int GetNumber();
int DoubleNumber(int nUserNumber);
int PrintResult(int nDoubleNumber);

#endif
  
• I wouldn't generally restrict myself to a single function per source file. It can actually make things harder to read. I try to keep the content of both headers and source files grouped into what I see as logical clumps of code, with no hard-and-fast rule. So I'd have at least GetNumber and PrintResult in the same file, for example.
  

If you are targeting a compiler that supports "#pragma once" and never have to be able to compile in one that doesn't you can use that directive instead of the include guard. Be aware that not all compilers support this directive as it is non-standard.
http://en.wikipedia....iki/Pragma_once

A way arround you having to include all common headers everywhere is making one header that just includes the ones you need everywhere and only include that one at the top of your cpps. Precompiled headers might help as well with compile times in bigger projects.
[/quote]


What ironic timing.


Frankly if you are still using LCC-Win32 from 2004, or GCC from 1998 ( the two compilers not supporting #pragma once correctly ), you have much greater problems to deal with!