----- Original Message ----- From: "Anthony Williams" <anthony.ajw@gmail.com> To: <boost@lists.boost.org> Sent: Thursday, October 14, 2010 8:53 AM Subject: Re: [boost] [system][chrono] header-only libs
"vicente.botet" <vicente.botet@wanadoo.fr> writes:
I understand that you should have found some issues including <windows.h> file. I see that other libraries as FileSystem, Flyweithts, Interprocess, interlocked ... include it as you said:
#if defined(BOOST_USE_WINDOWS_H) # include <windows.h> #else // extern declaration #endif
Unfortunately not all files including <windows.h> are protected in this way. Is BOOST_USE_WINDOWS_H the offical macro to use? is this described somewhere?
It isn't documented anywhere that I can see, but it is used by lots of libraries.
As there are quite a lot of files that includes some parts of <windows.h> some of them include the same declarations. I was wondering if we can not add a boost/detail/windows.hpp> file that will declare whatever is needed in Boost. Is this a good or a bad idea?
I think that's a bad idea, as lots of libraries will need to touch it, and it will end up getting big and bloated like <windows.h>. A boost/details/windows directory with a lot of special-purpose files would be better.
Yes. This will much less monolitic. I will give it a try.
As other platforms include other macros, shouldn't I do the same for this files?
You mean <pthread.h> defines macros, so should we protect against that in the same way (for example)?
I was thinking to some Mac files that include other macros that can colapse with Boost identifiers. If I remember the inspection program has added some of these macros in his inspection list.
If the header is as all-encompassing and messy as <windows.h> then yes. However, there are not many platforms where just about everything is a macro (e.g. because there are xxxA and xxxW versions of each function that takes a string), and there are macros that actively trample on common identifiers such as min and max (this even makes using std::min and std::max from <algorithm> tricky --- I end up using std::min<> everywhere to avoid being bitten).
Oh yes std::min<>(a,b) should be more readable that (std::min)(a,b). At least this ca be applied when the function is a template. Thanks, Vicente