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

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" wrote in message news:u4qvatli4.fsf@boost-consulting.com...

"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