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

From: David Abrahams (dave_at_[hidden])
Date: 2004-01-09 11:20:14

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

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

You also wrote:

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

Which I took to mean that you thought my solution was too complex, and
far more complex than what you started with.

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

It's not a corner case (you *are* adapting an iterator), and my
response wasn't intended to suggest it was.  All I was suggesting was
that your approach of using derivation to produce an iterator from a
const_iterator was much more complicated than what I posted.
Admittedly, my code was untested (and so labelled), but with a little
investment in reading the specification, I'm sure you could've made
the minor fixes I supplied.

> 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'm sorry, I was saying "don't do that" about defining new iterators
by deriving them from other iterators.  Was that unclear?  I am very
confused at this point, since I don't see why it has any relationship
to the misunderstanding 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.

Yes, thanks.  We already understand what needs to be done, basically,
but I appreciate you taking the time to let us know.  We are under a
lot of pressure with a boost release coming up and many issues
surrounding these proposals in the standards committee.  That,
combined with fending off hostility from one particular committee
member is probably making me touchier than neccessary.

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

Your questions weren't dumb.

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

Not that I know of.  Calling it a joke doesn't make it less offensive
though.  Suppose I suggested that you were just demanding better
documentation so that you could understand the library well enough to
write an article claiming you came up with all the ideas and then we
stole them from you? ;-)

See what I mean?

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