I may have misunderstood the purpose of boost::iterator: I was expecting it to make it easy to add standard conforming iterators to any container, but the complexity of the proposed solution, (using iterator_adaptor, which I can't get to compile), is making me doubt that. In an earlier release of the library, I was able to declare the const_iterator using iterator_facade, then simply adapt it to a non-const iterator using iterator_adaptor, as shown in my original posting. 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? 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. 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? Thanks, Keith MacDonald "David Abrahams" <dave@boost-consulting.com> wrote in message news:u65frftpp.fsf@boost-consulting.com...
Looks like a job for iterator_adaptor:
// untested 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> x, boost::enable_if_convertible<V2*,V*>::type* = 0) : super(x.base())
friend class iterator; friend class boost::iterator_core_access;
private: void increment() { base() = base()->next(); }
void decrement() { base() = base()->prev(); } };
typedef iter<Node> iterator; typedef iter<Node const> const_iterator;
HTH,
-- Dave Abrahams Boost Consulting www.boost-consulting.com