Am 23.07.2013 23:52, schrieb Peter Maydell:
> On 23 July 2013 22:36, Alexander Graf <agraf@xxxxxxx> wrote:
>> Am 23.07.2013 um 23:16 schrieb Peter Maydell <peter.maydell@xxxxxxxxxx>:
>>> On 23 July 2013 20:15, Peter Maydell <peter.maydell@xxxxxxxxxx> 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
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
