Comparing C and C++ usage and performance with a real world project • Hacker News Board

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

#131

Post by bstamour » Mon, Sep 04, 2017, 8:43 PM UTC

khitchdee wrote: post #129

bstamour wrote: post #128

Earlier quoted context omitted.

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.

Access control rules are all checked at compile time. There's literally nothing to store. If you want proof, check the output of your compiler. The only thing a non-virtual struct/class might do is reorder member variables if they're of different access controls, but if you're just using a C-style struct but with private member variables and public non-virtual member functions, it has literally the same memory layout as it would in C.

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

#132

Post by khitchdee » Mon, Sep 04, 2017, 9:25 PM UTC

bstamour wrote: post #131

khitchdee wrote: post #129

Earlier quoted context omitted.

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.

Access control rules are all checked at compile time. There's literally nothing to store. If you want proof, check the output of your compiler. The only thing a non-virtual struct/class might do is reorder member variables if they're of different access controls, but if you're just using a C-style struct but with private member variables and public non-virtual member functions, it has literally the same memory layout…

OK. That makes sense. So it's only a compiler overhead

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

#133

Post by harry8 » Tue, Sep 05, 2017, 4:28 AM UTC

WalterBright wrote: post #117

harry8 wrote: post #111

Earlier quoted context omitted.

if (existsCoffee) writeln("Drink coffee"); http://ddili.org/ders/d.en/if.html Sad that you adopted one of C's worst features. Why? Can you get rid of it and mandate the bracing every block?

My take on C's biggest mistake: https://digitalmars.com/articles/b44.html

Sure but there is just no reason at all to copy unbraced blocks. All you do is invite bugs for zero benefit.

Maybe there are bigger issues with C? But that's a different discussion. I want to know why you copied something as simultaneously horrendous and useless as unbraced blocks? If you just didn't think it through and that's the way languages syntactically similar to C have always done it, ok. I'm sure I've made worse mistakes. But please call it one way or the other.

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

#134

Post by elderK » Tue, Sep 05, 2017, 8:00 AM UTC

aidenn0 wrote: post #130

elderK wrote: post #125

Earlier quoted context omitted.

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

Thanks for the response.

To clarify "module boundaries", I mean "separate shared objects."

As for Linux, I'm not too concerned with creating a single binary that works for all distributions.

I'm more concerned with someone being able to build a set of shared libraries on their distribution of choice and those shared libraries being able to interact naturally regardless of which compiler s/he uses to build each of them.

Say, LibA is built using LLVM. LibB is built using G++ and LibC is built using ICC.

LibA defines several classes. LibB creates some subtypes. LibC instantiates types from both LibA and LibB.

All the functions present in LibA, LibB, LibC make use of STL types such as std::string, std::vector, etc. Some may throw exceptions, whatever.

With respect to MSVC, I've read that compatibility between Debug and Release builds is kind of suspect, especially if you're using STL types. Not to mention differences in MSVC version. Is this still a concern?

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

#135

Post by overgard » Tue, Sep 05, 2017, 1:42 PM UTC

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.

1) Ever try to upgrade msvc versions? It's always a huge problem if you're using libraries you don't have source for. Not to mention the 50 million linker issues if one library is linked statically and the rest dynamic. There are still people on like msvc 6 because of this.

2) Header only libraries are horrible for compile times, especially heavily templated ones (and if you use c++ generics it basically has to be a header library). The reason boost is banned from a lot of cpp projects isn't because the library is bad, it's because of compile time.

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

#136

Post by overgard » Tue, Sep 05, 2017, 1:49 PM UTC

aidenn0 wrote: post #130

elderK wrote: post #125

Earlier quoted context omitted.

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

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

And yet... microsoft releases a new compiler every two years or so, and not every library you use is going to update at the same time. This is a huge frustration for a lot of people.

I write c++ professionally and I've seen people waste weeks on these things, and most the libraries we wrote had plain c interfaces because being able to use other languages to call into the code was important and c++ is a nightmare with that.

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

#137

Post by aidenn0 » Tue, Sep 05, 2017, 4:15 PM UTC

elderK wrote: post #134

aidenn0 wrote: post #130

Earlier quoted context omitted.

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

