Boost logo

Boost Users :

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

> 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>
      boost::iterator_adaptor<iter<V>, V*, V, boost::bidirectional_traversal_tag>

    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;

    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

> 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

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at