4 ms·
The argument boils down to the fact that C++ can express more in a single line of code than C can. a = func(b,c); .... Is it a function call, a member functi
by dkarl 17y ago
The argument boils down to the fact that C++ can express more in a single line of code than C can.
a = func(b,c);
....
Is it a function call, a member function call, or is it an anonymous constructor? Are b and c implicitly invoking copy constructors for other classes as part of type coercion? Is that a normal assignment, or an assignment operator? Is there a cast operator involved?
If it's such a complicated expression, then the equivalent C code would be correspondingly large and hard to understand, and it would be just as complicated to figure out its cost. The not-so-hidden cost of C is that even simple things end up being many, many lines of code. C++ was invented because certain kinds of C programs -- programs that were already being written in C -- were painfully verbose to express and complicated to change.
If writing your code in C would be simple and clear, then you would have to be stupid to write it as complex, obscure C++. When your C++ code gets complex and you start banging your head against a wall, imagine re-expressing it in C. If the result would be an improvement, then you screwed up. If you blame C++ for screwing up, then you're a language feature junkie. Admit it and check yourself into rehab.
That is the hidden cost. The mental model for a simple function call became incredibly large and complex, and every function call is potentially as complex. Which makes reasoning about performance a rather hard thing to do.... All that translates ultimately into either worse performance or longer development time. Neither one is something you like to hear about.
I don't know how it is a "hidden cost," because it's quite well understood that any reasonably expressive language can say more in a single line of code than C. Anyway, the size of the mental model of your program is what you should be worried about. C++ doesn't give you worse performance or longer development time. It gives you more choices for how you express your program. It means more different problems, because you can write C-style code and have C-style problems, or you can use the possibilities C++ offers and have different problems. If you already know that the choices forced on you by C are usually the right ones for your domain, then by all means apply that knowledge to how you write C++. For instance:
Worse, it makes profiling harder than necessary. All the type coercions that happen at the API level will show up as separate functions, not attributed to the callee, but the caller.
If you want them attributed to the callee, it's pretty simple. Do the coercions in the callee, just like you would have in C.
- groby_b 17y agoYour counterargument boils down to "use C instead". That is exactly what I am currently advocating. I don't blame C++ for screwing up - I blame it for being an ill-designed language that makes it easy to screw up. Any of the high-level features of C++ are well-implemented in any number of decent languages that don't obfuscate your code and incur horrible link times. And my argument (for game development) is that C++ is indeed the wrong language for the domain. In fact, I'd argue it's wrong for most, if not all domains. And I'm not exactly alone - I can't recall any prominent figure that actually thinks C++ is a decent language, except Bjarne Stroustrup. (Correct me if I'm wrong - I'd love to hear about it!) <blockquote> If you want them attributed to the callee, it's pretty simple. Do the coercions in the callee, just like you would have in C. </blockquote> The issue is that in many instances, I own the caller, but not the callee. And the person owning the callee can unintentionally make my code perform worse by simply changing the API. Or adding a destructor.
- aceofspades19 17y agoAnd you can make your code slower by changing it! Oh the horror. C++ is, imo, a good language for a lot of domains. What goes wrong is when people try to use all of the features that C++ offers instead of just using the ones applicable to their domain, eg. I don't think you would really want to use exceptions in embedded programming. If you are on a platform where performance is the key, then you should be careful of what you are doing. I think people are mostly blaming C++ instead of bad programmers.
- groby_b 17y agoThe point is not that I can make the code slower by changing it. The point is that it can get slower by changes to the API, without any changes to functionality.Made by somebody else, unintentionally impacting me. Let me ask you this: Have you ever worked on a large scale C++ project that didn't have performance issues? Or memory issues?
- blasdel 17y agoNone of what you've said is in any way specific to C++ APIs can easily lose performance when refactored for correctness or code clarity. Large projects have large project issues!