Slashdot Mirror
An Interview With C++ Creator Bjarne Stroustrup
DevTool writes "Bjarne Stroustrup talks about the imminent C++0x standard and the forthcoming features it brings, the difficulties of standardizing programming languages in general, the calculated risks that the standards committee can afford to take with new features, and even his own New Year's resolutions."
So you have to be paranoid and check the class definition just in case.
So I have two responses to your general comment, though they are related.
You don't need to check the class definition at all -- you just need to know that one of the operands is an object. That's all. IMO, that's the only* difference between an overloaded operator call and a normal function call.
Once you're at that point, I don't see any difference between calling the function "+" and calling the function "doSomethingSimple". If you're paranoid enough about the class defining "+" in a way that will cause it to open sockets and thus you have to check the class definition to see if it does, you should be equally paranoid that "doSomethingSimple" will do the same thing and you have to check the class definition anyway.
The second part of my response is this: why do you CARE what "+" does internally? I can think of two reasons.
First, because you're concerned about efficiency. I've already said why I think this is a red herring, especially because I suspect most overloaded operator functions will be inlined to something efficient in general other way.
The second reason is because you want to know whether "+" is a good name for that function. But again I don't see how this differs from normal functions. If I call a function add and write a.add(b) instead of a + b, why are you more suspicious about the latter? I can come up with bad names without operator overloading plenty easily enough. Hell, I come up with bad function names for my non-overloaded functions far more often than bad function "names" for my operators. (And that even neglects the personal opinion that the normal convention of a.add(b) for a + b -- e.g. like what's used in Java's complex class -- feels wrong to me. a.add(b) feels way more like a += b than a + b to me. But again -- this isn't the fault of Java not supporting operator overloading per se, but rather the fault of Sun's function naming.)
* Okay, there is one other difference. Operator overloading is cool and tempting to use. It invites abuse way more than function naming does. But some high-profile cases aside (in particular, the proposal to overload the comma operator or whatever it was to load containers, a la Vector v = 4, 5, 6, 7, 8; or something), it certainly seems to me that, in practice, programmers are actually able to hold their tongues pretty well. Strangely enough, the biggest exception to this, I feel, is the bitshift overloading in iostreams. And IMO, that's easy enough to learn and brings about enough benefits (I/O type safety, non-repetition of type information, and extensibility vs a printf-style interface, and way less syntactic overhead vs repeated function calls) that it's probably the best solution even though it's not entirely satisfactory.