• Create Account

## A question on style regarding includes (C++)

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

30 replies to this topic

### #21Brother Bob  Moderators

10107
Like
3Likes
Like

Posted 20 February 2013 - 09:55 AM

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.

### #22Shaquil  Members

818
Like
0Likes
Like

Posted 20 February 2013 - 10:23 AM

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?

### #23Brother Bob  Moderators

10107
Like
3Likes
Like

Posted 20 February 2013 - 10:37 AM

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.

### #24hikarihe  Members

243
Like
0Likes
Like

Posted 20 February 2013 - 11:16 AM

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

sankyu

### #25EWClay  Members

659
Like
0Likes
Like

Posted 20 February 2013 - 11:50 AM

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.

### #26nobodynews  Members

3017
Like
0Likes
Like

Posted 20 February 2013 - 01:49 PM

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.

C++: A Dialog | C++0x Features: Part1 (lambdas, auto, static_assert) , Part 2 (rvalue references) , Part 3 (decltype) | Write Games | Fix Your Timestep!

### #27hikarihe  Members

243
Like
0Likes
Like

Posted 20 February 2013 - 02:26 PM

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.

### #28King Mir  Members

2391
Like
0Likes
Like

Posted 20 February 2013 - 04:42 PM

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.

### #29Shaquil  Members

818
Like
0Likes
Like

Posted 20 February 2013 - 07:27 PM

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

### #30BinaryPhysics  Members

294
Like
0Likes
Like

Posted 24 February 2013 - 09:33 AM

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?

### #31SiCrane  Moderators

11527
Like
0Likes
Like

Posted 24 February 2013 - 10:03 AM

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.

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.