Re: [boost] [system][chrono] header-only libs

Subject: Re: [boost] [system][chrono] header-only libs
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-10-14 11:26:06

----- Original Message ----- 
From: "Anthony Williams" <anthony.ajw_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, October 14, 2010 8:53 AM
Subject: Re: [boost] [system][chrono] header-only libs

> "vicente.botet" <vicente.botet_at_[hidden]> 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