• Advertisement
Sign in to follow this  

A question on style regarding includes (C++)

This topic is 1791 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
Advertisement

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

Share this post


Link to post
Share on other sites

 

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement