Re: [boost] [lib maintainers]Pleaseidentifyheadersinboost-root/boost

From: John Maddock (john_at_[hidden])
Date: 2007-11-19 04:43:15

Robert Ramey wrote:
>> Yes, because boost/detail is not public API and the
>> stuff there is implementation detail.
>
> Hmm - and implementation details shouldn't be documented?
> shouldn't be tested? If they're in a common area it seems
> that they are meant to be used by more than one library -
> and indeed they are. lightweight test others come to mind.

The way I approached this in the Boost.Math update was to place "documented 
details" in a sub-namespace of boost::math.  Not sure if it's ideal, but it 
does keep everything nice and tidy :-)

>> If a particular utility is useful for many libraries, then one of
>> the libraries can host it prior to it getting reviewed independently
>> and becoming a full-fledged boost citizen. That's the policy that
>> we've been following with the synergy between xpressive and spirit,
>
> I faced exactly that same issue with headers such as
> static_warning.hpp There was already a header in boost/static_assert.hpp. 
> I thought
> (and still think) that logical place for static_warning.hpp was in
> that same directory.  I considered the possibility of placing it in
> boost/serialization/static_warning.hpp but at the time I thought
> I might have to change it later to boost/static_warning.hpp sometime
> in the near future and I wanted to avoid an interface breaking change.

Sure, but static_assert has been through a review and is documented as a 
library in it's own right.  static_warning should probably have gone down 
the same route: probably a fast-track review for a small component like this 
would suffice.

> All these examples demonstrate that there really is
> no defined "standard practice" and never has been.

Please give us credit for trying though: yes we have legacy headers in 
boost/ that maybe shouldn't be there, but that doesn't mean that new stuff 
should be a free for all ! :-)

Regards, John Maddock.