|
angelbob:
Yui:
How often do you debug other people's code?
angelbob:
Yui:
Knock yourself out:
angelbob:
Yui:
Yup. And yours is still an extra step, just invisible at the language level. I tend not to call that "user space" because I'm used to "user space" meaning "not kernel space".
Yui:
angelbob:
Yui:
In general I semi-agree with you. You can do this with void pointers but it's ugly. It works, but it's ugly. It's also far smaller (in the final binary size) since it doesn't duplicate all the code. It's also more portable since you don't have to worry about template instantiation concerns. And it tends to run faster since you have a smaller amount of code in cache. Plus it doesn't require the extra symbol space that templates do -- you'll note that VC++ generates constant extra errors in STL because the symbols are too long. But you're right, it's uglier, especially if you like angle-brackets.
Templates, though, are a syntactic answer to a semantic problem. Plus they have all the problems I mention in the previous paragraph. And I don't particularly like angle brackets more than stars, just personally :-)
angelbob:
Yui:
So you're not in favor of detecting errors at runtime, then? Operator overloading precludes handling an error if it's returned (because it can't be returned). If your function ever needs to return an error (*cough* stream output *cough*) then there's no good way to deal with this.
There are exceptions, but the way C++ handles those is just *evil*. I'm not saying they can't be done right, but C++ certainly doesn't. They're hard to bolt onto a language after the fact, and C++ barely even tries.
angelbob:
Yui:
Any operator which you can't do in C to a builtin data type has no clear operator name. So operator overloading, which only allows you to use the builtin operator names, has no clear way to name it. What's the correct operator to mean "inner product" for a matrix? How about "outer product"? For a vector, how about "cross product"? I've seen all of these as "*", incidentally. It's probably the best match for all of them. See why I don't trust "*" to be one specific thing?
Yui:
So you're saying that using operator overloading for any problem domain that the operator doesn't perfectly match is a lack of coder discipline? But we'll get back to cin and cout in a minute.
Yui:
The fact that it's possible to affect these things in ways that are invisible means that I have to look through all new submitted code before I can trust using it -- it's not obvious, looking at a declaration, what code is being called. It's not enough for me to set guidelines, there has to be a way to check it. One way to check it is for a function call to be syntactically obvious, so I can say "oh! a function is being called here."
No two developers agree what parts of C++ are an abomination. You use operator overloading and templates, two of my favorite whipping boys. Incidentally, if I were to restrict the use of templates in one of my C++ projects (I don't have any in C++, but let's pretend) then there would be folks like you complaining about that since I'd be "spoiling the broth" on that as well. Where do you draw the line?
I draw the line by saying "no C++". That means I never have to deal with a developer saying "yeah, you have to use templates and overloaded operators, but only on the stuff in my module."
angelbob:
Yui:
None. There is no operator that matches the problem domain so there should be no operator overloading for it. Remember when you said that an operator that doesn't match the problem domain should be renamed?
|