10 ms·

What are the advantages of trying to use fake c++ instead of actual c++ for their use case? I'm sure there are / were smart people working on the project. Do th

What are the advantages of trying to use fake c++ instead of actual c++ for their use case? I'm sure there are / were smart people working on the project. Do they keep decision records? Have you had a conversation with the relevant people about it?

qalmakka 2y ago
C++, especially before C++11, was a total mess. Even today, it's super easy to shoot yourself in the foot and you literally can't learn the entirety of the language due to how massive it is. This still doesn't justify doing the absurdity of macro magic and garbage I've seen people pumping out in C over the years though. IMHO if you deliberately use C it's because you want to keep things simple. Sometimes C++ will inevitably lead to overcomplicated designs nobody needs; there's a reason why 90's C++ feels massively outdated, while 90's C is still (mostly) accessible. C is a great way to keep the urge people have to shovel in OOP even when it doesn't really make sense. When I see some bullshit C++ code at work, I often think, "if people had to write this in C, they wouldn't have overthought this this much"... My 2 cents is that there was a Java craze back in the '90s that basically infected all code designed in that time period, and that's how we got some very weird nonsense that in hindsight was poorly thought out. Just look at stuff like GTK+ and GObject...
- galangalalgol 2y ago
  I have been guilty of this if only in school. A class assignment could be completed in java or c and I knew c++ and c and my teammates knew c. I really wanted to do oop because I was ignorant, but none of us knew java so we did OO in c. It was horrible. I like the simplicity of c. I wish there was a zig that was immutable by default, and had a borrowchecker, but I think that road inevitably leads to a GC jitted language or to something as complicated as rust. Well almost as complicated, at least macros would still be written in the same syntax as normal runtime code.
- bobajeff 2y ago
  The GObject system for all it's faults serves a purpose. Similar to COM in Windows it allows mapping of higher level languages to libraries. Without it there wouldn't be all the bindings we have to Python, JavaScript, Vala and Rust today. I wouldn't say it was poorly thought out so much as mismatched with it's user's typical uses and expectations.
  - qalmakka 2y ago
    Yeah but it made literally zero sense to write GObject in C. They've reimplemented inheritance and the like with macro BS while the GNU project literally had both a C++ and Objective-C compiler - Objective-C warts and all was a perfect fit for GObject.
    - bobajeff 2y ago
      It makes sense if you consider that it was created for making c libraries bindable to higher level languages. That's more a flaw in it's design rather than implementation. If they were to design such a system now I'd hope it would be designed as a language independent ABI, Runtime and IDL like the Wasm Component Model.
flohofwoe 2y ago
> What are the advantages of trying to use fake c++ instead of actual c++ for their use case? There are exactly none, but there was a time during the mid- to late-90s when it was hip to implement OOP frameworks on top of C (C++ only really became a realistic option once C++98 was widely supported which took a couple of years, ...also there was such an extreme OOP hype in the 90s that it is hard to believe today - EVERYTHING had to be OOP, no matter if it made sense or not). QEMU seems to be from around the end of that era (first release apparently in 2003), and looking at the code it looks exactly as I imagined, with meta-class pointers, constructor- and destructor-functions etc... it would almost certainly be better to use a simple non-OOP C-style, but that was an 'outdated' point of view at that time (since everything had to use that new shiny OOP paradigm).
- bonzini 2y ago
  The object model in QEMU is from 2007-2011. Internally there isn't a lot of inheritance (it's pretty shallow), but yeah I guess "is-a" is what was in vogue at the time. However there is a reason to have the object model, and it was added because some things were getting out of hand. You had to write three parsers for everything you added: one for command line, one for the text-based command interface and one for the JSON API. And you had to do it once for each kind of "object" (device, network backend, disk backend, character device backend etc.). The object model is designed to let you write code just once for all three and to reuse the interface across object types.
- dhosek 2y ago
  That 90s OOP hype really mirrors the contemporary FP hype (and the 70s–80a structured programming hype). Programming is definitely subject to fads.
crabbone 2y ago
I worked for a large infra project that was mostly written in C with the kind of trickery that is being here ascribed to QEMU code (I trust the parent, but I haven't seen the code myself). It's a common thing to do in projects like this in C. While C++ solves some of the problems for larger projects, it brings so many more, it's usually not worth it. Projects of this kind, essentially, invent their own language, with their own conventions. C is just a convenient tool (given the alternatives...) to do that, as it's treated as a kind of a transpilation target. Think about languages like Haskell which essentially work like that, but went even further. So, what typically happens is that memory allocation, I/O and concurrency need to be done differently from how the language runtime wants to do that. So, at this point, you basically throw away most of the existing language runtime. From my recent encounters with different bugs in QEMU, I imagine that they really, really need a lot of customization in how memory is allocated (my particular case was that QEMU was segfaulting when running ldconfig in aarch64 emulation, which turned out to be due to ldconfig having some weird custom-made memory allocation pattern which QEMU cannot account for.) It's easier to fight this battle with C than it is with C++.
- dboreham 2y ago
  I was going to post the same thing. Others on this thread may not have had experience with very large C codebases and hence haven't seen this play out. To a large degree C++ is just capturing what was already widespread practices in C, and indeed assembly before that.
- quotemstr 2y ago
  You can define your own "language", the way you describe it, in C++ more easily than you can in C. C++ gives you more powerful and expressive tools for doing so. A program is not improved by foregoing these tools. There's nothing in C++ forcing you to do anything that makes anything "harder".
  - crabbone 2y ago
    I wouldn't be so quick to put "easy" and "C++" in the same sentence... Also, C and C++ language tools suck, when it comes to making a language compared to anything in Lisp family, for example, or any language that has Lisp-like macros. C wasn't chosen for it's ability to make other languages. It was an easy target. The benefits are the simpler and more malleable runtime that can be made to do all sorts of weird things where C++ would be much harder to deal with. In other words, if you don't want the language runtime, if you don't want C++ templates, smart pointers, classes, lambdas, exceptions etc. But, you want to be able to manage memory for eg. realtime kind of system... simply removing all the unwanted stuff from C++ is harder than it is with C. And, if you did want some / all of those features of C++, there are saner languages to have that (and you'd pay for it by having to drag in their runtime and conventions). Before Rust was a thing, I've seen people choose D instead, for example, as a kind of middle ground between the asceticism of C and unnecessary excess of C++.
IshKebab 2y ago
The only advantage I know of is that it means you stay within the C ABI. It can simplify linking a little in some cases, or FFI. I guess compilation is faster too. But yeah broadly speaking it's a terrible idea.

qalmakka 2y ago

C++, especially before C++11, was a total mess. Even today, it's super easy to shoot yourself in the foot and you literally can't learn the entirety of the language due to how massive it is. This still doesn't justify doing the absurdity of macro magic and garbage I've seen people pumping out in C over the years though. IMHO if you deliberately use C it's because you want to keep things simple. Sometimes C++ will inevitably lead to overcomplicated designs nobody needs; there's a reason why 90's C++ feels massively outdated, while 90's C is still (mostly) accessible. C is a great way to keep the urge people have to shovel in OOP even when it doesn't really make sense. When I see some bullshit C++ code at work, I often think, "if people had to write this in C, they wouldn't have overthought this this much"... My 2 cents is that there was a Java craze back in the '90s that basically infected all code designed in that time period, and that's how we got some very weird nonsense that in hindsight was poorly thought out. Just look at stuff like GTK+ and GObject...

galangalalgol 2y ago
I have been guilty of this if only in school. A class assignment could be completed in java or c and I knew c++ and c and my teammates knew c. I really wanted to do oop because I was ignorant, but none of us knew java so we did OO in c. It was horrible. I like the simplicity of c. I wish there was a zig that was immutable by default, and had a borrowchecker, but I think that road inevitably leads to a GC jitted language or to something as complicated as rust. Well almost as complicated, at least macros would still be written in the same syntax as normal runtime code.
bobajeff 2y ago
The GObject system for all it's faults serves a purpose. Similar to COM in Windows it allows mapping of higher level languages to libraries. Without it there wouldn't be all the bindings we have to Python, JavaScript, Vala and Rust today. I wouldn't say it was poorly thought out so much as mismatched with it's user's typical uses and expectations.
- qalmakka 2y ago
  Yeah but it made literally zero sense to write GObject in C. They've reimplemented inheritance and the like with macro BS while the GNU project literally had both a C++ and Objective-C compiler - Objective-C warts and all was a perfect fit for GObject.
  - bobajeff 2y ago
    It makes sense if you consider that it was created for making c libraries bindable to higher level languages. That's more a flaw in it's design rather than implementation. If they were to design such a system now I'd hope it would be designed as a language independent ABI, Runtime and IDL like the Wasm Component Model.

flohofwoe 2y ago

> What are the advantages of trying to use fake c++ instead of actual c++ for their use case? There are exactly none, but there was a time during the mid- to late-90s when it was hip to implement OOP frameworks on top of C (C++ only really became a realistic option once C++98 was widely supported which took a couple of years, ...also there was such an extreme OOP hype in the 90s that it is hard to believe today - EVERYTHING had to be OOP, no matter if it made sense or not). QEMU seems to be from around the end of that era (first release apparently in 2003), and looking at the code it looks exactly as I imagined, with meta-class pointers, constructor- and destructor-functions etc... it would almost certainly be better to use a simple non-OOP C-style, but that was an 'outdated' point of view at that time (since everything had to use that new shiny OOP paradigm).

bonzini 2y ago
The object model in QEMU is from 2007-2011. Internally there isn't a lot of inheritance (it's pretty shallow), but yeah I guess "is-a" is what was in vogue at the time. However there is a reason to have the object model, and it was added because some things were getting out of hand. You had to write three parsers for everything you added: one for command line, one for the text-based command interface and one for the JSON API. And you had to do it once for each kind of "object" (device, network backend, disk backend, character device backend etc.). The object model is designed to let you write code just once for all three and to reuse the interface across object types.
dhosek 2y ago
That 90s OOP hype really mirrors the contemporary FP hype (and the 70s–80a structured programming hype). Programming is definitely subject to fads.

crabbone 2y ago

I worked for a large infra project that was mostly written in C with the kind of trickery that is being here ascribed to QEMU code (I trust the parent, but I haven't seen the code myself). It's a common thing to do in projects like this in C. While C++ solves some of the problems for larger projects, it brings so many more, it's usually not worth it. Projects of this kind, essentially, invent their own language, with their own conventions. C is just a convenient tool (given the alternatives...) to do that, as it's treated as a kind of a transpilation target. Think about languages like Haskell which essentially work like that, but went even further. So, what typically happens is that memory allocation, I/O and concurrency need to be done differently from how the language runtime wants to do that. So, at this point, you basically throw away most of the existing language runtime. From my recent encounters with different bugs in QEMU, I imagine that they really, really need a lot of customization in how memory is allocated (my particular case was that QEMU was segfaulting when running ldconfig in aarch64 emulation, which turned out to be due to ldconfig having some weird custom-made memory allocation pattern which QEMU cannot account for.) It's easier to fight this battle with C than it is with C++.

dboreham 2y ago
I was going to post the same thing. Others on this thread may not have had experience with very large C codebases and hence haven't seen this play out. To a large degree C++ is just capturing what was already widespread practices in C, and indeed assembly before that.
quotemstr 2y ago
You can define your own "language", the way you describe it, in C++ more easily than you can in C. C++ gives you more powerful and expressive tools for doing so. A program is not improved by foregoing these tools. There's nothing in C++ forcing you to do anything that makes anything "harder".
- crabbone 2y ago
  I wouldn't be so quick to put "easy" and "C++" in the same sentence... Also, C and C++ language tools suck, when it comes to making a language compared to anything in Lisp family, for example, or any language that has Lisp-like macros. C wasn't chosen for it's ability to make other languages. It was an easy target. The benefits are the simpler and more malleable runtime that can be made to do all sorts of weird things where C++ would be much harder to deal with. In other words, if you don't want the language runtime, if you don't want C++ templates, smart pointers, classes, lambdas, exceptions etc. But, you want to be able to manage memory for eg. realtime kind of system... simply removing all the unwanted stuff from C++ is harder than it is with C. And, if you did want some / all of those features of C++, there are saner languages to have that (and you'd pay for it by having to drag in their runtime and conventions). Before Rust was a thing, I've seen people choose D instead, for example, as a kind of middle ground between the asceticism of C and unnecessary excess of C++.

IshKebab 2y ago

The only advantage I know of is that it means you stay within the C ABI. It can simplify linking a little in some cases, or FFI. I guess compilation is faster too. But yeah broadly speaking it's a terrible idea.