Re: [Qemu-devel] [PATCH v2 00/16] arm: A9MPCore+A15MPCore QOM'ification

["Andreas Färber" <afaerber@suse.de>]

Am 23.07.2013 23:52, schrieb Peter Maydell:
> On 23 July 2013 22:36, Alexander Graf <agraf@suse.de> wrote:
>> Am 23.07.2013 um 23:16 schrieb Peter Maydell <peter.maydell@linaro.org>:
>>> On 23 July 2013 20:15, Peter Maydell <peter.maydell@linaro.org> wrote:
[C needing access to full struct definition for composite use]
>>>> I had a thought about this. Suppose we have our class header
>>>> files do something like this:
>>>>
>>>> #ifdef MYCLASS_IMPLEMENTATION
>>>> #define PRIVATE
>>>> #else
>>>> #ifdef __GNUC__
>>>> #define PRIVATE __attribute__((deprecated("this is a private field")))
>>>> #else
>>>> #define PRIVATE
>>>> #endif
>>>>
>>>> typedef struct MyObject {
>>>>   int publicfield;
>>>>   int privatefield PRIVATE;
>>>> } MyObject;
>>>
>>> Forgot to say, but if people don't think this is an
>>> intrinsically terrible idea I'll put together a patch that
>>> does this sometime this week.
>>
>> I like the idea, but could we make this slightly less upper case? Something like
>>
>>   __private int privatefield;
>>
>> feels more readable imho.
> 
> Well, __ is using the reserved namespace, but we could use something
> else, and it looks like gcc lets us put the attribute at the front.
> Since we'll want to undef whatever we pick after the struct is defined
> we can actually use pretty much anything without worrying about it
> stealing namespace.
> (We could even use just 'private' if we didn't mind (a) not being
> able to compile with a C++ compiler

We still have many occurrences of "klass" around as proof that we try to
be C++ compatible. ;)

> and (b) confusing everybody
> completely :-))

I wouldn't generally mind annotating fields. But let's ask Michael about
this - QIDL tried to annotate fields in a similar way for migration status.

>> Or maybe
>>
>> struct MyObject {
>>   PUBLIC_FIELDS
>>   __field int publicfield;
>>   PRIVATE_FIELDS
>>   __field int privatefield;
>> }
> 
> I can't see an obvious way to make those do the right
> thing with the C preprocessor... am I missing something?

gtk-doc wouldn't understand that, and I can't think of a way that
PRIVATE_FIELDS could redefine __field (or field) to do the right thing.

Anyway, before we get lost in a bikeshed discussion, if the
underscore'ization of the type names is to everyone's liking now, I
would very much like to queue the QOM cast patches on qom-next
(independent of whether you apply parts of the series to arm-devs.next).

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg