Boost logo

Boost :

From: Joel de Guzman (joel_at_[hidden])
Date: 2007-12-03 18:17:43

> Hello Joel, sorry if the issues below have already discussed,
> I don't have time right now to review the whole thread.

No problem. Your comments are very welcome!

>> As promised, here's a draft of the proposed
>> "Boost Header And Namespace Policy" (attached)
>> Comments, suggestions, etc. very welcome.
> [...]
>> * Non-core libraries may place 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::
>> For a library named foobar, the convention is as follows:
>> - A single boost/foobar.hpp that forwards to all the headers
>> of foobar:
>> boost/foobar.hpp
> I see a couple of problems with the requirements that *all*
> Boost.Foobar headers be included from boost/foobar.hpp:
> 1. If the library is huge or it consists of several components
> among which the user has to select some for her specific needs,
> having a include-all header can lead to unnecesary compiler
> load.
> 2. Some functionality (serialization comes to mind) is best
> isolated to specific headers that the user has to explicitly
> include to bring that funcionality in, so as to not incur in
> unnecesay dependencies.
> So, I'd prefer that boost/foobar.hpp (if it exists) be
> regarded as a convenience header that includes all the headers
> in Boost.Foobar (when it's OK to do so) *or* a selection of
> the most usual components from the library.

Those are good points. I'll add them in the document.
Fusion too does not have a convenience header, for the
same reason. That's the real intent of this item. Thanks
for clarifying.

>> - foobar components (classes, types, constants etc.) in
>> namespace boost::foobar. Example:
>> namespace boost { namespace foobar
>> {
>> class foo {/*...*/};
>> class bar {/*...*/};
>> }}
> This is not the case at least for one Boost library,
> namely Boost.Tuple, whose associated namespace is boost::tuples,
> with a postfixed 's'. The reason for this anomaly is that
> some compilers have problems with classes living in homonyn
> namespaces, a la boost::foobar::foobar, see

Indeed. I'll add that too. As for all rules, there are exceptions.


Joel de Guzman

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