Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2007-11-18 10:26:11


on Sun Nov 18 2007, "Robert Ramey" <ramey-AT-rrsd.com> wrote:

>>> In my particular case, I had a need for some things like
>>> static_warning and strong_typedef which didn't exist. I didn't put
>>> them where they are currently found by accident. I knew they didn't
>>> fit in the serialization library
>>> and it seemed they were very similar to other files in the above
>>> list. I made
>
>> So, if I decide that some parts of spirit (a lot! e.g. multi_pass
>> iterator) is useful outside spirit and does not really belong in
>> spirit, I'm free to put that outside the spirit sphere and into boost?
>
> Up until now that's been the case.

In general, no, it has not been the case. This may not be a perfect
arrangement, but with very few exceptions:

* Core libraries whose documented public interface fits in just a few
  headers and a few pages of documentation have been able to put all
  their public headers in boost/ and their components in boost::.

* Larger libraries have sometimes placed a single consolidated
  convenience header in boost/, forwarding to files of the form
  boost/<libraryname>/<header>.hpp. Regardless, their documented
  public components are not in boost/ or namespace boost::

* Un-reviewed implementation details of libraries have been placed in
  boost/detail if they need to be used by other libraries and a
  subdirectory of boost/<libraryname>/ otherwise

I explained most of this in
http://lists.boost.org/Archives/boost/2006/05/105195.php

> So rather than saying that authors have refused to follow "standard
> practice", it would be more accurate to say that...

Nobody said that. What I said was that some people have ignored
direct (public and private) appeals from moderators to bring their
headers into conformance with the standard practice, and that is
exactly correct.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk