Boost logo

Boost :

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

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

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