Live data from Hacker News

The Hidden Cost of C++

rachelslabnotes.com

11–20 of 66 posts

Re: The Hidden Cost of C++

#11

I fixed a single line of code that drove our embedded processor to 50% cpu - it called 5 ctor/dtors. Changing it to a ref arg with a ref return, and dropped to under 10%. And yes, class defs had to be redeclared, the line of code was unchanged. Very indirect, utterly beyond the original authors comprehension.

Thus proving it's possible to write crap code in any language.

Re: The Hidden Cost of C++

#12
post #11

I fixed a single line of code that drove our embedded processor to 50% cpu - it called 5 ctor/dtors. Changing it to a ref arg with a ref return, and dropped to under 10%. And yes, class defs had to be redeclared, the line of code was unchanged. Very indirect, utterly beyond the original authors comprehension.

Thus proving it's possible to write crap code in any language.

Well, yes. The point here is that C++ makes it much easier to generate crap code.

Re: The Hidden Cost of C++

#13
post #10

There are constructors in C++. The water is wet, how sneaky of it. You either know the code you are working with or you don't. C++ or not.

What he is pointing out is that C++ makes it harder to 'know the code you are working with'.

FWIW, I think you meant to say "what she is pointing out"...

Re: The Hidden Cost of C++

#14
post #8

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 express…

Your 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!)

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.

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.

Re: The Hidden Cost of C++

#15
post #3

And the hidden cost of using Java is that there is a JVM! These are only hidden to developers who don't really know C++. If you have virtual functions everywhere and have api that encourages copy or anonymous constructors you get what you asked for. And any profiler worth its salt should be able to show you what is really happening so you can quickly fix it. For a game shop who is worried about performance there are…

Yes, there are many things I could do. Once I'm done with writing all that boilerplate, I'm more or less down to C code with nice namespaces.

Re: The Hidden Cost of C++

#16
post #5
post #3

And the hidden cost of using Java is that there is a JVM! These are only hidden to developers who don't really know C++. If you have virtual functions everywhere and have api that encourages copy or anonymous constructors you get what you asked for. And any profiler worth its salt should be able to show you what is really happening so you can quickly fix it. For a game shop who is worried about performance there are…

I'm pretty sure the author was comparing C++ to C, not to Java, but that's kinda beside the point, because as the article says, "The real hidden cost is that now, instead of looking at one piece of source -- the function itself -- I need to look at up to four different classes. Add possible ancestors to find out if a call is virtual." Put another way, the performance details we so often care about in projects for whi…

> Also, reasoning about the performance of C is all well and good right up until you realize that your compiler is better at translating C to assembler than you are

The difference being that in this case, the code performs better than I assumed. Nobody minds that. In C++, the usual results are that it performs worse than assumed. Significantly worse.

> some jackass wrote a preprocessor macro called "foo" which does 18 different things

Yes. There is that. Thankfully, they are rare. (I'd rate the preprocessor as by far the worst part of C. Amongst other things, it costs us any number of tools that could help us reason about code)

Re: The Hidden Cost of C++

#17
post #8

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 express…

Second part of my reply...

    The not-so-hidden cost of C is that even simple things end up being many, many lines of code
Yes. If I care about performance, that is a good thing, because I immediately know the cost.

>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

That is certainly true, but I think C++ has outlived its usefulness and is coasting on momentum.

> Anyway, the size of the mental model of your program is what you should be worried about.

If you can keep 2.5 million lines of code in one single mental model, congratulations. I can't. I don't know anybody else who can. Game code bases, for better or worse, are fairly large, so we need to reason about subsets of it.

This is where the C++ problem comes to bear - I have no direct control and knowledge of all classes involved in a particular computation. Yes, I can look them up - but not everybody does. And I'm concerned with building shipping products with a normal team, not some hypothetical team of superstars.

Re: The Hidden Cost of C++

#18
post #14
post #8

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 express…

Your 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++…

And 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.

Re: The Hidden Cost of C++

#19
post #9
post #6

Earlier quoted context omitted.

Pop Quiz: Why should I clutter my brain with these little guessing games about what the compiler is doing? And why should these pop quizzes slow down my group's code reviews? There are, after all, languages out there that do not force this insanity on us. The alternative for performance-critical applications is not Java, but C. C remains surprisingly tough competition after all these years for those rare pieces of so…

Ugh. Try attacking the vector math required for most games programming these days in C, using macros and magic instead of classes and templates and operator overloading. I'd rather blow my own leg off with a bit of C++ any day.

[deleted]

Re: The Hidden Cost of C++

#20
post #8

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 express…

Expressiveness in a single line of code is such a stupid metric.

magic()

What's that? It's a function call. What does it do? Anything. Everything. Why does it need a complex grammar? It doesn't. Spend your time thinking about the problem, not the language. What a concept!

Do simple things take many lines of code in C? Yes. If you only have a few data structures and algorithms in your mental toolbox, simple things will take many lines of code in C, or C++, or in any language. Why do people advocate baroque languages by claiming that you cannot do simple things simply except with baroque languages, and then blame people for complicating their programs by using that baroqueness?

Yeah, C++ programmers are feature junkies; the language is designed by a feature junkie and promotes language features as the solution to every problem. If you go against that, you are going against the whole culture.

If PL/I was the fatal disease, C++ is the shambling corpse.

Post reply on HN