Christian Engström <christian.engstrom@glindra.org> writes:
David Abrahams wrote:
Christian Engström <christian.engstrom@glindra.org> writes:
Christian Engström <christian.engstrom@glindra.org> 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