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

From: David Abrahams (dave_at_[hidden])
Date: 2004-01-06 09:59:17

"Keith MacDonald" <boost_at_[hidden]> writes:

> 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:

We're working on the docs.  That document is the standards proposal,
but the Boost (user-level) docs aren't complete yet.

> "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.  

I quote:

  The iterator_adaptor class template adapts some Base 3 type to
  create a new iterator. Instantiations of iterator_adaptor are
  derived from a corresponding instantiation of iterator_facade and
  implement the core behaviors in terms of the Base type. In essence,
  iterator_adaptor merely forwards all operations to an instance of
  the Base type, which it stores as a member.

  [3] The term "Base" here does not refer to a base class and is not
  meant to imply the use of derivation. We have followed the lead of
  the standard library, which provides a base() function to access the
  underlying iterator object of a reverse_iterator adaptor.

  The user of iterator_adaptor creates a class derived from an
  instantiation of iterator_adaptor and then selectively redefines
  some of the core member functions described in the table above. The
  Base type need not meet the full requirements for an iterator. It
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  need only support the operations used by the core interface
  functions of iterator_adaptor that have not been redefined in the
  user's derived class.

> For example, if you add the statement
> "++x;" to your example, it fails to compile.

Umm, sorry.  I whipped that one off without too much testing. I've
enclosed a fixed one.



> 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.

Why would you need to develop either of those?  You just follow the
formula.

> 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.

I'm sorry, I need you to be more specific.  Is the example of your
node iterator good enough?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com