You shouldn't have any using-statements at file-scope in a header file at all. Either limit the scope so that the using-statement does not extend into the full scope of the translation unit, or fully qualify any name in the header file.

You shouldn't have any using-statements at file-scope in a header file at all. Either limit the scope so that the using-statement does not extend into the full scope of the translation unit, or fully qualify any name in the header file.

I think I understand why you say that, but could you explain it for me anyway?

Instead of having using-statements in the header file, use the fully qualified name. That is, do this:

#include <vector>
void myFunc(std::vector<myClass> const &);

and not this:

#include <vector>
using namespace std;
void myFunc(vector<myClass> const &);

after reading this my program compiles in 1/5th the time it took before

sankyu

after reading this my program compiles in 1/5th the time it took before

sankyu

That's good, but that's not why you should do it that way. You should do it that way because otherwise you force everyone who uses your header to pollute the global namespace and polluting the global namespace should be avoided for same reason real pollution should be avoided.

which of these is better practice?

• include & define whatever the header file needs to compile. include & define all the rest in source file
• include & define whatever the header file needs to compile. include & define everything in source file

after reading this my program compiles in 1/5th the time it took before

sankyu

That's good, but that's not why you should do it that way. You should do it that way because otherwise you force everyone who uses your header to pollute the global namespace and polluting the global namespace should be avoided for same reason real pollution should be avoided.

which of these is better practice?

• include & define whatever the header file needs to compile. include & define all the rest in source file
• include & define whatever the header file needs to compile. include & define everything in source file

I would say it's fine to not include the files a source file needs, when they are already included in the associated header. You should never re-#define things though. Macros that need to be in the header should not be copied in the source file.

By the same token, macros that don't need to be in the header file shouldn't go there; macros don't have name spaces, so there is no way to resolve name collisions. If you do define a macro that is not part of the intended interface, give it a long name to minimise the odds of collisions.

This thread has been really helpful in improving my coding practices. Thanks to everyone who's been adding their input.

I've always tried to include only what I need and not rely on a header including another header. If a type is indirectly included via a header I'm using but I need that type specifically then I manually include it's definition.

However! It has just occurred to me that large APIs/engines generally organise which headers/defines should exist based on builds, etc. Surely manually including a header removes this system of automatic, self configuring. I'd point to something like 'windows.h' as an example.

So diversion question: Is this style of 'headering' an example of poor design or should it be used at all? Should you actually include 'winuser.h' if you need it or should you actually rely on 'windows.h' setting it up for you?