David Abrahams wrote:
Christian Engström <christian.engstrom@glindra.org> writes:
A proxy_iterator is publicly derived from the iterator of the underlying Container< proxy<T> >.
And if that iterator happens to be a pointer?
Then of course it doesn't work. But is the container really STL compliant if it has ordinary pointers as iterators? If the answer to this question is yes, the requirement that the underlying iterator type must be a class should of course be added to the documentation, but apart from that I see no problem with it.
Are we really allowed to define these operators like this? --Yes, we are.
No you're not. The standard makes it very clear that the semantics of an iterator's operator-> must correspond to those of its operator*.
Or else what? Is there anything particular that the standard says will break if the two operators have different semantics? In Bjarne Stroustrup's "The Design and Evolution of C++", he says on page 241 (in the edition that I have): "For ordinary pointers, use of -> is synonymous with some uses of unary * and []. For example, for a Y* p it holds that: p->m == (*p).m == p[0].m As usual, no such guarantee is provided for user-defined operator. The equivalence can be provided when desired: [...]" The way I read it, the phrase "can ... when desired" does not have the same meaning as "must always". Am I misunderstanding something or is Bjarne Stroustrup wrong?
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.
indirect_iterator may already suit your needs.
Does indirect_iterator make possible to convert a program that has been written to use a direct container to use an indirect container instead by changing a single typedef? /Christian