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
----- Original Message -----
From: "Paul Baxter" <paul_baxter_at_[hidden]>
> > Several of us would like to take an unprecedented step for boost: we
> > gather related library components from several boost libraries into a
> > library. In particular, I believe the following iterator-related
> > 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
> 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
> individual components when the components are not dependent on one
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
> 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
> 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
> 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
> 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!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk