Re: [boost] reverse_iterator.hpp uploaded

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-06-11 22:10:41

----- Original Message -----
From: <jsiek_at_[hidden]>
> Hi Dave,
>
> David Abrahams writes:
>  > Because there was no apparent interest in the indirect_iterators I
uploaded
>  > last week, I have used the wrapped_iterator template to create a
motivating
>
> Ahh, but a lack of immediate reaction does not necessarily mean a lack
> of interest! I'm interested :) Just been busy...  I use this
> wrapped_iterator idea a lot, though my version is broken when it comes
> to const/non-const compatibility.

Which version is "your version"?

> Ok, so assuming we can work around
> the friend function instantiation problem...

That's a big assumption.

> I'm wondering if we can
> make the implementation of reverse_iterator even smaller. Can we use
> b&n to also get rid of the operator+=, etc.?

What do you have in mind? I confess to being a bit lost.

> Oh, and on a separate note... there's an issue to be addressed with
> std::iterator and the old g++ lib. I've noticed that in recent
> revisions of boost/operators.hpp some #define's have been appearing
> removing the iterator helpers that use std::iterator. How about
> instead of removing the iterator helpers (which will break all of my
> code that uses it) we provide std::iterator in boost. I know all the
> reasons for not putting in std::iterator in boost, but again, its just
> a workaround for a broken implementation.

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
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
or the other, I favor fewer switches in the main-line boost code, meaning
"add the definition of std::iterator<>"