Operator overloading should not change the meaning of an operator
By
Martin Atkins
on February 15, 2007
BigInt(x) + BigInt(y) == BigInt(x + y) // Good
matrix1 * matrix2 = matrix3 // Good (as long as it gives the right answer!)
"z" + "q" == "zq" // Bad! This isn't addition! Why doesn't "z"-"q" work?
cout << "Hello, world" // Bad! What the hell?!
Agreed
25
14
64.1% 35.9%
Embed Claim
Make a related claim
Discussion (9)
Yeah, the choice of adding the meaning of "insertion" to << is really kind of weird. OTOH, << is really only meaningful on unsigned integers anyway. So it was available.
(And when I say "unsigned integers", I really mean "independent bit fields, usually implemented as unsigned integers".)
D'A
+ is the only sensible choice for concatenation
I would agree with this in a loose sense, but not in the sense given by the author in the fine print. Given an expression like "z"+"q", an answer of "zq" seems the most sensible one to me. You are adding the strings together, just in a peculiar way.
It gets a bit sticky when you're in a dynamically-typed language and you end up with "3" + 2, though. I'm looking at you, JavaScript.
I don't know a lot about programming languages compared to most of you, but in my humble opinion "3"+2 shouldn't be defined.
the meaning of operators is purely conventional, and as long as the new meaning is clearly defined, let them mean whatever you want.
I suppose it would be good to do something like this:
"z" + "q" == "zq"; //'+' signifies concatenation.
It's comments like the above that clearly demonstrate that you, Protagoras, are a fucking idiot.
D'A
So you think there is a mind-independent definition of operators?
you, D'A, are the idiot.