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

Post by CJefferson » Sun, Sep 03, 2017, 6:33 PM UTC

blub wrote: post #26

jgh wrote: post #7

Earlier quoted context omitted.

Reminds me of this anecdote I came across on the internets one time: https://groups.google.com/forum/message/raw?msg=comp.lang.ad...

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.

Post by inetknght » Sun, Sep 03, 2017, 6:36 PM UTC

andrepd wrote: post #53

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…

That is absolutely false. C++ member functions are zero-cost abstractions, i.e. they have the same cost as any other function call. Member functions are _not_ function pointers that reside inside the struct. They don't take up space, they don't need dereferencing to call. They are just "syntatic sugar" to group functions more logically.

Post by khitchdee » Sun, Sep 03, 2017, 6:41 PM UTC

andrepd wrote: post #53

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…

That is absolutely false. C++ member functions are zero-cost abstractions, i.e. they have the same cost as any other function call. Member functions are _not_ function pointers that reside inside the struct. They don't take up space, they don't need dereferencing to call. They are just "syntatic sugar" to group functions more logically.

Post by bch » Sun, Sep 03, 2017, 6:43 PM UTC

coldtea wrote: post #41

bch wrote: post #10

Earlier quoted context omitted.

> As for the "memory leaks" --- I haven't looked at the source, but something whose runtime is very short-lived, like pkg-config, may be very well justified in allocating and never freeing, letting the process exit itself be the "ultimate free". I've seen and done this many times myself. This makes sense, and then somebody has a vision for a use case beyond the original imagination, goes to turn the code into a libra…

> This makes sense, and then somebody has a vision for a use case beyond the original imagination, goes to turn the code into a library and spends countless hours smartening up lazy resource management. That's THEIR problem then. Why should the original author care for that?

Post by nly » Sun, Sep 03, 2017, 6:48 PM UTC

aewnjfksd wrote: post #58

astrodust wrote: post #44

Earlier quoted context omitted.

The problem, by and large, is that C++ is heavily dependent on header files to implement the Standard Library. It's largely templated, which means there's no way to make a pre-compiled version, the code generated varies wildly depending on the types involved. C has relatively simple header files, they usually contain structs, function signatures, and a bunch of macros. They're easy to parse and apply by comparison, p…

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