|
Boost : |
From: JOAQUIN LOPEZ MU?Z (joaquin_at_[hidden])
Date: 2007-12-03 12:16:03
Hello Joel, sorry if the issues below have already discussed,
I don't have time right now to review the whole thread.
----- Mensaje original -----
De: Joel de Guzman <joel_at_[hidden]>
Fecha: Sábado, Diciembre 1, 2007 5:48 am
Asunto: [boost] [RFC] Header/namespace policy draft
Para: boost_at_[hidden]
> Hi,
>
> 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.
> - 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
http://www.boost.org/libs/tuple/doc/design_decisions_rationale.html
Cheers,
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk