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

From: Christian Engström (christian.engstrom_at_[hidden])
Date: 2004-02-20 12:34:18

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.

>>>>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, 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, all of the STL algorithms can be used without 
restriction."

> 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.

> 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 ;-)