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

"Keith MacDonald" writes:

"David Abrahams" wrote in message news:uu13545id.fsf@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