[boost] Re: [iterators] request for utility iterator

From: David Abrahams (dave_at_[hidden])
Date: 2005-02-18 10:40:05

Thomas Witt <witt_at_[hidden]> writes:

> Dave,
>
> David Abrahams wrote:
>> Thomas Witt <witt_at_[hidden]> writes:
>> 
>>>
>>> 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?
>
> What I was trying to say was that I'd prefer to see a solution that 
> provides the desired functionality without having the user derive from 
> what otherwise is a valid iterator.

Well, of course it wouldn't be a valid iterator.

  transform_iterator<derived_is<whatever>, ... >  // using named param syntax

isn't a valid iterator by itself.

>>>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.
>
> Well that's actually more like deriving from xxx_iterator_base.

Yes, I was only talking about the capability -- not the means for
getting it -- and saying why we need to do _something_.

>> But you know what you _don't_ like ;-)
>
> Yep. I just try to be unhelpfull in a sophisticated way ;-).

Ever the urbane sophisticate, ain'tcha?

>>>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?
>
> I am mostly referring to iterator_categories here. IIRC not all
> issues that came up during the iterator adaptor discussions are
> resolved yet.

So you don't mean DRs.  That's a whole other ball-o'-wax.

>> Well, maybe we need to return to policy adaptors, with a hybrid
>> approach:
>>    class my_iterator
>>       : public iterator_facade<my_iterator, my_policies>
>>    {
>>        // c'tors here
>>    };
>
> Wasn't that one of the original design ideas that was ruled out due to 
> ... ? If only I could remember what the rationale was.

I honestly don't know.  I think it's quite possible that we never
distinguished the use of policies in the old design from the problems
caused by not using CRTP.

>> 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!
>> 
>
> Agreed

Well, at least we agree there's a real problem.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com