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

121–130 of 140 posts

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

#121

Post by KayEss »

khitchdee wrote: post #109
psyc wrote: post #107

Earlier quoted context omitted.

This is done at compile time. The call is indirect, which only means the call destination is decoupled from the generated calling code. This does not entail the runtime loading anything. http://www.geeksforgeeks.org/virtual-functions-and-runtime-p...

OK. Wouldn't that indirection add an extra instruction, each time you called a function?

Yes, but if your design requires the virtual function then you'll be using a function pointer in the C implementation as well, which has the same indirection.

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

#122

Post by coldtea »

blub wrote: post #103
coldtea wrote: post #40

Earlier quoted context omitted.

Doesn't have to be hygienic, it's enough that fixing it doesn't justify the time/money costs for the programmer.

We wouldn't want the programmer to spend too much money/time on fixing errors. After all, it's not like people would die if there's an error in the missile software: http://www.gao.gov/mobile/products/IMTEC-92-26 Not to mention they added even more HW to work around the leaks. No wonder those projects always run over budget.

>We wouldn't want the programmer to spend too much money/time on fixing errors. After all, it's not like people would die if there's an error in the missile software

When exactly did pkg_config became missile software?

As they say in meme-land, "that escalated quickly".

Here's a novel idea: how about the appropriate level of effort/time/YAGNI-stuff based on the domain?

Or do you write one-time scripts with MISRA rules?

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

#123

Post by khitchdee »

KayEss wrote: post #121
khitchdee wrote: post #109

Earlier quoted context omitted.

OK. Wouldn't that indirection add an extra instruction, each time you called a function?

Yes, but if your design requires the virtual function then you'll be using a function pointer in the C implementation as well, which has the same indirection.

If your design requires inheritance or virtual functions, C++ is the right choice. But in many cases, when it doesn't, if you still use C++, you'll pay the price of an extra indirection and a much larger memory structure to hold your objects. If your function were processing the inner loop of a video codec, that would unneccesarily slow you down

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

#124

Post by blub »

coldtea wrote: post #122
blub wrote: post #103

Earlier quoted context omitted.

We wouldn't want the programmer to spend too much money/time on fixing errors. After all, it's not like people would die if there's an error in the missile software: http://www.gao.gov/mobile/products/IMTEC-92-26 Not to mention they added even more HW to work around the leaks. No wonder those projects always run over budget.

> We wouldn't want the programmer to spend too much money/time on fixing errors. After all, it's not like people would die if there's an error in the missile software When exactly did pkg_config became missile software? As they say in meme-land, "that escalated quickly". Here's a novel idea: how about the appropriate level of effort/time/YAGNI-stuff based on the domain? Or do you write one-time scripts with MISRA rul…

The sub-thread I replied to was linking to an anecdote about missile software.

But I still think not freeing is pretty lame even in short-lived tools. If one is using a no-op deallocator at least the code is designed properly and could be repurposed.

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

#125

Post by elderK »

aidenn0 wrote: post #98
overgard wrote: post #96

Earlier quoted context omitted.

> C++ does make code reuse a lot easier. Not really, with ABI issues and compiler incompatibility widely used C++ libs are either header-only, or have an "extern C" version of the public API. Id say C++ makes reuse much harder.

1) ABI issues and compiler incompatibility hasn't been a problem for 5-10 years (using two compilers for a single binary is relatively rare). 2) Being "header-only" is no impediment to code reuse.

Hey there Aidenn0,

I'm no expert on C++ and I've been considering using it for several projects.

An important thing for my needs is being able to define classes in one shared object and create new subtypes of those classes in another, possibly defining overrides on virtual methods and such.

A good friend of mine has said similar things as you - that the ABI issue has not been a major obstacle for some time.

And yet, as much as I search, I still find the same-old advice: Don't use STL types in your interfaces or throw exceptions across module boundaries.

If all the compilers used for a given platform follow the same ABI, would using a separate and specific STL implementation (say, STLport) instead alleviate that particular issue?

Sorry if this question seems a bit rambley but I'd really love to find out how to use C++ in the way I've mentioned.

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

#126

Post by khitchdee »

elderK wrote: post #125
aidenn0 wrote: post #98

Earlier quoted context omitted.

1) ABI issues and compiler incompatibility hasn't been a problem for 5-10 years (using two compilers for a single binary is relatively rare). 2) Being "header-only" is no impediment to code reuse.

Hey there Aidenn0, I'm no expert on C++ and I've been considering using it for several projects. An important thing for my needs is being able to define classes in one shared object and create new subtypes of those classes in another, possibly defining overrides on virtual methods and such. A good friend of mine has said similar things as you - that the ABI issue has not been a major obstacle for some time. And yet,…

