[boost] Re: Proxy --- an indirect container adaptor

From: David Abrahams (dave_at_[hidden])
Date: 2004-02-20 16:07:56

Christian Engström <christian.engstrom_at_[hidden]> writes:

> David Abrahams wrote:
>
>> Christian Engström <christian.engstrom_at_[hidden]> writes:
>> 
>>>
>>>Christian Engström <christian.engstrom_at_[hidden]> writes:
>>>
>>>But is the container really STL
>>>compliant if it has ordinary pointers as iterators?
>> David Abrahams wrote:
>> Yes. Many std::vector implementations do that.
>
> Right, this is exactly the kind of feedback I am looking for.  I'll
> amend the documentation so that it states as an additional requirement
> that the iterators for the underlying container must be classes.

I think you'll find there's little interest in such a component.

>>>>>Are we really allowed to define these operators like this? --Yes, we are.
>>>>
>>>>No you're not.  [...]
>>>
>>> Or else what?  
>> Or else the class doesn't satisfy the iterator requirements.
>
> Okay, I stand corrected.  Adding the following to the documentation
> should fix the problem:
>
> "A proxie_iterator does not fulfill the formal criteria for being an
> iterator according to the definitions in the STL

I think you'll find there's little interest in such a component.

> , since the relation
>
>    it->m == (*it).m == it[0].m
>
> does not hold true.  The expression  it->m  has the same semantics as
> it would for a Container<T>, whereas  (*it).m  and  it[0].m  have the
> semantics they would have for a Container< proxy<T> >.
>
> This means that the proxy_iterators may not work with algorithms that
> rely on any of these expressions.  However, since none of the
> algorithms in the STL library do

You have no guarantee of that.  They are allowed to call operator->
on their iterators.  Can't do much with them, but it's allowed.

> , all of the STL algorithms can be used without restriction."

False.  They are allowed to contain concept checks that cause
compilation to fail if you pass them non-conforming iterators.

>> Technically, anything that claims to depend on a parameter matching
>> the iterator concept.  Less, technically, any generic algorithm that
>> takes advantage of an iterator's operator->.  The fact that the ones
>> in the standard library don't use operator-> doesn't mean very much,
>> since other peoples' algorithms are allowed to rely on iterators
>> matching the standard iterator requirements.
>
> See above.
>
>>>[...]
>> Sure you can do whatever you want.
>
> Excellent, I think we are beginning to speak the same language ;-)
>
>> You just can't call it an iterator
>> (in C++).  The standard library defines what an iterator is.
>
> Right, I won't claim that it's an iterator in that sense.
>
>>>>The design makes several other wrong assumptions about iterator
>>>>requirements.
>>>>
>>>
>>>If you or somebody else can point them out to me I shall be very grateful.
>> I don't have time to look for all of them, but one assumption it
>> makes is that the underlying iterator supplies value_type,
>> iterator_category, etc. via nested public types as opposed to a
>> specialization of std::iterator_traits.
>
> Quite agree, there is nothing in the design as such that demands that
> implementation, I just did it that way because I don't know how to
> make it properly according to modern standards.

I think you'll find there's little interest in such a component.

>> Writing correct iterators is
>> really hard; that's part of the reason for the boost iterators
>> library.
>
> I know; that's part of the reason why I posted it here Boost ;-)

Cheers,

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