Thanks for the response. To clarify "module boundaries", I mean "separate shared objects." As for Linux, I'm not too concerned with creating a single binary that works for all distributions. I'm more concerned with someone being able to build a set of shared libraries on their distribution of choice and those shared libraries being able to interact naturally regardless of which compiler s/he uses to build each of the…

> I'm more concerned with someone being able to build a set of shared libraries on their distribution of choice and those shared libraries being able to interact naturally regardless of which compiler s/he uses to build each of them.

Sorry, but this is an unreasonable standard. Literally no language, including C supports this. With C it only works inasmuch as the C compiler authors work really hard to make it works, and even then it sometimes breaks (if your compiler inlines a call to malloc, and you free a pointer compiled with a different C Compiler that inlined a different malloc implementation, it can break horribly. Yes I've seen this happen.)

Some languages support cross-version linking (or whatever the language's equivalent of "linking" is), but I'm not aware of any that specify a complete ABI for unrelated implementations to support. IPC libraries do typically support this though.

[edit]

I don't want to go on a shared-library rant, but I am fairly strongly opposed to them (except perhaps in cases like how nixos manages it). You can take a statically linked binary from 1997 and run it unmodified on your linux machine today. It is a virtual guarantee that any dynamically-linked binary more than 2 years old will not work correctly. Linus puts a huge amount of effort into backwards compatibility, and it is completely destroyed by dynamic linking.

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

#138

Post by aidenn0 » Wed, Sep 06, 2017, 12:21 AM UTC

overgard wrote: post #136

aidenn0 wrote: post #130

Earlier quoted context omitted.

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

> If you use the same compiler, ABI is a non-issue And yet... microsoft releases a new compiler every two years or so, and not every library you use is going to update at the same time. This is a huge frustration for a lot of people. I write c++ professionally and I've seen people waste weeks on these things, and most the libraries we wrote had plain c interfaces because being able to use other languages to call into…

Yeah, MSVC breaking ABI is somewhat annoying, but I am also used to keeping the most recent half-dozen MSVC's installed.

VS 6.0 is getting very hard to source legally these days, and I wish MS made it easier to get.

As far as having high-level languages call directly into C++, yes that's quite a pain (nearly impossible without something like https://github.com/rpav/c2ffi). Note also that calling into non-C ABI functions in any language is hard (and most HLLs don't support anything like extern "C" to make it easy).

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

#139

Post by khitchdee » Wed, Sep 06, 2017, 2:14 PM UTC

khitchdee wrote: post #35

FWIW, Donald Knuth was a proponent of using C over C++ at the time it first came out. He equated C++ with the use of frameworks in writing programs which he thought were a bad idea for the profession as it would dumb it down. C++ does make code reuse a lot easier.

As an example of C++ making code reuse a lot easier, consider the Windows platform from a developer's perspective. Before C++, there was this huge library called Win32 in C that contained several hundred functions and data structures to access the services of the platform. Since it was not object oriented, there was a fat book by Charles Petzold, which was like a Bible for windows programmers that described how each of the functions related to each other, in what sequence to call them and a bunch of stuff that was not even documented by Microsoft. Once C++ came, there was a library called MFC which was object oriented and hence a lot better documented and organised and now there's .NET.

The organization of functions into objects makes it a lot easier to understand systems software specially if it's very large. Also the ability to subclass means you can take the base functionality of "template" classes provided by a library and subclass them to extend them with what you need. This was not as easy with C where you had to rely on sample code for this purpose. The Petzold book had a ton of sample code.

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

#140

Post by matthewaveryusa » Fri, Sep 08, 2017, 1:25 PM UTC

wilun wrote: post #65

matthewaveryusa wrote: post #63

Earlier quoted context omitted.

My experience has been the opposite of yours. Freeing is always a good idea so you can use tools like valgrind to find memory bugs without needing to sort through all the false positives. Your short-lived program today can become a service tomorrow. c++is worth it just for RAII

Valgrind does not force the user to read mem leak reports along errors. Actually IIRC, by default you don't get detailed leak reports.

True, the defaults are pretty lame, but my point is if you don't free, and you start using data you intended to free, that's a memory bug valgrind won't be able to help you with unless you free your memory.

FWIW, this is in my bashrc along with a myriad of other programs that have lame defaults: alias valgrind='valgrind --leak-check=full --show-reachable=yes --track-origins=yes --track-fds=yes --error-limit=no'