C vs C++

[sirherrbatka]

I have to admit, I'm extremely curious on how you can guarantee real-time when the GC blocks everything until it is finished. Not knowing when the GC would run, for how long and that it won't handle any requests makes me extremely nervous (and refuse to use/deploy) in some situations.

You can't have hard real time but you can get really damn close. Azul systems offer linux kernel module that implements parts of GC directly in the linux, using internal kernels memory synchronization barriers. The result is rather good.

Anyway, my remark was pointed at Rust. Functional programming without GC is just… stupid. And const by default is all nice and dandy, but does not change that much on it's own.

[wareya]

Deterministic GCs can even be good for games. They won't increase throughput, but you can use a GC to defer freeing memory until the current frame has been completed, which can reduce the amount of time between taking inputs and showing their results on the screen.

[psi29a]

I mean you can read about these things if you want, heres what my company uses: ftp://public.dhe.ibm.com/software/webse ... nux_30.pdf

Hey Jyby, thank you for this. Good 'ol Websphere and IBM J9.

I dug a bit into how they achieved hard RT in J9 which was interesting. So they basically threw out the traditional (non-deterministic) GC for a deterministic (Metronome) GC that tries to give equal time to application as to GC itself.

https://www.ibm.com/developerworks/library/j-rtj4/

I don't know about you, but this reads to me as a solution for "shit, we have software/systems ready to use but we have RT requirements..." They did solve it, which is great. However it is a bitter pill to swallow when following the old adage: you have security, stability and performance; pick 2.

So while you've met your RT requirements (awesome), your performance (requests/calls per second) is going to take a hit. So long as you can meet your time sensitive deadlines with your available bandwidth (requests/s), it's fine. As it says in the PDF you linked: "Real-time applications need consistent run time rather than absolute speed."

I see where J9 makes use of AOT instead of JIT compilation, which certainly does help on the performance side and allows you to reach the embedded market as well.

I hope you can see my point in that with a non-GC language, this a non-issue. You'll obviously have a lot more hand-holding going to handle your own memory but with C++11, as it was pointed out earlier that you can write code that is RAII and not have to worry about it.

https://en.wikipedia.org/wiki/Resource_ ... ialization

Again, thanks for the read! I guess at this point, I'll back off on the RT and Java do not mix rhetoric.

[Chris]

On windows, you can statically link libraries like libstdc++ or openal to avoid problems like this and nobody will bat an eye.

You can on Linux as well. Link with -static-libstdc++ and it will static link it. But then that throws back into the other problem of (lack of) resource sharing. If every module that uses C++ has to static link the C++ runtime, you're bloating code since each module will have a unique copy of the C++ runtime, and it ensures the C++ resources from one module aren't recognized by another. The point of having a shared library is being able to do those things.

The C++ standard library literally has to link over the C++ ABI.

That's my point. If "Any respectful C++ library will only link over the C ABI", what do you expect out of the language's users if the standard library can't follow its own "good practice" to avoid this problem? And if you can't use C++ language features over a DLL/SO boundary, isn't that a language problem?

[wareya]

On windows, you can statically link libraries like libstdc++ or openal to avoid problems like this and nobody will bat an eye.

If every module that uses C++ has to static link the C++ runtime, you're bloating code since each module will have a unique copy of the C++ runtime

There's literally no problem with this. If your system needs multiple versions of the same library installed, then it needs multiple versions of the same library installed. If your application needs a specific version of a library, and the OS makes that difficult, then static linking it makes 100% perfect sense. I'll never understand the modern foss culture's cult-like obsession with shared libraries.

it ensures the C++ resources from one module aren't recognized by another. The point of having a shared library is being able to do those things.

No, making resources compatible is not the point of shared libraries. You can do that perfectly fine with statically linked libraries, look no further than SDL. With SDL, you link SDL's dependencies when you link SDL, and SDL uses those libraries in such a way that their version doesn't matter at all.

If there's some library someone wants to use that they can't because it'll screw up the way their application is linked, that's a problem with the library, not the library's language: both C and C++ have exactly the same problem here. This could be improved dramatically, but it's an inherent problem with the C/++ approach to linking in general, shared or otherwise, and I'll repeat that both languages have it.

Shared libraries do not solve the issue at all, as linux distributions discovered after pretending that version numbers are compatibility numbers.

That's my point. If "Any respectful C++ library will only link over the C ABI", what do you expect out of the language's users if the standard library can't follow its own "good practice" to avoid this problem? And if you can't use C++ language features over a DLL/SO boundary, isn't that a language problem?

