"Andrei Alexandrescu \(See Website for Email\)" <andrewalex@hotmail.com> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:u7jtf3hxn.fsf@boost-consulting.com...
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 nonportabilities.
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 overload.
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 calls.
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