Boost logo

Boost :

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

on Sun Nov 18 2007, "Robert Ramey" <> 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

> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at