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.