
"David Abrahams"
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