5 ms·

I've said this before on here and I'll say it again. The QEMU code base is a nightmare. The amount of fake C++ is mind numbing. Every time I come across a varia

I've said this before on here and I'll say it again. The QEMU code base is a nightmare. The amount of fake C++ is mind numbing. Every time I come across a variable or strict declaration or method with the word "class" in it, I'm reminded of how much easier the whole thing would've been with C++. You can't even compile C++ into QEMU because of how the headers use keywords. That's not even touching their macro abuse template functions. You know what has templates and classes? C++. And constructors. There's just so much. All this to say: if Rust can make it in, that's great, because I'm tired of dealing with C's simplicity for more complicated tasks. I'm not a rust user but if it lets me use classes and templates, I'll switch over

masklinn 2y ago
> I'm not a rust user but if it lets me use classes and templates, I'll switch over Yer not switching any time soon then. Rust does have methods but not classes (QOM’s inheritance is specifically called as an issue in TFA) and it uses Haskell-style generics rather than C++-style templates.
- Neywiny 2y ago
  :( the QOM inheritance is where I've had my wrist bugs. Recently I merged from master (upgrading me from version 8.something to 9.2.?) and they dramatically changed the resets. I tried the new way and had segfaults in bad places that went away when I reordered code that shouldn't have ordering requirements. That was too scary so I switched to their legacy reset function and it was all fine again. All this blind casting of opaques makes me nervous.
  - bonzini 2y ago
    The legacy reset way is fine, and yeah this is where being more strict and doing more stuff within the language should help.
- ThePhysicist 2y ago
  I mean it has polymorphism via v-tables and composition via traits, that's enough object-orientation for me. Inheritance is a core principle of OOP but in practice most C++ class hierarchies are relatively flat (there are exceptions like Qt, which I think uses inheritance in a good way), in practice most of that can be mimicked with embedding and composition well enough to work. Not sure if you want to call that object-oriented but operating on polymorphous structures that encapsulate their data is pretty close to object orientation (the good parts of OOP, at least). And I'm not a big expert on Rust but I think you can do most of the things we do in C++ with templates using macros.
  - galangalalgol 2y ago
    The one lagging thing that isn't easy with rust's generics is expressions, and that looks to be getting kicked down the road indefinitely. You can't have Foo<N> * Foo<M> -> Foo<N+M> or similar. That is a useful thing for statically sized math libraries and for performance oriented metaprogramming. The latter can be clumsily handled with macros, but not the former. It is also blocking portable simd from stabilizing, apparently now indefinitely. I still wouldn't pick any other language a new production product, but I find the stalling out on const generic expressions frustrating, as simd and static math libraries are things I use daily.
    - LoganDark 2y ago
      I could go on and on about the limitations of min_const_generics, missing TAIT (type alias impl trait), unstable coroutines/generators, etc. but none of that stuff erases how much of a miracle Rust is as a language. The industry really needed this. It's practically the poster child of memory safety and security-critical industries are picking it up and Ferrocene is pushing it in safety-critical environments as well and it's just. Good. Please. Finally a serious contender against the terrible reign of C and C++.
    - duped 2y ago
      > You can't have Foo<N> * Foo<M> -> Foo<N+M> or similar. You can though, unless I totally misunderstand your syntax use std::{marker::PhantomData, ops::{Add, Mul}}; pub struct Foo<T> { _p: PhantomData<T>, } impl<N, M> Mul<Foo<M>> for Foo<N> where N: Add<M> { type Output = Foo<<N as Add<M>>::Output>; fn mul(self, rhs: Foo<M>) -> Self::Output { todo!() } }
- IshKebab 2y ago
  I don't think he literally means templates and classes. Rust has equivalents that do the things you want templates and classes for (generics and structs/traits respectively). I completely agree with his point about reimplementing C++ badly in C. GNOME does this too in their libraries. He will be much happier with Rust.
  - Neywiny 2y ago
    Hmmm I think I actually really want classes. Something that combines data and methods together without more function pointers. Template vs generic I don't care about
    - rascul 2y ago
      Rust structs are in some ways similar to C++ classes. You can combine data and methods together with them without worrying about things like function pointers.
    - IshKebab 2y ago
      Rust structs do bind data and methods together.
  - justahuman74 2y ago
    On the other hand it seems like gobject was good for gnome as it made it easier to bind GTK to other languages
tejohnso 2y ago
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.
deleted 2y ago
[deleted]
winocm 2y ago
Yeah, even integrating any C++ into it and calling any QEMU functions via extern "C" declarations when including the headers cause many issues because many variables are named "new" or have type cast issues. It's a full time job on its own to fix all of the compilation errors. Could probably fix it with coccinelle scripts to make some parts easier, but still, validating the codebase with different compilers to make sure there's no resulting subtle breakage either still requires a lot of effort.
jefbyokyie 2y ago
C++23 is a godawful mess; especially the functional paradigms (which look beautiful in e.g. OCaml) that got shoehorned kicking and screaming into the morass that C++ had already been. If you read function specs in the OCaml docs, they're understandable and the syntax is clean; the same concepts bolted onto C++ look like line noise, both in actual syntax and the (allegedy) English-language description on en.cppreference.com. Reading the C++ standard itself is an exercise in futility, very much unlike the C standard. (Although, latest developments in C land are repulsive too, IMO.) The C++ committee's tantrums and scandals (physical violence at meetings!) put the worst that has been seen in open-source communities to shame. <https://izzys.casa/2024/11/on-safe-cxx/ https://izzys.casa/2024/11/on-safe-cxx/> has been posted to reddit and HN recently. C++ compilation still takes absolutely forever, and C++ template error messages are as incomprehensible as ever. One important problem with C++ (repeated ad nauseam, so this is nothing new) is the unforeseen and unintended harmful interactions between such language features that were supposed to be orthogonal. The only remedy for that is to stop adding stuff to the language; but nooo, it just keeps growing. Another important problem is that, the more the compiler does for you implicitly, the less you see (and the less you can debug) what happens in the code. This is not a problem in OCaml, which is a managed language with a safe runtime, but it's a huge problem in C++, which remains a fundamentally unsafe language. (And yes, once you start extending OCaml with C, i.e., mixing implicit and explicit, OCaml too becomes unsafe, and a lot of head-scratching can occur.) A home-grown object system in C is at least explicit, so it's all there for the developer to read, instrument, step through, and so on. When your "core guidelines" <https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines> could fill a book, there's a problem with your language. (I'm not here to defend QEMU's object model indiscriminately; I'm here to bash C++.)
- kstrauser 2y ago
  I cant believe I just read that entire izzys.case post. Wow. I couldn’t possibly assess it all for accuracy, but if that’s reasonably correct, just wow.

masklinn 2y ago

> I'm not a rust user but if it lets me use classes and templates, I'll switch over Yer not switching any time soon then. Rust does have methods but not classes (QOM’s inheritance is specifically called as an issue in TFA) and it uses Haskell-style generics rather than C++-style templates.

Neywiny 2y ago
:( the QOM inheritance is where I've had my wrist bugs. Recently I merged from master (upgrading me from version 8.something to 9.2.?) and they dramatically changed the resets. I tried the new way and had segfaults in bad places that went away when I reordered code that shouldn't have ordering requirements. That was too scary so I switched to their legacy reset function and it was all fine again. All this blind casting of opaques makes me nervous.
- bonzini 2y ago
  The legacy reset way is fine, and yeah this is where being more strict and doing more stuff within the language should help.
ThePhysicist 2y ago
I mean it has polymorphism via v-tables and composition via traits, that's enough object-orientation for me. Inheritance is a core principle of OOP but in practice most C++ class hierarchies are relatively flat (there are exceptions like Qt, which I think uses inheritance in a good way), in practice most of that can be mimicked with embedding and composition well enough to work. Not sure if you want to call that object-oriented but operating on polymorphous structures that encapsulate their data is pretty close to object orientation (the good parts of OOP, at least). And I'm not a big expert on Rust but I think you can do most of the things we do in C++ with templates using macros.
- galangalalgol 2y ago
  The one lagging thing that isn't easy with rust's generics is expressions, and that looks to be getting kicked down the road indefinitely. You can't have Foo<N> * Foo<M> -> Foo<N+M> or similar. That is a useful thing for statically sized math libraries and for performance oriented metaprogramming. The latter can be clumsily handled with macros, but not the former. It is also blocking portable simd from stabilizing, apparently now indefinitely. I still wouldn't pick any other language a new production product, but I find the stalling out on const generic expressions frustrating, as simd and static math libraries are things I use daily.
  - LoganDark 2y ago
    I could go on and on about the limitations of min_const_generics, missing TAIT (type alias impl trait), unstable coroutines/generators, etc. but none of that stuff erases how much of a miracle Rust is as a language. The industry really needed this. It's practically the poster child of memory safety and security-critical industries are picking it up and Ferrocene is pushing it in safety-critical environments as well and it's just. Good. Please. Finally a serious contender against the terrible reign of C and C++.
  - duped 2y ago
    > You can't have Foo<N> * Foo<M> -> Foo<N+M> or similar. You can though, unless I totally misunderstand your syntax use std::{marker::PhantomData, ops::{Add, Mul}}; pub struct Foo<T> { _p: PhantomData<T>, } impl<N, M> Mul<Foo<M>> for Foo<N> where N: Add<M> { type Output = Foo<<N as Add<M>>::Output>; fn mul(self, rhs: Foo<M>) -> Self::Output { todo!() } }
IshKebab 2y ago
I don't think he literally means templates and classes. Rust has equivalents that do the things you want templates and classes for (generics and structs/traits respectively). I completely agree with his point about reimplementing C++ badly in C. GNOME does this too in their libraries. He will be much happier with Rust.
- Neywiny 2y ago
  Hmmm I think I actually really want classes. Something that combines data and methods together without more function pointers. Template vs generic I don't care about
  - rascul 2y ago
    Rust structs are in some ways similar to C++ classes. You can combine data and methods together with them without worrying about things like function pointers.
  - IshKebab 2y ago
    Rust structs do bind data and methods together.
- justahuman74 2y ago
  On the other hand it seems like gobject was good for gnome as it made it easier to bind GTK to other languages

tejohnso 2y ago

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.

deleted 2y ago

[deleted]

winocm 2y ago

Yeah, even integrating any C++ into it and calling any QEMU functions via extern "C" declarations when including the headers cause many issues because many variables are named "new" or have type cast issues. It's a full time job on its own to fix all of the compilation errors. Could probably fix it with coccinelle scripts to make some parts easier, but still, validating the codebase with different compilers to make sure there's no resulting subtle breakage either still requires a lot of effort.

jefbyokyie 2y ago

C++23 is a godawful mess; especially the functional paradigms (which look beautiful in e.g. OCaml) that got shoehorned kicking and screaming into the morass that C++ had already been. If you read function specs in the OCaml docs, they're understandable and the syntax is clean; the same concepts bolted onto C++ look like line noise, both in actual syntax and the (allegedy) English-language description on en.cppreference.com. Reading the C++ standard itself is an exercise in futility, very much unlike the C standard. (Although, latest developments in C land are repulsive too, IMO.) The C++ committee's tantrums and scandals (physical violence at meetings!) put the worst that has been seen in open-source communities to shame. <https://izzys.casa/2024/11/on-safe-cxx/ https://izzys.casa/2024/11/on-safe-cxx/> has been posted to reddit and HN recently. C++ compilation still takes absolutely forever, and C++ template error messages are as incomprehensible as ever. One important problem with C++ (repeated ad nauseam, so this is nothing new) is the unforeseen and unintended harmful interactions between such language features that were supposed to be orthogonal. The only remedy for that is to stop adding stuff to the language; but nooo, it just keeps growing. Another important problem is that, the more the compiler does for you implicitly, the less you see (and the less you can debug) what happens in the code. This is not a problem in OCaml, which is a managed language with a safe runtime, but it's a huge problem in C++, which remains a fundamentally unsafe language. (And yes, once you start extending OCaml with C, i.e., mixing implicit and explicit, OCaml too becomes unsafe, and a lot of head-scratching can occur.) A home-grown object system in C is at least explicit, so it's all there for the developer to read, instrument, step through, and so on. When your "core guidelines" <https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines> could fill a book, there's a problem with your language. (I'm not here to defend QEMU's object model indiscriminately; I'm here to bash C++.)

kstrauser 2y ago
I cant believe I just read that entire izzys.case post. Wow. I couldn’t possibly assess it all for accuracy, but if that’s reasonably correct, just wow.