Re: [Qemu-devel] [RFC] [tcg] Idea on refactoring target code generation loop (gen_intermediate_code)

[Markus Armbruster <armbru@redhat.com>]

Paolo Bonzini <pbonzini@redhat.com> writes:

> On 07/04/2016 16:49, Peter Maydell wrote:
>> > QOM to C++ classes
>> I suspect if you looked at this you'd find that the QOM semantics
>> for various things don't map onto C++ (ie that we have more runtime
>> flexibility than C++ does).
>
> True, but you don't have to use it. :)  If your code is static, one
> could imagine bindings to C++ that eliminate some of the boilerplate.
> Don't look at me, though.
>
> On the other hand, minimal usage of templates instead of some of the
> preprocessor gunk we have would be a very good thing IMNSHO.  I am
> referring to the multiply included header files and to the macros with
> type arguments (mostly QOM casts).
>
> I don't think we need more C++ than that, but using templates as
> basically a type-safe preprocessor would improve QEMU a little bit.
> More rarely, lambdas could replace some preprocessor magic too, but
> that's C11 and not many compilers support them.
>
> But I won't weep if people say no because we have a lot other
> low-hanging fruit to make QEMU better (especially the header file

"No!"  (Hey, you asked for it)

Back to serious.  As Peter Maydell said, "if we move away from C I'd
rather it to be a language that's nicer than C rather than one that's
uglier and larger and still retains all of C's flaws."

People sometimes propose to defang C++ by subsetting and/or coding
conventions.  I'll take that seriously when I see the tool that
rigorously checks adherence to subset / convention.  We're bad enough at
getting everybody write half-decent C, and making the problem harder is
unlikely to help.

> cleanups that Markus started and I want to conclude very early in 2.7).

Speaking of which: the plan was you post yours for 2.7, and then I can
build on top (assuming there's useful work left), right?