From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59247) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1kkp-0000wU-90 for qemu-devel@nongnu.org; Tue, 23 Jul 2013 18:08:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V1kko-0005LT-1B for qemu-devel@nongnu.org; Tue, 23 Jul 2013 18:08:23 -0400 Received: from cantor2.suse.de ([195.135.220.15]:59416 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1kkn-0005LH-PK for qemu-devel@nongnu.org; Tue, 23 Jul 2013 18:08:21 -0400 Message-ID: <51EEFECD.9070706@suse.de> Date: Wed, 24 Jul 2013 00:08:13 +0200 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1374547404-11700-1-git-send-email-afaerber@suse.de> <4E04E931-F4B5-45A7-8F22-7DE7F7174A59@suse.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v2 00/16] arm: A9MPCore+A15MPCore QOM'ification List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell , Alexander Graf , Michael Roth Cc: Hu Tao , Peter Crosthwaite , "qemu-devel@nongnu.org" , Anthony Liguori , "kvmarm@lists.cs.columbia.edu" Am 23.07.2013 23:52, schrieb Peter Maydell: > On 23 July 2013 22:36, Alexander Graf wrote: >> Am 23.07.2013 um 23:16 schrieb Peter Maydell : >>> On 23 July 2013 20:15, Peter Maydell 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? Some= thing like >> >> __private int privatefield; >> >> feels more readable imho. >=20 > 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 statu= s. >> Or maybe >> >> struct MyObject { >> PUBLIC_FIELDS >> __field int publicfield; >> PRIVATE_FIELDS >> __field int privatefield; >> } >=20 > 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 --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg