Re: [boost] [iterator] indirect_iterator->

From: David Abrahams (dave_at_[hidden])
Date: 2005-11-20 08:12:09

"Orjan Westin" <orjan.westin_at_[hidden]> 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-iterator-models

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