From: Topher Cooper (topher_at_[hidden])
Date: 2004-07-12 13:15:29
Putting my two cents in on the issue of redefining the meaning of
Summary: Bad idea.
The redefinition of "operator<<" for the I/O libraries is an entirely
different situation. Before that was done, the specific meaning of the
operator depended, however simply, on polymorphic resolution of the
left operand. Use of the operator for streams -- though frequently
confusing at first until it became, effectively, an accepted part of
the language -- simply extended this fact rather radically. The
complete meaning of the operator was now different rather than simply
some of the details, but this is within the continuum of meanings.
Now, as before, to understand what the operator meant -- if anything --
you examined the class of the first operand.
The situation is very different for "operator," however. Sans
redefinition it has a well defined meaning for every object that
(despite the formal situation) is varied (and only in the matter of its
return type) only through the *second* operand. Seeing an expression
of the form "x, y" there is no interpretive moment equivalent to
stopping to think just what it means to "shift an output stream left."
As it stands, "x, y" has a clear meaning -- evaluate x then evaluate y
and use the latter as the value of the complete expression -- UNLESS
someone somewhere has overloaded the operator.
Overloading "operator<<" as in the I/O libraries *extends* its meaning.
Overloading "operator," redefines its meaning.
Are people aware of the ordering implicit in the *normal* usage of the
"," operator? Of course, look at how it is taught. It is described as
a sort of "weaker" version of ";" that can be used within expressions
without terminating the statement the expression appears in. Do they
understand the sequential nature of ";". Of course. Do they
understand the sequential nature of ",", at least in many cases, if
they remember that "," within expressions exists at all, they remember
that it acts sort of like ";" and therefore they probably understand
its sequential character.
Overloading "operator," is something like overloading "operator==" to
mean something entirely unrelated to equality or equivalence -- only
Looking at this from another viewpoint: If there is no standard that
allows generic programmers to assume that "operator," can be assumed to
act according to its "default semantics", then they should stop using
"operator," except to make use of some specifically overloaded
semantics. Otherwise, the generic code is indeterminate (OK, you could
use it by being very careful that no value dependent on a generic type
was involved, but you would still be simply hoping that no one had
added an overload involving one of your non-parameterized types).
I strongly recommend that "operator," not be overloaded. If it is
decided that this is absolutely essential, then I recommend that a
strong and precise statement first be drafted stating unambiguously
when such overloading should be "acceptable".
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk