From: David Abrahams (dave_at_[hidden])
Date: 2004-07-07 12:35:11
"Andrei Alexandrescu \(See Website for Email\)" <andrewalex_at_[hidden]> writes:
> "David Abrahams" <dave_at_[hidden]> wrote in message
>> IMO it's only a valid coding standard if you also have a coding
>> standard that says "operators must always act the same on user-defined
>> types as they do on the builtins" -- which I would never accept ;-)
>> Probably the right standard is:
>> "If you're trying to define operators that act like the
>> builtin ones, beware the overloading of operator,, operator&&
>> and operator||, because you can't get identical semantics".
>> But then, why would anyone want to overload operator, other than to
>> change the semantics??
> That argument doesn't hold water. You do want to change the semantics, but
> not in ways that can be confusing or introduce subtle
Can you think of one change to the semantics of operator, that _can't_
be confusing? Or any operator for that matter? And the "subtle
nonportabilities" you're referring to are introduced by every
expression whose order of evaluation is unspecified (of which every
real program contains many).
My point is that it's unlike any other operator: the built-in comma
works on any type, even UDTs. So if you need sequencing, just use the
built-in one. If you want it to do something else, go ahead and
> Unlike all other overloadable operators, the three operators you
> mention have special regime in the way they evaluate their
> arguments, regime that cannot be emulated with regular function
That was what I meant by "you can't get identical semantics".
> That being said, I take it your answer was (a): it is an obsolete
> coding standard.
I didn't give a straight answer because saying it's obsolete presumes
it was once valid... and I don't see that anything has changed to
make it more or less so.
> Thanks. Any other votes and opinions are welcome.
I'll be silent now so someone else can reply. Ciao,
-- Dave Abrahams Boost Consulting http://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