"Orjan Westin" <orjan.westin@gmx.net> writes:
No, something was wrong with my question, and possibly the documentation. I've made a little test to confirm it, and it works as it should.
You're right; the documentation is wrong, or at least very obtuse. In the synopsis for indirect_iterator, it only shows the parts of the interface that are added to what it inherits from iterator_adaptor, and iterator_adaptor is not shown as a base. The only hint you have is in: http://www.boost.org/libs/iterator/doc/indirect_iterator.html#indirect-itera... which, in combination with the standard iterator requirements, actually tells you that operator-> is present.
Just out of curiosity, do you ever think you (and the "you" here is the boost community, not you David) fall for the temptation to do things more powerful and complex than they need be?
Why would that be tempting?
Just looking at the <counts> 14-18 includes in indirect_header.hpp is a bit scary, really
Why? Most of those headers define a single component whose name corresponds exactly to the header name. Would you rather see #include <big_mess_o_stuff.hpp> instead?
, and personally I found the code a bit hard to follow.
The first motivation in producing the library is to make it as useful and useable as possible. Occasionally code clarity suffers. However, in this case -- aside from more comments which would be nice -- I can't see how the clarity could be improved. I certainly don't see how fewer #includes would aid clarity.
This is not unique to the iterator library either - I often get a feeling when looking at things in boost and other publicly accessible libraries that things are somethimes done not so much because that's what needs to be done, but because they are interesting, technologically challenging or cool. I know I sometimes find myself overengineering simply because I think "wouldn't it be cool if..."
Feel free to design something simpler that works just as well, if you think it can be done. Often, to provide easy-to-use interfaces, libraries need to do complicated things in their implementations. The fact that the docs were not quite adequate in this case aside, users are expected to understand the libraries from their documentation. Libraries are not written primarily so that users will be able to understand their implementations, but so that they will provide users with the best service. -- Dave Abrahams Boost Consulting www.boost-consulting.com