Duane Murphy wrote:
I've started doing a conversion of many old iterators to the new iterators. I also have been going through the docs, so I thought I would add a few comments.
No, I am serious. Looking at the iterator_facade doc, first of all it does not tell me what it is all about. The one sentence in the abstract is indeed very abstract.
Wow, good point.
The biggest thing missing for me is what the difference is between facade and adaptor. In particular when would you choose one over the other. I think i know the answer, but it wasn't clear that the docs explained that very well.
The answer is, ``you'd choose adaptor when you want to build a new iterator that's "just like" some other iterator in some of its behaviors, but (usually) different in some others.'' Yes, seeing that could help.
I would like to see more examples, if that is possible.
Hm. Examples of what?
The example with details shows a forward iterator that can also be used as an adaptor. Clever for continuity, but reality is seldom that cooperative.
You might be surprised to learn that I didn't plan it that way. I said to myself, "I need to build a simple iterator. Probably the simplest thing I can imagine is a linked list iterator. Okay... Hey, that same iterator could be built pretty well with iterator_adaptor after all!"
I would like to see a full random access facade. For example: build the full suite of four iterators for std::vector from the outside of std: :vector. That is assume std::vector had no iterators; how would iterators be implemented?
Well, that's really uninteresting. You'd use pointers, and if you didn't like pointers you'd use iterator_adaptor over the raw pointers, with no behaviors implemented. You'd never implement the two reverse iterators using iterator_facade because according to the standard they're required to be built from std::reverse_iterator, and even if you didn't do that you should build them using boost::reverse_iterator.
I hope this didn't sound rude, I know it must be hard to write a doc for such a complicated library.
Yes, but that usually means the library needs to be simplified ;-)
I have found boost::iterator to be awesome. Using boost::iterator to build new iterators is actually easier than the docs seem to make it out to be. It seems like it might be a case of "you can't see the forest because of the trees."
Might be. But actually I think we have some serious usability problems. The way defaults are computed in this library is very complicated, to the point that documenting it is nearly impossible. We should revisit that problem starting from the specification side and then proceeding to coding. The authors of this library are somewhat swamped and burned out on it at the moment, so if anyone would like to volunteer to help with these improvements (I mean with the authors' participation) they'd be more likely to get done. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com