Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Comparing C and C++ usage and performance with a real world project

nibblestew.blogspot.com

Post reply on HN
Print view View original

71–80 of 140 posts

Re: Comparing C and C++ usage and performance with a real world project

#71

Post by Joky »

khitchdee wrote: post #31
humanrebar wrote: post #24

Earlier quoted context omitted.

> It's only when you need protection and class heirarchies that C++ benefits you. Well, need is a strong word. You might not need better correctness while still coming out way ahead by using C++.

Protection implies a much more complex structure to represent an object and class heirarchies and inheritance imply the need for a runtime. Both these overheads come at a cost. It's the nature of the program you are wriitng that determines whether you will come out ahead. If you were writing a codec, say, you would not use C++.

Can you clarify what runtime needs would a class hierarchy have in C++ that a correctly structured C program wouldn't have?

Re: Comparing C and C++ usage and performance with a real world project

#72

Post by blub »

TickleSteve wrote: post #42
blub wrote: post #32

Earlier quoted context omitted.

Never freeing is sloppy, it means resource handling was likely not thought through. I would be concerned about non-memory resource handling in particular. If one must use this "trick", it's better to think things through, add the appropriate release calls and then somehow replace the release function with a no-op. Anyway, you're welcome to take a C++ project and translate it to a fast C project with fewer dependencie…

Never freeing is common practice in embedded systems where you should be pre-allocating all data (after worst-case analysis). This removes any possibility of fragmentation issues, etc. Many coding standards forbid dynamic allocation for embedded & real-time systems also for safety & reliability reasons. It is not unusual to have allocate-only heaps for exactly these reasons.

I agree, but the C idiom is to just not call free, without pre-allocating anything. It's an optimisation to avoid waiting for the resources to be released, with the idea that they will be anyway when the process is killed.

Re: Comparing C and C++ usage and performance with a real world project

#73

Post by khitchdee »

humanrebar wrote: post #49
khitchdee wrote: post #31

Earlier quoted context omitted.

Protection implies a much more complex structure to represent an object and class heirarchies and inheritance imply the need for a runtime. Both these overheads come at a cost. It's the nature of the program you are wriitng that determines whether you will come out ahead. If you were writing a codec, say, you would not use C++.

Not necessarily. A trivial scope guard initialized with a lambda has basically no overhead versus the equivalent be-really-careful approach in C.

That would be cruelty to the cat dancing on the hot tin roof.

Re: Comparing C and C++ usage and performance with a real world project

#75

Post by khitchdee »

Joky wrote: post #71
khitchdee wrote: post #31

Earlier quoted context omitted.

Protection implies a much more complex structure to represent an object and class heirarchies and inheritance imply the need for a runtime. Both these overheads come at a cost. It's the nature of the program you are wriitng that determines whether you will come out ahead. If you were writing a codec, say, you would not use C++.

Can you clarify what runtime needs would a class hierarchy have in C++ that a correctly structured C program wouldn't have?

Well, if you override the implementation of a function in a subclass, the runtime has to determine that and load it in at runtime, when you instantiate an object of the subclass. In C there is no runtime.

Re: Comparing C and C++ usage and performance with a real world project

#76

Post by astrodust »

nly wrote: post #70
aewnjfksd wrote: post #58

Earlier quoted context omitted.

> If C++ ever adopts the Pascal-style "module" extensions that have been kicking around in various proposals compile times could shrink by several orders of magnitude. I'm skeptical. Modules don't avoid the need for template instantiation.

Template instantiation surely only requires type substitution and re-running some analysis though. What makes C++ compilation slow is reparsing headers again and again and again because the C the preprocessor means that every time they are encountered they may have new semantics. The motivation for modules in C++ is similar to that of developing a Binary AST for Javascript, discussed on HN recently.

If modules ever happen, wow, C++ is going to feel like a whole new language. I remember large Pascal codebases compiling in as little time as it took to press the key, and this was in the era of computers with mere megabytes of memory.

Turbo C++ was never as "turbo" as Turbo Pascal.

Re: Comparing C and C++ usage and performance with a real world project

#77

Post by kitsunesoba »

userbinator wrote: post #60
andrepd wrote: post #50

Earlier quoted context omitted.

"Using C++" does not mean "Using lots and lots of features of C++ just because". That some people do that is hardly a criticism of C++, more of the lousy programmers that write software like that.

Unfortunately it seems that the majority of C++ code out there is like that. It could be said that C++ makes it far easier than C to introduce unnecessary abstraction and indirection, without realising the true costs. I've noticed that using a lower-level language, where abstractions have to be built explicitly, tends to cause one to rethink the problem and often come up with an even simpler and more efficient soluti…

I've only written patches of C++ in a couple of tiny projects, and something I've had trouble with in both cases is trying to figure out the somewhat objectively "right" or "best" way to write it. It's not a language I'm fluent in (the vast majority of my experience has been in Objective-C and Swift) so I find myself spending a good chunk of time doing research trying to figure out what the most widely accepted/correct way to do [insert thing] is in C++.

So if what's written here is true, I may be unwittingly baking bad practices into my C++ knowledge as a direct result of trying to accomplish the exact opposite…

Which leads me to the question: what is the "right way"? I've seen highly vocal critics of writing C++ as "C with extras", so I assume some middleground is where I need to target?

Re: Comparing C and C++ usage and performance with a real world project

#78

Post by nitrogen »

CJefferson wrote: post #62
blub wrote: post #26

Earlier quoted context omitted.

I have heard of calculating a "memory budget" and pre-allocating that, but calculating a "leak budget" and doubling that doesn't seem like hygienic programming.

The problem with counting leaks is it counts memory you need until the very end of your program. There is no point calling free as you are exiting anyway, and I have seen programs where freeing everything took .5 seconds as the program was closing.

As someone whose startup was probably hindered by an almost religious adherence to testing with Valgrind (hardware was way too slow), I'd still say finding the real leaks and bugs is a lot easier when you don't have the noise of "expected" leaks.

Re: Comparing C and C++ usage and performance with a real world project

#79

Post by ric129 »

khitchdee wrote: post #15

If you ignore the protection mechanisms and the class heirarchy built into C++, then a C++ class is like a C struct that can contain function pointers. For many programs this is all that's needed, and the amount of overhead involved in using such an approach to creating objects is obviously lower. So there's no question C will always be faster. It's only when you need protection and class heirarchies that C++ benefit…

Only virtual functions behave as you described, and even them don't exactly cause a function pointer to be stored in an object.

Re: Comparing C and C++ usage and performance with a real world project

#80

Post by jackmott »

kitsunesoba wrote: post #77
userbinator wrote: post #60

Earlier quoted context omitted.

Unfortunately it seems that the majority of C++ code out there is like that. It could be said that C++ makes it far easier than C to introduce unnecessary abstraction and indirection, without realising the true costs. I've noticed that using a lower-level language, where abstractions have to be built explicitly, tends to cause one to rethink the problem and often come up with an even simpler and more efficient soluti…

I've only written patches of C++ in a couple of tiny projects, and something I've had trouble with in both cases is trying to figure out the somewhat objectively "right" or "best" way to write it. It's not a language I'm fluent in (the vast majority of my experience has been in Objective-C and Swift) so I find myself spending a good chunk of time doing research trying to figure out what the most widely accepted/corre…

lots of people who have produced super high quality, money making software in c++ ignore almost everything advised by stroustrop and other modern c++ advocates. don't worry about it, just aolve your own problems.
Post reply on HN