From: Larry Evans (jcampbell3_at_[hidden])
Date: 2002-03-24 12:05:10
Daryle Walker wrote:
> 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?
> 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
> 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?
> 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?
> All the components will share those subdirectories. The "doc" subdirectory
> will have an "index.html" that lists the FD-header and all the main
> component headers. The main component headers listings will have links to
> each component's HTML documentation in the same subdirectory.
This sounds good to me. I've often torn between putting too many comments
in the .hpp and .cpp files or in the documentation, but your suggested directory
structure would make it easy for a user to find documentation for a particular
file or class.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk