From: David Abrahams (dave_at_[hidden])
Date: 2004-02-22 06:20:53
I seriously have to wonder if I'm being trolled, here...
Christian Engström <christian.engstrom_at_[hidden]> 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.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk