Re: [boost] Boost policy for putting headers in boost/ Was: #3541 Support <boost/ptr_map.hpp>

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 12:37:33

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

> 
> Eric Niebler wrote:
>>
>> I don't like the idea of a boost/<lib>/all.hpp header. Does
>> that really
>> drag in everything? Debug utilities? Boost.Python integration?
>> Boost.Serialization support? Typeof registrations? Support
>> for Zlib and
>> Bzip compression that will require downloading, configuring,
>> building,
>> and linking to additional external libraries? I find all.hpp headers
>> generally useless.
> 
> If you don't want everything, you wouldn't include the all.hpp header.  Such headers are a convenience, particularly for those just learning to use a library (when the constant compilation failure because yet another include directive is needed can turn off a new user).
> 
> This is no different from what is already happening, except the name of the header would be standardized and its location relative to the library directory would be standardized.  It doesn't preclude you from including only the headers you want.
> 
> What we're trying to address is whether the "include all" header should be boost/<libname>.hpp, boost/<libname>/<libname>.hpp, or boost/<libname>/all.hpp.  There are examples of the first two already -- and perhaps even slight variations of those.

I think the main problem with standardizing boost/<lib>/all.hpp  is could clash with a feature named all for a particular domain.

Best,
Vicente