Re: [boost] Library consolidation process?

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-12-31 10:33:17

I guess I forgot the most important question of all, which was "should it be
done?"... ;-)

----- Original Message -----
From: "Paul Baxter" <paul_baxter_at_[hidden]>

> > Several of us would like to take an unprecedented step for boost: we
want
> to
> > gather related library components from several boost libraries into a
new
> > library. In particular, I believe the following iterator-related
> components
> > should be documented in and delivered from a single source:
>
> Conceptually the libs do all have a common basis, but my concern with this
> more coarse-grained approach is that when say, I want to use the random
> number generator I'll have to compile the rest of the iterator components
if
> it all is in the same source file.

Fortunately, none of the iterator-related components require separate
compilation as they're all templated.

> I can see a benefit as an extension to the standard library where file
> explosion would not be appreciated, but I also enjoy being able to just
pick
> individual components when the components are not dependent on one
another.

Okay; part of what this proposal does is to allow you to pick
generator_iterator without interacting with the random library, or to pick
the (original Arithmetic) operators library functionality without getting
library stuff designed to help you build iterators.

> I would totally support a higher level iterator components document to
flesh
> out how Boost has supported iterators in many ways.
>
> I wouldn't be averse to a high level source file that included these lower
> level headers either, so that we could use both methods, but I would
prefer
> not to prematurely combine functional blocks unless there is a significant
> amount of code sharing possible from the process.

Well, there may be a little bit: it looks to me as though generator_iterator
may be reimplementable as an iterator adaptor. Certainly there is a fair
amount of workaround code for broken implementations which can be shared.
Except for boost/iterator.hpp and boost/detail/iterator.hpp (proposed),
though, I see no reason to combine any source files. I'm interested in
/separating/ some components from their existing libraries so that they can
be found together. Leaving iterator adaptors and iterator helpers (from
operators.hpp) in separate headers sounds like a fine idea to me.

> I can also appreciate that under one author, style and consistency might
be
> improved, but think that the drawbacks might outweigh the benefits.

That wasn't an aim of this idea. I hope that, given the massive
contributions in the area of iterators by others, the new library would be a
multi-author lib.

> Witness projects like ACE where significant efforts are made to reduce the
> inter-dependencies as the library has grown larger.
>
> Just an opinion.

"Just" a response ;-)

> Oh and Happy New Year

Likewise, I'm sure!

-Dave