I seriously have to wonder if I'm being trolled, here... Christian Engström <christian.engstrom@glindra.org> writes:
Okay, so a more accurate way of describing the problem would be:
"Due to a glitch in the formal specification for iterators in STL, algorithms are allowed to place semantic restrictions on the -> operator when it exists, even though the algorithm can never acutally use the operator in question, since is not actually required to exist at all.
And what about a third-party algorithm that iterates over classes and happens to use operator-> ? That's no bug?
The proxy_iterator:s may not work with STL implementations that deliberately take advantage of this glitch to do over-reacing concept-checking for concepts that they do not actually require. It is not known if any such implementations actually exist or are in common use."
Are you trying to write a library (if not, this whole discussion is OT), or is this just for yourself? How long do you think this list of exceptions has to to be before the component is of no interest to anyone other than yourself? After you responded to "it's not an iterator" with one caveat, my eyes glazed over (not to mention, "I just did it that way because I don't know how to make it properly according to modern standards"). I'm sure it won't take most people much longer to realize that it's obviously not built "properly according to modern standards" when they see a list of 3 or more subtle/not-so-subtle ways in which it isn't an iterator. It took me about 3 seconds to notice that your iterator is broken in another way: it assumes the operators on the underlying iterators are implemented as member functions and not free functions. I have no idea how many more of these issues are lurking. Why you wouldn't just build a conforming iterator the easy way is beyond me. I think I'm all done here; good luck in the future. Cheers, Dave -- Dave Abrahams Boost Consulting www.boost-consulting.com