Boost logo

Boost :

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


Dave Abrahams
Boost Consulting

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