From: Warner Losh <imp@bsdimp.com>
To: Thomas Huth <thuth@redhat.com>
Cc: Roman Kiryanov <rkir@google.com>,
QEMU Developers <qemu-devel@nongnu.org>,
JP Cottin <jpcottin@google.com>,
Erwin Jansen <jansene@google.com>
Subject: Re: QEMU headers in C++
Date: Thu, 2 May 2024 08:47:15 -0600 [thread overview]
Message-ID: <CANCZdfo-YFs+A_oW55qE6U4GdbHz7GaeqNqGofK2jgk+Y=L4SA@mail.gmail.com> (raw)
In-Reply-To: <e04bd44b-8a91-48c0-9fbf-223d1b28e7cd@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2774 bytes --]
On Thu, May 2, 2024 at 12:20 AM Thomas Huth <thuth@redhat.com> wrote:
> On 02/05/2024 06.40, Roman Kiryanov wrote:
> > Hi QEMU,
> >
> > I work in Android Studio Emulator and we would like to develop devices
> > in C++. Unfortunately, QEMU headers cannot be used with C++ as is
> > (e.g. they use C++ keywords as variable names or implicitly cast void*
> > to T*).
>
> Can't you simply use something like:
>
> extern "C" {
> #include <foo.h>
> }
>
> to include the QEMU headers?
>
No.
All that does is not mangle the functions and requires that none of them be
overloaded.
It doesn't otherwise change the language that you're compiling, so the
implicit casts
from void * to T * are still verboten. It also doesn't change the keywords
that are accepted.
I'm not in the main line of qemu development, but I'll share what FreeBSD
has done in
this area. We've bracketed the functions in our .h files with __BEGIN_DECLS
/ __END_DECLS
which are defined away in C but not C++ (to allow it to turn into extern
"C" { and } respectively).
We avoid C++ keywords (mostly the word class). Our headers don't have a lot
of inlines in them,
but the few that do we'll make sure they don't have the implicit casts
(though the style we inherited
from CSRG / Research Unix was to always cast). For FreeBSD, we have about a
dozen different
compilation environments that we need to work in, so we also have a bunch
of other macros that
let us use newer C features in headers, but that make them disappear when
someone is building
a pure C90 program. These are quite a bit more intrusive, imho, but still
not bad. So maybe that
context might explain why my initial reaction was "oh, that's not too bad".
If you didn't want to do the __BEGIN_DECLS / __END_DECLS dance (which isn't
a super unreasonable
position), then avoiding keywords is easy enough and usually unobtrusive...
but the implicit cast bits
might be harder to deal with if there's a lot of code that does it.
The hardest part for us has been keeping things working with C++. Though
90% of it naturally is tested
in building FreeBSD because we have just enough C++ that's old-school
enough to include many of
the system headers :). QEMU would need to test it, and that might otherwise
require a C++ compiler
for some builds that wouldn't need one today.
I don't know if the main line developers would be willing to pay this "tax"
or not. I'm not advocating
either way, per se, but would suggest that if the tax is super low and the
benefit to others high, I'd
go for it. In the absence of the scope of the patches, though, it's hard to
say of this amount of C++
would enable more technology than it inhibits by being a drag on future
development.
Warner
[-- Attachment #2: Type: text/html, Size: 3564 bytes --]
next prev parent reply other threads:[~2024-05-02 14:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-02 4:40 QEMU headers in C++ Roman Kiryanov
2024-05-02 6:19 ` Thomas Huth
2024-05-02 14:47 ` Warner Losh [this message]
2024-05-02 8:02 ` Daniel P. Berrangé
2024-05-02 15:17 ` Peter Maydell
[not found] <a href="raw">
[not found] ` </a>
2024-05-02 15:19 ` Paolo Bonzini
2024-05-02 16:04 ` Roman Kiryanov
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='CANCZdfo-YFs+A_oW55qE6U4GdbHz7GaeqNqGofK2jgk+Y=L4SA@mail.gmail.com' \
--to=imp@bsdimp.com \
--cc=jansene@google.com \
--cc=jpcottin@google.com \
--cc=qemu-devel@nongnu.org \
--cc=rkir@google.com \
--cc=thuth@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).