On Thu, May 2, 2024 at 12:20 AM Thomas Huth <th...@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
