Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2005-02-15 10:17:39

Thomas Witt <witt_at_[hidden]> writes:

> Dave, Thorsten,
> David Abrahams wrote:
>> "Thorsten Ottosen" <nesotto_at_[hidden]> writes:
>> It has been pointed out that this sort of thing would be very much
>> easier if, like iterator_facade and iterator_adaptor, all the
>> specialized adapters could accept one more optional parameter that
>> specifies the most-derived iterator class. I think that's a good
>> idea, but I'm not sure how to do it without making the interface
>> overly complicated. Ideas? I don't want to go back to the "bad old
>> days" of named template parameters.
> I can see this being usefull, but deriving from an iterator is such a
> no-no that creating a optonally derivable iterator somehow seems wrong
> to me.

What you're saying is that giving people a way to do it correctly will
encourage them to do it incorrectly, and therefore we shouldn't?

> We could add another level of indirection and introduce
> xxx_iterator_base<Derived, ...> types. And no I don't consider this
> a very bright idea either.

The problem is that the previous version of the library using the
policy adaptor pattern _had_ this capability, because you could grab
the policies class that each adaptor published as part of its public
interface, and derive a new policies class from it.

> With respect to iterator lib maintenance. Me personally I don't feel
> confident in making changes as I don't have a good feeling on what
> is really needed or what the correct solution will be.

But you know what you _don't_ like ;-)

>> In fact, the way default types are calculated and specified in the
>> iterators library is just too complicated and needs to be re-examined.
> This directly relates to what I said before. The whole area of
> iterator categories is so murky currently. IIRC there are
> outstanding DRs

DRs? Do you mean against C++03 iterators in the standard?

> and issues that where never really resolved. In general I do agree.
>> The whole iterators library needs some attention, but there just
>> hasn't been time for me recently. Jeremy is working on his PhD, and
>> Thomas has allowed his professional life to get the better of him ;-).
> Yeah having to work for a living really makes your live miserable ;-).
> Seriously I will have more time to deal with these things starting now.
> I.e. I am open to input I just currently don't have any good ideas on
> how to improve the whole thing.

Well, maybe we need to return to policy adaptors, with a hybrid

   class my_iterator
      : public iterator_facade<my_iterator, my_policies>
       // c'tors here

But ultimately, I think we do need some way to allow users to
conveniently refine the existing adaptors, and we need to do it
*before* template aliases show up in their compilers!

Dave Abrahams
Boost Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at