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

"Keith MacDonald" 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 struct Node { Node* next(); Node* prev(); Node const* next() const; Node const* prev() const; }; template <class V> struct iter : boost::iterator_adaptor { typedef boost::iterator_adaptor super; iter() {} template <class V2> iter(iter<V2> const& x, typename boost::enable_if_convertible::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