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

[Stefan Hajnoczi]

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). Also, once C++ is available people will
start submitting C++ patches simply because they are more comfortable
with C++ (especially one-time/infrequent contributors).

We need to agree on a policy so that people know how and when they can
use C++.

The policy needs to be simple so it doesn't create hurdles for new
contributors.

Does anyone have experience with C projects that introduced C++ and what
worked/didn't work?

Stefan

signature.asc
Description: PGP signature