Partly this depends on the platform. C++ is well supported on Microsoft's .NET platform where you can access all the functionality of the .NET libraries through C++.

STL, I guess, is more used on Linux. I would advise against trying to use portable libraries and instead using libraries designed for the platform you are targeting.

Having said that, a good portable UI library is the open source WxWidgets which is accessible through C++ for OSX, Linux, Windows

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

#127

Post by psyc »

khitchdee wrote: post #123
KayEss wrote: post #121

Earlier quoted context omitted.

Yes, but if your design requires the virtual function then you'll be using a function pointer in the C implementation as well, which has the same indirection.

If your design requires inheritance or virtual functions, C++ is the right choice. But in many cases, when it doesn't, if you still use C++, you'll pay the price of an extra indirection and a much larger memory structure to hold your objects. If your function were processing the inner loop of a video codec, that would unneccesarily slow you down

You only pay for the indirection for virtual functions. You don't pay it simply for choosing C++. There is no "much larger memory structure" either. The vtable is per class. The per object cost is one pointer. C++ compilers are pretty smart.

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

#128

Post by bstamour »

khitchdee wrote: post #123
KayEss wrote: post #121

Earlier quoted context omitted.

Yes, but if your design requires the virtual function then you'll be using a function pointer in the C implementation as well, which has the same indirection.

If your design requires inheritance or virtual functions, C++ is the right choice. But in many cases, when it doesn't, if you still use C++, you'll pay the price of an extra indirection and a much larger memory structure to hold your objects. If your function were processing the inner loop of a video codec, that would unneccesarily slow you down

Unless you explicitly type `virtual`, your C++ classes will have the exact same overhead as C structs. Even with inheritance. The memory layout of

    struct A { int x; };
    struct B : A { int y; };
is the same as if you had written

    struct B { int x; int y; };
Public/private/protected inheritance and access control do not add overhead. It's literally only if you opt in by typing `virtual` do you get class hierarchy overhead.

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

#129

Post by khitchdee »

bstamour wrote: post #128
khitchdee wrote: post #123

Earlier quoted context omitted.

If your design requires inheritance or virtual functions, C++ is the right choice. But in many cases, when it doesn't, if you still use C++, you'll pay the price of an extra indirection and a much larger memory structure to hold your objects. If your function were processing the inner loop of a video codec, that would unneccesarily slow you down

Unless you explicitly type `virtual`, your C++ classes will have the exact same overhead as C structs. Even with inheritance. The memory layout of struct A { int x; }; struct B : A { int y; }; is the same as if you had written struct B { int x; int y; }; Public/private/protected inheritance and access control do not add overhead. It's literally only if you opt in by typing `virtual` do you get class hierarchy overhea…

Public/private/protected inheritance and access control do not add overhead

That's interesting. So does the compiler just put the functions in different parts of the vtable to remember the access control rules. There's no such thing as a free lunch and you're adding information here -- has to be stored somewhere.

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

#130

Post by aidenn0 »

elderK wrote: post #125
aidenn0 wrote: post #98

Earlier quoted context omitted.

1) ABI issues and compiler incompatibility hasn't been a problem for 5-10 years (using two compilers for a single binary is relatively rare). 2) Being "header-only" is no impediment to code reuse.

Hey there Aidenn0, I'm no expert on C++ and I've been considering using it for several projects. An important thing for my needs is being able to define classes in one shared object and create new subtypes of those classes in another, possibly defining overrides on virtual methods and such. A good friend of mine has said similar things as you - that the ABI issue has not been a major obstacle for some time. And yet,…

If you use the same compiler, ABI is a non-issue.

If you want to distribute dynamic-link binaries for windows, use MSVC.

If you want to distribute dynamic-link binaries for OS X, use Xcode.

If you want to distribute dynamic-link binaries for linux, you are SOL regardless of whether or not you are using C++, but if you use the same compiler and flags that the latest LTS version of Ubuntu uses, then it will work on Ubuntu, and will be made to work anywhere that Steam works.

It used to be that there were at least two C++ compilers for each *nix (typically GNU and something cfront based), so ABI was a much bigger deal.

When "Modern C++ Design" came out, famously none of the compilers could correctly compile all of the sample code. Since then things are much better; not that all compilers are bug-free of course, but they are sufficiently good enough that if you report a bug, you can expect it to be fixed.

[EDIT]

"Don't use STL Types in your interfaces" is not advice I've heard in like 15 years; I more often hear "If you're using a C array instead of a Vector, you're doing it wrong"

"Don't throw exceptions across module boundaries" seems similarly odd. Unless your constructors are inlined, no modern code-base will follow that rule because RAII relies so strongly on exceptions.

There are coding styles that are opposed to exceptions as part of an external interface, but that's due to exceptions not being checked as part of the type system, and is not what I would call a majority opinion.

Post reply on HN