[Boost-users] Re: Converting from const to non-const withiterator_adaptor

From: Keith MacDonald (boost_at_[hidden])
Date: 2004-01-06 06:58:14

You have proposed a very elegant solution, but I would defy anyone who does
not understand the library inside out to arrive at that solution. The
documentation (iterator/doc/index.html#iterator-facade-and-adaptor) states:

"It is common to define a new iterator which behaves like another iterator,
but which modifies some aspect of its behavior. For that purpose, the
library supplies the iterator_adaptor class template, which is specially
designed to take advantage of as much of the underlying iterator's behavior
as possible."

In this case, I can't see what the underlying iterator is, so don't
understand how iteration can proceed.  For example, if you add the statement
"++x;" to your example, it fails to compile.

To return to my point about the purpose of a software library, my approach
is generally to ask if it will allow me to implement code more quickly and
reliably than without it.  I got to the point of thinking, I've now got to
implement a straightforward iterator, sigh, so will the boost library help
me?  I didn't expect to have to develop a deep understanding of template
metaprogramming and the curiously recurring template pattern, before I could
move on.  Hence my plea for an example of a plain vanilla iterator, by which
I meant something similar to those used for the std library containers.
That would make a much more satisfactory introduction than trying to plough
through the impenetrable documentation.

Thanks for your time and, possibly, for an extremely useful library!

Keith MacDonald

"David Abrahams" <dave_at_[hidden]> wrote in message
news:u4qvatli4.fsf_at_boost-consulting.com...
> "Keith MacDonald" <boost_at_[hidden]> writes:
>
> > I may have misunderstood the purpose of boost::iterator
>
> Do you mean the Boost.Iterator library?  There's no boost::iterator
> component.
>
> > I was expecting it to make it easy to add standard conforming
> > iterators to any container
>
> Containers are sort of irrelevant.  It makes it easy to build
> conforming iterators and adapt existing iterators.
>
> > but
> > the complexity of the proposed solution
>
> ?? it's way simpler than what you posted ??
>
> > (using iterator_adaptor, which I can't get to compile)
>
> <sigh> Fine, here's a complete, compilable example.
>
> #include <boost/iterator/iterator_adaptor.hpp>
>
> struct Node
> {
>     Node* next();
>     Node* prev();
>     Node const* next() const;
>     Node const* prev() const;
> };
>
> template <class V>
> struct iter
>   : boost::iterator_adaptor<iter<V>, V*, V,
boost::bidirectional_traversal_tag>
> {
>     typedef
>       boost::iterator_adaptor<iter<V>, V*, V,
boost::bidirectional_traversal_tag>
>     super;
>
>     iter() {}
>
>     template <class V2>
>     iter(iter<V2> const& x, typename
boost::enable_if_convertible<V2*,V*>::type* = 0)
>       : super(x.base())
>     {}
>
>     friend class boost::iterator_core_access;
>
>  private:
>     void increment()
>     { base() = base()->next(); }
>
>     void decrement()
>     { base() = base()->prev(); }
> };
>
> int main()
> {
>     typedef iter<Node> iterator;
>     typedef iter<Node const> const_iterator;
>
>     iterator x;
>     const_iterator y;
>     y = x;
> }
>
> > is making me doubt that.  In an earlier release of
> > the library, I was able to declare the const_iterator using
> > iterator_facade
>
> You still can, but you have to do more work with iterator_facade.
> Why declare the dereference member if you don't need to?
>
> > then simply adapt it to a non-const iterator using iterator_adaptor, as
> > shown in my original posting.
>
> Is that what your posting was doing?  And you think that's simpler
> than what I did above?
>
> > I've not followed the discussions that led up to the current
> > implementation, so don't know what its advantages are, but if it
> > can't provide a simple solution to the simplest case, has something
> > important been thrown out with the bath water?
>
> I don't know what you mean.  There was no iterator_facade in any
> earlier design which was substantially different from what's there
> now.
>
> > My working solution is now to use iterator_facade to declare instances
of
> > const_iterator and iterator, which are independent of each other, except
> > that a const_iterator can be constructed from an iterator.
Instinctively,
> > this does not seem to the intended way to do it, but it would probably
be
> > quicker to write the iterators from scratch than work that out from the
> > documentation.
>
> We're working on the docs; we apologize for the delay.
>
> > Can I make a plea for an example to be included with the library,
> > which shows how best to add plain vanilla iterators to a container
> > class?
>
> OK.  What do you mean by "plain vanilla?"
>
> -- 
> Dave Abrahams
> Boost Consulting
> www.boost-consulting.com