Re: [PATCH experiment 00/16] C++20 coroutine backend

[Paolo Bonzini]

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. :)

Thanks,

Paolo

[1] One big advantage of STL containers for example is that 
std::vector<> automatically constructs objects instead of just filling 
memory with zero (or leaving it uninitialized).  But that doesn't really 
matter if we don't use classes with constructors.