|
Boost : |
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk