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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk