[Boost-users] Re: Converting from consttonon-constwithiterator_adaptor

From: Keith MacDonald (boost_at_[hidden])
Date: 2004-01-09 09:55:55

"David Abrahams" <dave_at_[hidden]> wrote in message
news:uu13545id.fsf_at_boost-consulting.com...

> The problem I'm having is seeing how to keep users from feeling
> misled by the statement that apparently misled you.  Even if
> iterator_adaptor can be used to adapt non-iterators, that *is*
> a corner case.  We'll be telling people to use iterator_facade
> when they're not starting with something very much like the
> iterator they want to end up with.

Well, if we go back to my question that started this thread, I asked:

"I'm stuck trying to use iterator_adaptor from the CVS head.  I
simply want to derive a non-const iterator from a const one derived
from iterator_facade, as shown in the code below."

And you replied:

"Answer: don't do that.  Making iterators by derivation from other
iterators is almost always an error (and in your case also: for
example the return type of operator++ is wrong on the derived
iterator).  Make a new constant iterator type with iterator_facade.
If you do it right, it will interoperate properly with your mutable
iterator.
<snip>
Looks like a job for iterator_adaptor."

I had problems compiling your suggested solution, so, I replied:

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

And you responded:

"Is that what your posting was doing?  And you think that's simpler than
what I did above?"

I'm afraid that I did not deduce from that that this was a corner case.  If
your introduction to iterators is from using them with standard library
containers, it's natural to want to do the same things with your own
containers, to lever the power of the standard algorithms.  If the first
time you try, an expert says "don't do that", there is plenty of scope for
the misunderstanding that followed.

> I think it's fair to let me know that the docs could be
> improved, but before the library has even entered a Boost
> release this amounts to harping on it

I was commenting on the documentation that I have before me, and assumed
that that was what you were working on.  Therefore, I assumed that you would
be open to suggestions as to how to improve it,  _before_  it is released.
Given the above, I would now like to see a separate section on how to use
the Boost.Iterator library to implement bidirectional and random access
iterators (both const and non-const) for simple containers.  That may well
satisfy the requirements of more than half the potential users of this
library - which should cut down on the number of people asking "dumb"
questions, like me.

> I'm sorry, I realize that part of your post was trying to be helpful,
> but I have a hard time seeing how your veiled accusation that we're
> keeping the workings of the library secret so that we can sell books
> is anything other than a cheap shot.

It was meant as a joke - hence the use of the smiley.  Is there a better
convention for indicating jokes in email?

Keith MacDonald