30 replies to this topic

[Brother Bob]

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.

[Shaquil]

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?

[Brother Bob]

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 &);

Edited by Brother Bob, 20 February 2013 - 10:37 AM.

[hikarihe]

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

 

sankyu

[EWClay]

You should never put using namespace in a header. It removes the entire point of the namespace and can cause problems for any code that includes it.

I would not have using namespace at all, it makes the code clearer to be specific about where things come from. If you have to do it, put it in the smallest scope possible.

[nobodynews]

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.

[hikarihe]

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

Edited by hikarihe, 20 February 2013 - 02:27 PM.

[King Mir]

 

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.

[Shaquil]

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

[BinaryPhysics]

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?

[SiCrane]

For Windows API functions, they tell you what header you should actually include. For example, if you look at GetLastError() it says "Header WinBase.h (include Windows.h)" so you should probably follow the documentation and include windows.h rather than winbase.h.