Quite often. Now what does that have to do with anything? Or are you telling me that since other people do bad things, we should automatically take away all things that have the possibility of being bad?
How could a language possibly add support for ths? This is basically constructing a type from the data of its parent types. But for a language to add support for this, they would have to know how this construction is handled! I think the existing functionality is more than adequate to handle something so simple.
It's quite visible at the language level. But not the user of that library's level. I'm not sure about you, but I use the objects in libraries far more often than I write them, so the 'extra' step ends up paying for itself the moment I use it more than once.
Nope, you can't even do this with void pointers. You would still have to overload an operator. And how would the function know which type to cast as to perform the operation?
If I have a performance problem, I'll profile. Debugging symbols add far more to my binary size than templates do, and I usually keep those in for safe measure. Maybe when we're talking about performance problems will these points be valid.
So when I use a compiler that doesn't support the standard formalized *5 years ago* I'll worry about this ;). Until then, unless I'm writing code for ancient SCO machines, I'll continue to use the feature that's been in every compiler I've ever used across dozens of platforms.
Coupling the error system to the *return type* of the function is stupid. What do you do if you have a legitimate return type but an error condition may also be raised? Exceptions are the answer. And even if you don't like C++'s implementation of them, they work very well for the vast majority of people that don't bother with what is almost always an insignificant performance issue.
No, you even gave an example of a user-defined data type that had a clear operator name in that of operator* for multiply. Your later attempting to show how people overload this for inner and outer product only shows that these people wrote bad code, not that overloading operator* is bad in all cases. Of course you don't trust operator* to be one specific thing, but I've seen factorial() functions that compute the sum rather than the factorial. Therefore using your logic, we should all never use functions, or any abstraction at all. See where the argument falls apart? Overloading operators are no different than any other kind of abstraction, excepting the bizarre stigma you've attached to them.
Yes. But you don't seem to understand that cin/cout, and even plain function calls don't match the problem domain for input/output streaming. It has no defined domain like mathematics does. Therefore they're fully justified in coming up with operators to make it more conveniant to use. Just like the mathematicians of old came up with special characters -- operators shall we say -- to represent certain operations. Going against the problem domain is a lack of coder discipline; tackling an undefined domain and making it more managable is a sign of the opposite.
This is what 'abstraction' is all about! It's not obvious, looking at a function declaration, what code is being called. But any programmer knows that he needs to make an assumption that the name of the function conveys this necessary information. Likewise, when a programmer is working with a class he needs to make an assumption that the type of class *and* the operator being used conveys this necessary information. If it does not, then the operation or the class needs to be renamed. This is a very simple concept.
No two developers agree on how many spaces to indent -- or even if spaces should be used at all in place of tabs -- but that's no excuse for avoiding coming up with coding standards for it on a large project.
Umm. Let's see here:
1) I say that restricting a feature from an entire language because some can do wrong with it is "spoiling the broth".
2) You say that restricting a feature from your own project because some can do wrong with it would have people like me claiming that it is "spoiling the broth".
Do you see the fallacy now? There's a staggering difference in scale between a *language design* and your own project's guidelines. You are free to do whatever you'd like in your own project. But the moment that you step out of your bounds and claim that since you have never seen a great use of something, then mandate that it is useless for everybody else is the moment that I cry foul.
reply.output(poster.name());
reply.output(", you're saying we should not use operator overloading for output streaming?\n");
reply.output("Well, ");
reply.output(poster.name());
reply.output(", I guess we disagree.\n");
|