qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Integrating QOM into QAPI


From: Christophe de Dinechin
Subject: Re: Integrating QOM into QAPI
Date: Mon, 27 Jan 2020 20:05:36 +0100


> On 26 Jan 2020, at 16:04, Peter Maydell <address@hidden> wrote:
> 
> On Sun, 26 Jan 2020 at 08:10, Christophe de Dinechin
> <address@hidden> wrote:
>> I’m still puzzled as to why anybody would switch to something like
>> GObject when there is C++.
> 
> I'm fairly strongly against using C++.

Just to be clear, so am I ;-)

> C++'s language design
> is an "everything including the kitchen sink, lots of "this
> is here for back compat but it's a bear trap", lots of new
> stuff arriving all the time.

Actually, the new stuff is not that bad, overall.

I do agree C++ is an overly complicated language, and that in
practice, there is zero chance of qemu moving to it. But that does
not invalidate my point that creating a class in C++ is easier
than creating a class in any C-based macro-heavy reinvention
of basic OO concepts.

(I write this after having read Paolo’s response, which points
out IMO better reasons for GObject, which I will discuss there).

> It's just too big to keep in
> your head all at once. C has its faults, absolutely, but at
> least it tries to be a reasonably sized vaguely coherent
> language.
> 
> You'd have more luck persuading me we should move to Rust:
> at least then we'd get some clear benefits (no more buffer
> overrun security bugs) for the upheaval :-)

This is largely a myth as soon as you need to do “your own stuff”.
Example: CVE-2019-18960, https://seclists.org/oss-sec/2019/q4/141.

> 
> thanks
> -- PMM
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]