Re: [boost] [RFC] Header/namespace policy draft

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

JOAQUIN LOPEZ MU?Z wrote:
> 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.

Regards,
-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net