Boost logo

Boost Users :

From: Keith MacDonald (boost_at_[hidden])
Date: 2004-01-06 06:58:14

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" <dave_at_[hidden]> wrote in message
> "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,
> {
> typedef
> boost::iterator_adaptor<iter<V>, V*, V,
> 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
> > const_iterator and iterator, which are independent of each other, except
> > that a const_iterator can be constructed from an iterator.
> > this does not seem to the intended way to do it, but it would probably
> > 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