The C++ standard library implements things that should be language features. As such, it has to link over C++. This is not true of things like OpenAL or SFML at all. Libraries like that should use a header-only wrapper around a C ABI shared library, which is clean, simple, and can be done for everything that's not trying to extend the language like boost. You're trying to argue from principle here, but it's literally backwards. Normal libraries have no reason to do the things that the standard library has to do.

[Chris]

If your system needs multiple versions of the same library installed, then it needs multiple versions of the same library installed.

And it only needs multiple versions because the C++ ABI is so fragile. That's the problem. If the lib's ABI didn't so regularly break with updates due to C++'s design, it wouldn't require multiple separate versions as the newest one would be backwards compatible. If X causes Y problem, it's not a valid defense to say "Y happens because of X, so its not a problem". The problem is still there regardless of the reason.

No, making resources compatible is not the point of shared libraries. You can do that perfectly fine with statically linked libraries, look no further than SDL.

I don't see what you're getting at. What I'm saying is that the point of a shared library is to have shared resources. Globally, it means only 1 copy of the library's constant data (including code) needs to be loaded into RAM for all processes that use that library. It means when some part of the library is thrown into the OS's disk cache, all processes using that library will have that part of the library in memory and ready to use. Within a single process, it also means all modules that use the same binary interface will access the same data pools (just that some OSs are more prone to giving you a different binary interface for the same source interface).

The C++ standard library implements things that should be language features.

Huh? The C++ standard library utilizes language features to provide standard functionality. If the C++ standard library should be language features, why aren't they? They're designed by the same committee, and it's not like the standard library is some kind of "staging ground".

As such, it has to link over C++. This is not true of things like OpenAL or SFML at all. Libraries like that should use a header-only wrapper around a C ABI shared library, which is clean, simple, and can be done for everything that's not trying to extend the language like boost.

Which is a tacit admission that C++ has a big problem with ABI compatibility. Every library "extends the language". That's the purpose of libraries, to provide new functionality for the language that it didn't have before. OpenAL extends the language to give it 3D audio functionality, Bullet extends the language to give it physics functionality, etc. Sometimes this extended functionality gets adopted into the core language, as is the case with parts of Boost.

[wareya]

And it only needs multiple versions because the C++ ABI is so fragile. That's the problem.

No, it needs multiple versions because there are multiple versions. A given compiler's C++ ABI is stable over time. The problem is that different C++ compilers have different ABIs. This is completely tangential to libstdc++ breaking compatibility between language versions, and it makes me feel like you don't understand how minor the ABI's impact on the issue is.

If X causes Y problem

X doesn't cause Y problem.

What I'm saying is that the point of a shared library is to have shared resources. Globally, it means only 1 copy of the library's constant data (including code) needs to be loaded into RAM for all processes that use that library.

Different versions of the "same" library are not the same library. This is a problem both C and C++ have, equally badly. The libstdc++ linker clashing problem is the same as the glib linker clashing problem.

Huh? The C++ standard library utilizes language features to provide standard functionality. If the C++ standard library should be language features, why aren't they?

That's not my problem.

Which is a tacit admission that C++ has a big problem with ABI compatibility.

C++'s ABI compatibility problem is a thing between compilers, not over time.

Every library "extends the language".

No. The basic purpose of a library is to extend your program, not the language. There is a very big difference between language-like things and program-like things. I'm not going to have this conversation if the basis of your argument is bad faith.

[Chris]

No, it needs multiple versions because there are multiple versions.

Obviously there are multiple versions, but why is that the case? Because the binary interfaces for C++ are unstable. This is nowhere near as big of a problem in C, so it's not an inherent problem of public interfaces to be this bad. Ergo, the C++ language has a problem that makes interfaces unstable.

A given compiler's C++ ABI is stable over time.

Sorry, I mean the ABI of C++ libraries. Yes, the general C++ ABI itself is set.

If X causes Y problem

X doesn't cause Y problem.

So having to keep track of several individual versions of C++ libs isn't because of regular breakages from using C++ interfaces? Then what is it because of?

Different versions of the "same" library are not the same library. This is a problem both C and C++ have, equally badly.

No, C doesn't have this problem anywhere near as badly as C++ does. There's a reason why if you want a stable ABI for a library you use C, rather than C++. Yes, it can happen with C, but it's more prone to happening when using C++ because extra details end up in a binary interface that don't otherwise need to be in it. It takes more work to keep a C++ interface stable compared to a C interface, because the latter better separates the implementation from the interface.

Ironically, your video even suggests what GNU/libstdc++ does. "Avoid breakage by turning it into accretion. Old and new can coexist." That's exactly what the symbol versioning accomplishes. If an interface needs to break, the old interface is kept with its old version and the new interface is added with a new version. Under Windows, you get an entirely new DLL that has that interface updated. Under Linux, the shared library just gains a new interface that coexists with the old one.

