Boost logo

Boost :

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

on 3/25/02 3:00 PM, Edward D Brey at EdwardDBrey_at_[hidden] wrote:

>> From: Daryle Walker [mailto:darylew_at_[hidden]]
> Thanks for the comments on the review comments.
>> 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.
> I like that you are applying a methodical approach here. Before jumping into
> it though, it would probably be useful to identify the advantages of stopping
> the "sprawl".

A directory with lots of entries is harder to search through. Also we have
a lot of names in the "boost" namespace. There have been suggestions to use
sub-namespaces to prevent name collisions. These sub-namespaces can be used
to separate the libraries to their various domains. The directory
structures should match the name hierarchy to prevent confusion on how to
find an item.

> I find your use of the term sub-library curious. Wouldn't we want to limit
> the collection of top-level directories to one per library, or else face a
> sprawl of TLDs?

By a sub-library I mean what others here refer as a "(source) library," but
within a namespace-mirroring hierarchy.

>>> - Contents of index.html should be merged into iostate.html, since this is
>>> such a small library. Having the extra level in between the main boost
>>> library page and the actual documentation of the library slows down
>>> browsing. When the user clicks on iostate from the boost library index
>>> page, the first think that he should see is a brief description and a
>>> "Hello, world" example.
>> No. See my future namespace, forwarding header, and sub-library philosophy
>> post.
> What is your vision for the io library? E.g. should lexical_cast be part of
> it? What other features do you see being added? I can see creating an io
> namespace if we have a general road-map on how to fill it. Otherwise, I would
> be in favor of keeping ios_state a top-level utility.

The initial idea for the I/O library was introducing the stuff I wrote in
the more_io package in a piecemeal fashion. Others are free to use it. The
lexical_cast functionality could be moved if the maintainer wishes. The
format package is an example of a new library that someone else did that
could also go there.

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at