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@boost-consulting.com> Fecha: Sábado, Diciembre 1, 2007 5:48 am Asunto: [boost] [RFC] Header/namespace policy draft Para: boost@lists.boost.org
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