Jump to content
  • Advertisement
Sign in to follow this  
Alessio1989

Any way to force a namespace for global definition of 3rd party headers?

This topic is 754 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

I guess the answer is "just no!".

However, I personally find very tedious to have tons of Win32 and C libraries definition in the global namespace, since it only add tons of things that slow downs Intellisense.

Moreover, putting those headers in the PCH extends only the issue to all the project in a one-shot manner.

Is there any practical solution? Actually the only little help I am aware is to force the scope resolution operator to see only the global definitions and hide the locals definition, but that's also tedious...

Edited by Alessio1989

Share this post


Link to post
Share on other sites
Advertisement

Yes, putting the winapi headers into a namespace is a terrible idea, I tried this before  :wacko:

 

I also know it is not possible in C++ to "uninclude" a header file :\

Share this post


Link to post
Share on other sites

If this is really a problem, try to keep those includes out of your own headers, perhaps by encapsulating the APIs and only including the headers in very specific source files.


This. If you're including windows.h in one of your headers, you're doing something super wrong.

Use forward declarations and use wrappers. Out of a few hundred non-third-party source files in my latest personal project, only a few include windows.h: filesystem_win32.cpp, threads_win32.cpp, gpu_d3d.cpp, diagnostics_win32.cpp, and logging_win32.cpp. The first three are obvious I think. The diagnostics one is for callstack generation and the assert dialog, and the last one is for OutputDebugConsole support.

Note that not a single header includes windows.h. Of the third-party libraries I use, they only use windows.h inside of their .cpp files or their private .h files, so it never infects my project.

The same is true for just about any large header. D3D/OpenGL headers, sound middleware headers, SDL/SFML/GLFW/etc., bad C++ headers like <algorithm>, anything from Boost, etc.

That said, windows.h is rather special. It's both one of the worst offenders in terms of bloat and one of the most configurable in terms of bloat. For the times that I do need windows.h, I generally wrap it behind a custom windowskit.h that #define's a ton of magic macros before including windows.h that strips out a lot of its cruft and undoes some of its UNICODE macros that annoy me or conflict with identifiers I use. Here's an example WindowsKit.h

Share this post


Link to post
Share on other sites
OK, I think I will go with some preprocessor magic plus more wrapping around platform depended implementation ^_^ Edited by Alessio1989

Share this post


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

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!