Boost logo

Boost :

Subject: Re: [boost] Boost policy for putting headers in boost/ Was: #3541 Support <boost/ptr_map.hpp>
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2009-10-23 13:31:14

----- Original Message -----
From: "Eric Niebler" <eric_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, October 23, 2009 6:56 PM
Subject: Re: [boost] Boost policy for putting headers in boost/ Was: #3541 Support <boost/ptr_map.hpp>

> Scott McMurray wrote:
>> 2009/10/23 Frank Mori Hess <frank.hess_at_[hidden]>:
>>> How do these objections to boost/D/all.hpp not also apply when it is called
>>> boost/D.hpp?
>> Presumably the argument is that if "all" doesn't include every single
>> header in the library, then it's misleading, whereas D.hpp can be the
>> "author's cut" of functionality.
> Yes. That's the case for proto.hpp. It includes everything except debug
> utilities and typeof registrations. If I were to add serialization or
> python support, that would also be left out. A proto/all.hpp would
> either be inefficient and largely useless or else misleading. I imagine
> the same is true for most libraries.

I agree with you. boost/<libname>.hpp don't needs to include all the public files.
In addition to
* typeof registration
* serialization
* phyton support

I will add every 'decoration' to existing types, either from STL or from Boost.

In Boost.Synchro I have files defining traits for thread mutex (from Boost.Thread) and for process mutex (from Boost.Interprocess). I as a user don't expect that boost/synchro.hpp will include all the traits files. IMO, it is up to the user to include the specific file.

In Boost.Conversion, boost/conversion.hpp includes all the core files, but don' include every specific STD or Boost conversion. If some one needs to use conversions from chrono::duration to posix::time_duration he needs to include explicitly



Boost list run by bdawes at, gregod at, cpdaniel at, john at