Actually, I was going to bring up this point myself =). I do think that goto-less languages should put it on their todo list. Despite Djikstra's warnings on the harmfulness of goto, Knuth has shown that it can be used to create elegant algorithms. Steve McConnell, author of Code Complete, has an excerpt from his book on the subject that goes much further in-depth than I could.
But my point was that with this code:
[code] typedef mytype int;
void dosomething (mytype &m) { m = 5; }[/quote]
You would have to go back and insert function calls if you later decided to use a user-defined type. This drastically reduces the genericity of the code. Even though the result may be the same, you have to jump through a lot more hoops to bring it about.
I don't know about all of those compilers, but for a few (like g++ and VC++), the only unsupported important operation is 'export', which would require a restructuring of both C and C++ compilation methods. But you were concerned about 'template instantiation concerns', which is portable across all systems I've come across. If that weren't portable, those systems wouldn't be able to support the STL, a great deal of the C++ Standard Library, which would cause even more problems. The lack of export, while unfortunate, does not mean that most valid C++ template code is unportable, however.
Yes, g++ 3.x supports namespaces. Can't say for the other compilers, as I haven't used them recently.
Wait, I thought operator overloading precluded handling an error was what concerned you? Regardless of how you think C++ exceptions are implemented, that statement is false.
I agree, if there is not a valid operator for the operation, one should not overload an operator for it. Exceptions to this statement are when there are no valid functions either, as in input/output streaming, and when the operator is similar to what one has come to expect, as in overloading operator[] with a char * for an array index.
No, I never said that operator overloading was better than making function calls in all cases. I said that it is better when it meets a certain criteria, defined above. I do agree that inner product should be implemented as a function call. But I also think that multiplication (scalar and matrix) should be implemented as overloaded operators because it is far more intuitive and easy to genericize than the alternative.
I agree. But I don't think that the domain of bit-shifting is at all related to that of input and output. Or rather, it is at least as related as the original bit-shift operator and the relational > and <. Because of the finite amount of symbols in the western alphabet, nearly every operator has different meanings in different contexts. Is that # for number or # for sharp? ^ for XOR or ^ for raising to the power of or ^ to denote superscript? As you can see, just because it's possible to use the same operator on another object doesn't mean overloading that operator for a different object is necessarily bad. Especially when it has such advantages over the alternatives [more below].
Ah, but you've stumbled upon one of the major shortcomings of format strings. Namely, they cannot handle user-defined types. If poster_name() returns a 'string' object or something else, you would have to go back and insert convertors into every one of your output methods to convert it to the right type. Whereas with the cin/cout method, I simply change the return-type of my operation, and I'm done.
There are several libraries that solve the attribute problem by overloading operator<< so that one may use format-strings just as you do for printf(). These are immune to the problems I mentioned, though, because one should not insert the actual data using these formatters.
No, operator overloading does not "make you" choose an operator when a function name would be more appropriate. All it does is add more choice so that you can pick the best option available. Positing that an optional feature restricts choice more than languages that don't have such a thing is ridiculous.
I would be hard-pressed to say that I hated a particular feature, granted that it was really a feature (case insensitivity comes to mind). Anything that adds to my programmer's toolbox and increases the expressiveness of my code can only bring good, IMO. I think it's incredibly difficult to assert that a feature is always bad. Even case insensitivity has its uses =).
No, not at all. I said that if one were to assert that operator overloading was always bad (You said that they, along with templates, were an abomination: "No two developers agree what parts of C++ are an abomination. You use operator overloading and templates, two of my favorite whipping boys". But you also said that it was clean for math operations: "Using operator overloading for math is reasonably clean"), that it would ruin it for those of us that find the feature useful. I think it's perfectly alright, encouraged even, to actively advocate why one likes / dislike certain things, so long as one realizes that there may be untold uses for certain things.
No. Where did I claim this? I said that a language designer need not be concerned if there are potential abuses for otherwise useful features (that is, they should not be too concerned -- they should of course try to minimize the chances and impact of abuse).
|