On 23.07.2013, at 23:52, Peter Maydell wrote:
> 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:
>>>> 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.
Very nice :). And it aligns pretty well with the __user hint in Linux.
> (We could even use just 'private' if we didn't mind (a) not being
> able to compile with a C++ compiler and (b) confusing everybody
> completely :-))
>
>> 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?
No, I'm probably just daydreaming :). Macros can't redefine other defines, so this probably won't work....
So yes, prepending the visibility on every field seems to be the most straight forward choice.
Alex
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