Huh? The C++ standard library utilizes language features to provide standard functionality. If the C++ standard library should be language features, why aren't they?

That's not my problem.

I'm asking for clarification on what you meant.

Every library "extends the language".

No. The basic purpose of a library is to extend your program, not the language.

It extends your program's capabilities by extending the language functionality. If you write a program in C++, you can only do what C++ allows you to do, full-stop. If your program can do more, you've extended C++ to let you do more. Like threading. Prior to C++11/C11, you needed to use something like libpthread, which extends the C++/C language with threading functionality. You extend the language by including that library and you can then use threads through C++/C (in this case, the functionality was useful enough across so many types of software that it ended up in the core languages and no longer needs an extra library). Similar to audio, the core C language does not define any audio functionality, so you get a library like SDL or OpenAL that adds it to the language, then your program can use audio through C.

There is a very big difference between language-like things and program-like things.

It all comes down to the program. Everything serves the program because without a program, nothing happens. libc does nothing if a program isn't there to use it. The language is for the program, and consequently, anything for the language is also for the program.

[psi29a]

C++ allows 0-width spaces in variable names.

Where's your god now?

[wareya]

I'll try to be less aggressive this time, sorry, writing that last post left a bad taste in my mouth.

Obviously there are multiple versions, but why is that the case? Because the binary interfaces for C++ are unstable. This is nowhere near as big of a problem in C, so it's not an inherent problem of public interfaces to be this bad. Ergo, the C++ language has a problem that makes interfaces unstable.

...

Sorry, I mean the ABI of C++ libraries. Yes, the general C++ ABI itself is set.

Oh, that's fine then. I assumed we were both talking about the language ABI itself, but apparently that's not the case. For the rest of this conversation I'm going to use the term "API version" to refer to a library compatibility target, and "language ABI" to refer to the symbol mangling and calling convention of a shared library.

I don't really think C++ makes it easy to change the API version of a library on accident. I do think that there's a linker problem, but I think it's exactly the same one that C has, which it does, when glib updates and breaks old userspace programs. In a reasonable world, either glib versions would be packaged with each application, or old glib API versions would continue to be used forever, even if they only function as a translation layer to the latest version of glib. Java has this basically done with Maven, but C and C++ both don't really determine much of the linking process, and in practice, GCC presents the same fundamental problems for both of them.

So having to keep track of several individual versions of C++ libs isn't because of regular breakages from using C++ interfaces? Then what is it because of?

Normal backwards-incompatible library API version changes.

No, C doesn't have this problem anywhere near as badly as C++ does. There's a reason why if you want a stable ABI for a library you use C, rather than C++. Yes, it can happen with C, but it's more prone to happening when using C++ because extra details end up in a binary interface that don't otherwise need to be in it. It takes more work to keep a C++ interface stable compared to a C interface, because the latter better separates the implementation from the interface.

I don't really think this is the language's fault, and I don't think it's true that C++ has it significantly worse than C, either. With C libraries, the binary ABI of a given version of a given library contains too little information about things like types for how low level it is. This is basically a security hazard. It's easier to break binary compatibility with C++, but only when the behavior of your library already changed and you shouldn't be using the changed version with something that wasn't meant for it.

Ironically, your video even suggests what GNU/libstdc++ does. "Avoid breakage by turning it into accretion. Old and new can coexist." That's exactly what the symbol versioning accomplishes. If an interface needs to break, the old interface is kept with its old version and the new interface is added with a new version. Under Windows, you get an entirely new DLL that has that interface updated. Under Linux, the shared library just gains a new interface that coexists with the old one.

The accretion he's referring to is to basically consider the API version part of the identity of the library. You wouldn't link "SDL2", you'd link "SDL2 2.0.4". If that exact API version of that library isn't found on the system, your program won't run. It won't try to run with 2.0.3 or 2.0.5, only 2.0.4. No backwards compatible version changes like semver tries and fails to provide. This is very different from adding new interfaces to existing shared libraries, and still different from what Windows programs generally do which packages the correct version of every library with every program (except for the 20 DX redistributables I have installed).

I'm asking for clarification on what you meant.

Things like dynamic arrays and variants should by all means be part of the language spec. For some reason they're not. I don't know why they're not, but it's insane to consider dynamic arrays and variants to be extensions of a program instead of extensions of the language. If the C++ standard library only included utilities like i/o streams instead of fundamental data structures like dynamic arrays I would get the comparison to third party libraries like SFML, but the fact that it's so low level means that it can't be expected to operate at the same level. Again, I do think this is stupid, and those things should be part of the language, not the standard library, but that's the way things stand right now.