Re: [boost] Re(post): My Namespace, Forwarding Header, and Sub-library Philosophy Post

From: Daryle Walker (darylew_at_[hidden])
Date: 2002-04-10 21:03:26

on 3/24/02 11:05 AM, Larry Evans at jcampbell3_at_[hidden] wrote:

> Daryle Walker wrote:
> [snip]
> 
>> For example, we'll start a talk-show sub-library.  To stop the sprawl of
>> headers in the top boost header directory, components for talk-shows will go
>> in a "talk_show" namespace (within the "boost" namespace).  To make the new
>> headers easy to find, the headers for stuff in the "talk_show" namespace will
>> go into the new "BOOST_ROOT/boost/talk_show" directory.
> 
> Are you suggesting that boost/shared_ptr.hpp and boost/scoped_ptr.hpp should
> be moved to their own subdirectory with a name such as boost/smart_ptr?

This is a guideline that future libraries should think about following.
Whether or not existing libraries should move to this model is up to the
maintainers of those libraries.  (Of course, other people could ask if a
reorganization should be done.)

>> Forward declarations, like <iosfwd>, make some applications of a class
>> easier.  We could make the forward declaration header
>> <boost/talk_show/fwd.hpp>, but I like <boost/talk_show_fwd.hpp> better
>> because I don't like a lot of headers with the short name "fwd.hpp".  This
> 
> What about <boost/talk_show.fpp>.  I know it's non-standard, but gcc also has
> a non-standard .tpp extension instead of .cpp for template code used for
> explicit instantiation.

I don't want to risk confusion from non-standard extensions.

> [snip]
> 
>> 
>> Note that the previous two paragraphs imply that every time a new component
>> is added to a sub-library, any other component in that sub-library that you
>> use will get marked with a dependency recompile when you upgrade your Boost
>> installation.  (I know you could avoid the problem by making a forward
>> declaration header for each sub-library component, but that would result in a
>> _lot_ of little FD-headers.  I'd rather take advantage of grouping.)
> 
> And the disadvantage of a lot of little headers is slower compile time due to
> many file open/close?  But, as you pointed out above(I think), if there is a
> component1_fwd,hpp and component2_fwd.hpp, then a change in component1.hpp
> would only require compiling the .cpp which include component1_fwd.hpp.  So
> why is one more important than the other?

I don't think a lot of files named "fwd.hpp" is asthetically pleasing.
Also, compiler file search algorithms for header files work better if there
is minimal filename overlap.  A FD-header would change when a new
sub-library is added or an existing sub-library has an user-visible
interface change.  These would correspond to a new Boost release, so the
user should do a complete recompile to check for other compatibility
problems anyway.

>> The sub-library's extra files would be in "BOOST_ROOT/libs/talk_show".  It
>> would have the "doc", "test", "example", and possibly "src" subdirectories.
> 
> Like the boost_1_27_0 regex, thread, graph, and python libraries?
[TRUNCATE]

Yeah.  But those libraries are a single piece of work with that directory
structure.  My plan has separate pieces of work sharing these directories.

-- 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com