Am 15.03.2022 um 15:05 hat Stefan Hajnoczi geschrieben: > On Mon, Mar 14, 2022 at 05:21:22PM +0100, Paolo Bonzini wrote: > > On 3/14/22 15:07, Stefan Hajnoczi wrote: > > > If we can reach a consensus about C++ language usage in QEMU then I'm in > > > favor of using C++ coroutines. It's probably not realistic to think we > > > can limit C++ language usage to just coroutines forever. Someone finds > > > another C++ feature they absolutely need and over time the codebase > > > becomes C++ - with both its advantages and disadvantages. > > > > > > [...] although you can write C in C++, it's not idiomatic modern C++. > > > The language lends itself to a different style of programming that > > > some will embrace while others will not. > > > > Yes, this is an important aspect to discuss. I think coroutines provide a > > good blueprint for how QEMU might use C++. > > > > I totally agree that, if we go this way, the genie is out of the bottle and > > other uses of C++ will pop up with 100% probability. But the important > > thing to note is that our dialect of C is already not standard C, and that > > some of our or GLib's "innovations" are actually based on experience with > > C++. We can keep on writing "QEMU's C" if we think of C++ as a supercharged > > way of writing these quality-of-life improvements that we already write. In > > some sense coroutines are an extreme example of this idea. > > > > In fact, a C API would have to remain unless all source files are changed to > > C++, so QEMU would remain mostly a C project with C idioms, but that doesn't > > prevent _abstracting_ the use of C++ features (written in modern, idiomatic > > C++) behind an API that C programmers have no problems learning. Again, > > coroutines are an example of this of keeping the familiar create/enter/yield > > API and hiding the "magic" of C++ coroutines (and when they don't, that had > > better be an improvement). > > > > In the end, C++ is a tool that you can use if it leads to better code. For > > example, I don't see much use of C++ for devices for example, and the > > storage devices in particular do not even need coroutines because they use > > the callback-based interface. But perhaps someone will try to use templates > > to replace repeated inclusion (which is common in hw/display) and others > > will follow suit. Or perhaps not. > > > > One example that was brought up on IRC is type-safe operations on things > > such as hwaddr (i.e. hwaddr+int is allowed but hwaddr-hwaddr gives back an > > int64_t and might even check for overflow). These would be opt in (you get > > them just by changing a file from .c to .cc), but the actual C++ code would > > still look very much like C code that uses hwaddr with no type checking. > > All the operator overloading gunk would be in include/. > > > > A different topic is what would happen if all of QEMU could be compiled as > > C++, and could inform our selection of C++ idioms even long before we get > > there. For example, I'm fine with GLib and our type-safe intrusive lists, > > so I don't have much interest in STL containers and I would prefer _not_ to > > use STL containers even in .cc files[1]. However, perhaps QEMU's home-grown > > lock guard might be replaced by something that uses C++ destructors instead > > of g_autoptr, so perhaps we should consider using std::lock_guard<>, or > > something like that, instead of QEMU_LOCK_GUARD. It may be interesting to > > pass down lock_guards as arguments to enforce "this lock is taken" > > invariants. > > > > But really, coroutines would be enough work so my dish would be full for > > some time and I wouldn't really have time to look at any of this. :) > > I think it will be necessary to compile QEMU with a C++ compiler quite > soon. It is possible to provide C APIs like in the case of coroutines, > but sometimes C++ features need to be exposed to the caller (like the > lock guards you mentioned).
I'm not sure what the C++ lock guards offer that our current lock guards don't? Passing down lock guards makes sense to me, but why can't you do that with QemuLockable? (Hm, or can the C++ version somehow check at compile time that it's the _right_ lock that is held rather than just any lock? It didn't look like it at the first sight.) But I do see the benefit of a compiler checked CoroutineFn<> return type compared to the coroutine_fn markers we have today. On the other hand... > Also, once C++ is available people will start submitting C++ patches > simply because they are more comfortable with C++ (especially > one-time/infrequent contributors). ...using C++ in coroutine code means that all of the block layer would suddenly become C++ and would be most affected by this effect. I'm not sure if that's something I would like to see, at least until there is a clear tree-wide policy (that preferably limits it to a subset that I understand). Kevin
signature.asc
Description: PGP signature
