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

From: David Abrahams (dave_at_[hidden])
Date: 2004-01-05 11:20:51

"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