[Boost-users] Re: iterator_adaptor: disguise iterator as const_iterator?

From: David Abrahams (dave_at_[hidden])
Date: 2004-12-02 15:31:48

Duane Murphy wrote:
 > I've started doing a conversion of many old iterators to the
 > new iterators. I also have been going through the docs, so I
 > thought I would add a few comments.
 >
 >
 >>>No, I am serious. Looking at the iterator_facade doc, first of
 >>>all it does not tell me what it is all about. The one sentence
 >>>in the abstract is indeed very abstract.
 >>
 >>Wow, good point.
 >
 >
 > The biggest thing missing for me is what the difference is
 > between facade and adaptor. In particular when would you choose
 > one over the other. I think i know the answer, but it wasn't
 > clear that the docs explained that very well.

The answer is, ``you'd choose adaptor when you want to build a
new iterator that's "just like" some other iterator in some of
its behaviors, but (usually) different in some others.''

Yes, seeing that could help.

 >>>I would like to see more examples, if that is possible.
 >>
 >>Hm.  Examples of what?
 >
 >
 > The example with details shows a forward iterator that can also
 > be used as an adaptor. Clever for continuity, but reality is
 > seldom that cooperative.

You might be surprised to learn that I didn't plan it that way.
I said to myself, "I need to build a simple iterator.  Probably
the simplest thing I can imagine is a linked list iterator.
Okay... Hey, that same iterator could be built pretty well with
iterator_adaptor after all!"
 >
 > I would like to see a full random access facade. For example:
 > build the full suite of four iterators for std::vector from the
 > outside of std: :vector. That is assume std::vector had no
 > iterators; how would iterators be implemented?

Well, that's really uninteresting.  You'd use pointers, and if
you didn't like pointers you'd use iterator_adaptor over the raw
pointers, with no behaviors implemented.  You'd never implement
the two reverse iterators using iterator_facade because according
to the standard they're required to be built from
std::reverse_iterator, and even if you didn't do that you should
build them using boost::reverse_iterator.

 >>>I hope this didn't sound rude, I know it must be hard to write
 >>>a doc for such a complicated library.
 >>
 >>Yes, but that usually means the library needs to be simplified ;-)
 >
 > I have found boost::iterator to be awesome. Using
 > boost::iterator to build new iterators is actually easier than
 > the docs seem to make it out to be. It seems like it might be a
 > case of "you can't see the forest because of the trees."

Might be.  But actually I think we have some serious usability
problems.  The way defaults are computed in this library is very
complicated, to the point that documenting it is nearly
impossible.  We should revisit that problem starting from the
specification side and then proceeding to coding.

The authors of this library are somewhat swamped and burned out
on it at the moment, so if anyone would like to volunteer to
help with these improvements (I mean with the authors'
participation) they'd be more likely to get done.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com