All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Hanna Reitz <hreitz@redhat.com>
Cc: kwolf@redhat.com, Peter Maydell <peter.maydell@linaro.org>,
	berrange@redhat.com, qemu-block@nongnu.org,
	qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH experiment 00/16] C++20 coroutine backend
Date: Thu, 31 Mar 2022 13:37:17 +0200	[thread overview]
Message-ID: <875ynuqro2.fsf@pond.sub.org> (raw)
In-Reply-To: <66f70dc8-2899-b837-0a9f-572737d64856@redhat.com> (Hanna Reitz's message of "Thu, 17 Mar 2022 16:53:13 +0100")

Hanna Reitz <hreitz@redhat.com> writes:

> On 17.03.22 16:11, Paolo Bonzini wrote:
>> On 3/16/22 13:32, Stefan Hajnoczi wrote:
>>> You can define rules and a way to enforce a subset of C++, but I think
>>> over time the code will be C++. A policy that is complicated discourages
>>> contributors.
>>>
>>> For these reasons I think that if code runs through a C++ compiler we
>>> should just allow C++. Either way, it will take time but that way no one
>>> will feel betrayed when C++ creeps in.
>>
>> Fair enough.  We even already have some conventions that will make
>> any C++ that creeps in less weird (for example, mandatory typedef of 
>> structs).
>>
>> I don't think it would be a big deal overall.  I actually agree that
>> we should "just allow C++", what matters more to have style rules
>> that make QEMU's flavors of C and C++ consistent.
>
> I just want to throw in that I personally am absolutely not confident
> in reviewing C++ code.

Me neither.

>                         As for Rust, you keep mentioning that we don’t
> have anyone who would “shepherd us through the learning experience”,
> but I find the very same argument applies to C++.
>
> C++ may start out looking like C, but if used ideally, then it is a
> very different language, too.  I understand the difference is that we
> can incrementally convert our C code to C++,

Bad C++ in need of rework, presumably.

>                                              but I’m not comfortable 
> overseeing that process, which I would have to do as a maintainer. 

That makes two of us.

The plain language version of "I'm not comfortable serving" is of course
"I do not intend to serve".

> Assuming our overall stance does change to “just allowing C++”, I’d
> feel unjust if I were to reject C++isms just based on the fact that I
> don’t know C++, so I’d be forced to learn C++.  I’m not strictly
> opposed to that (though from experience I’m more than hesitant), but
> forcing maintainers to learn C++ is something that has a cost
> associated with it.

I'm a lot more interested in learning Rust than in (re-)learning C++.

> My biggest gripe about C++ is that as far as I understand there are
> many antipatterns, many of which I think stem from the exact fact that
> it is kind of compatible with C, and so you can easily accidentally
> write really bad C++ code; but without years of experience, I’m
> absolutely not confident that I could recognize them.  Now, I might
> say I’d just disallow complicated stuff, and keep everything C-like,
> but from what I’ve heard, C-like C++ seems to be exactly one case that
> is considered bad C++.  I’m really under the impression that I’d need
> years of experience to discern good from bad C++, and I don’t have
> that experience.

Right.



  reply	other threads:[~2022-03-31 11:44 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-14  9:31 [PATCH experiment 00/16] C++20 coroutine backend Paolo Bonzini
2022-03-14  9:31 ` [PATCH experiment 01/16] coroutine: add missing coroutine_fn annotations for CoRwlock functions Paolo Bonzini
2022-03-14  9:31 ` [PATCH experiment 02/16] coroutine: qemu_coroutine_get_aio_context is not a coroutine_fn Paolo Bonzini
2022-03-14  9:31 ` [PATCH experiment 03/16] coroutine: small code cleanup in qemu_co_rwlock_wrlock Paolo Bonzini
2022-03-14 13:32   ` Philippe Mathieu-Daudé
2022-03-14  9:31 ` [PATCH experiment 04/16] coroutine: introduce QemuCoLockable Paolo Bonzini
2022-03-14  9:31 ` [PATCH experiment 05/16] port atomic.h to C++ Paolo Bonzini
2022-03-14  9:31 ` [PATCH experiment 06/16] use g_new0 instead of g_malloc0 Paolo Bonzini
2022-03-14 11:16   ` Markus Armbruster
2022-03-14  9:31 ` [PATCH experiment 07/16] start porting compiler.h to C++ Paolo Bonzini
2022-03-14  9:31 ` [PATCH experiment 08/16] tracetool: add extern "C" around generated headers Paolo Bonzini
2022-03-14 13:33   ` Philippe Mathieu-Daudé
2022-03-14 13:44     ` Paolo Bonzini
2022-03-14  9:31 ` [PATCH experiment 09/16] start adding extern "C" markers Paolo Bonzini
2022-03-14  9:31 ` [PATCH experiment 10/16] add space between liter and string macro Paolo Bonzini
2022-03-14  9:31 ` [PATCH experiment 11/16] bump to C++20 Paolo Bonzini
2022-03-14  9:31 ` [PATCH experiment 12/16] remove "new" keyword from trace-events Paolo Bonzini
2022-03-14 13:30   ` Philippe Mathieu-Daudé
2022-03-14  9:32 ` [PATCH experiment 13/16] disable some code Paolo Bonzini
2022-03-14  9:32 ` [PATCH experiment 14/16] util: introduce C++ stackless coroutine backend Paolo Bonzini
2022-03-14 14:37   ` Stefan Hajnoczi
2022-03-14 19:36     ` Paolo Bonzini
2022-03-14  9:32 ` [PATCH experiment 15/16] port QemuCoLockable to C++ coroutines Paolo Bonzini
2022-03-14  9:32 ` [PATCH experiment 16/16] port test-coroutine " Paolo Bonzini
2022-03-14 14:07 ` [PATCH experiment 00/16] C++20 coroutine backend Stefan Hajnoczi
2022-03-14 16:21   ` Paolo Bonzini
2022-03-14 19:51     ` Richard Henderson
2022-03-15 14:05     ` Stefan Hajnoczi
2022-03-15 14:24       ` Peter Maydell
2022-03-15 17:29         ` Paolo Bonzini
2022-03-16 12:32           ` Stefan Hajnoczi
2022-03-16 13:06             ` Daniel P. Berrangé
2022-03-16 16:44               ` Stefan Hajnoczi
2022-03-17 15:11             ` Paolo Bonzini
2022-03-17 15:53               ` Hanna Reitz
2022-03-31 11:37                 ` Markus Armbruster [this message]
2022-03-15 14:50       ` Kevin Wolf
2022-03-15 15:35         ` Stefan Hajnoczi
2022-03-15 15:55         ` Daniel P. Berrangé
2022-03-15 23:08           ` Paolo Bonzini
2022-03-16 12:40             ` Stefan Hajnoczi
2022-03-16 16:15               ` Kevin Wolf
2022-03-17 12:16             ` Dr. David Alan Gilbert
2022-03-17 12:51             ` Daniel P. Berrangé
2022-03-31 11:52           ` Markus Armbruster
2022-03-15 17:23         ` When and how to use C++ (was Re: [PATCH experiment 00/16] C++20 coroutine backend) Paolo Bonzini
2022-03-14 16:52 ` [PATCH experiment 00/16] C++20 coroutine backend Daniel P. Berrangé
2022-03-15  9:05   ` Paolo Bonzini
2022-03-15  9:32     ` Daniel P. Berrangé
2022-03-15 17:27       ` Paolo Bonzini
2022-03-15 18:12         ` Daniel P. Berrangé
2022-03-15 16:15 ` Daniel P. Berrangé
2022-03-15 17:50   ` Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=875ynuqro2.fsf@pond.sub.org \
    --to=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=hreitz@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.