Date: 2000-06-11 22:41:00
David Abrahams writes:
> You all know I have mixed feelings about entering this territory too deeply.
> There is already a project (STLport) which does this job better and more
> completely than we could ever hope to do it. Also, I think they're working
I agree that people *should* use STLport, but I also think it is
unreasonable to force people to use STLport. With that in mind the
boost libraries need to be self reliant.
> on a new "official" lib for GCC which is a hybrid of the SGI STL and a
> GNU-specific iostreams implementation. All that said, I have no real
> objection to doing something like this. Whatever we need to do to get things
> to work I guess.
> > Another alternative is to
> > provide versions of the iterator helpers that do not used
> > std::iterator... it's trivial to make that change and I'd be more than
> > happy to do it.
> Compilers which don't support partial specialization will need to rely on
> public derivation from std::iterator<> to get the iterator_category,
> value_type, and difference_type of user-defined iterators through overloaded
> functions, so we'd better not cut that derivation out entirely. If it's one
Of course, the compiler that doesn't have std::iterator does support
partial spec ;)
> or the other, I favor fewer switches in the main-line boost code, meaning
> "add the definition of std::iterator<>"
Ok, that sounds good.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk