Hanna Reitz <hre...@redhat.com> writes: > On 17.03.22 16:11, Paolo Bonzini wrote: >> On 3/16/22 13:32, Stefan Hajnoczi wrote: >>> You can define rules and a way to enforce a subset of C++, but I think >>> over time the code will be C++. A policy that is complicated discourages >>> contributors. >>> >>> For these reasons I think that if code runs through a C++ compiler we >>> should just allow C++. Either way, it will take time but that way no one >>> will feel betrayed when C++ creeps in. >> >> Fair enough. We even already have some conventions that will make >> any C++ that creeps in less weird (for example, mandatory typedef of >> structs). >> >> I don't think it would be a big deal overall. I actually agree that >> we should "just allow C++", what matters more to have style rules >> that make QEMU's flavors of C and C++ consistent. > > I just want to throw in that I personally am absolutely not confident > in reviewing C++ code.
Me neither. > As for Rust, you keep mentioning that we don’t > have anyone who would “shepherd us through the learning experience”, > but I find the very same argument applies to C++. > > C++ may start out looking like C, but if used ideally, then it is a > very different language, too. I understand the difference is that we > can incrementally convert our C code to C++, Bad C++ in need of rework, presumably. > but I’m not comfortable > overseeing that process, which I would have to do as a maintainer. That makes two of us. The plain language version of "I'm not comfortable serving" is of course "I do not intend to serve". > Assuming our overall stance does change to “just allowing C++”, I’d > feel unjust if I were to reject C++isms just based on the fact that I > don’t know C++, so I’d be forced to learn C++. I’m not strictly > opposed to that (though from experience I’m more than hesitant), but > forcing maintainers to learn C++ is something that has a cost > associated with it. I'm a lot more interested in learning Rust than in (re-)learning C++. > My biggest gripe about C++ is that as far as I understand there are > many antipatterns, many of which I think stem from the exact fact that > it is kind of compatible with C, and so you can easily accidentally > write really bad C++ code; but without years of experience, I’m > absolutely not confident that I could recognize them. Now, I might > say I’d just disallow complicated stuff, and keep everything C-like, > but from what I’ve heard, C-like C++ seems to be exactly one case that > is considered bad C++. I’m really under the impression that I’d need > years of experience to discern good from bad C++, and I don’t have > that experience. Right.