From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:53161) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RhsgC-0005LR-6Y for qemu-devel@nongnu.org; Mon, 02 Jan 2012 19:56:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RhsgB-0000U2-5T for qemu-devel@nongnu.org; Mon, 02 Jan 2012 19:56:40 -0500 Received: from mail-iy0-f173.google.com ([209.85.210.173]:58886) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RhsgB-0000Tx-0T for qemu-devel@nongnu.org; Mon, 02 Jan 2012 19:56:39 -0500 Received: by iagj37 with SMTP id j37so34855421iag.4 for ; Mon, 02 Jan 2012 16:56:38 -0800 (PST) Message-ID: <4F025241.1050405@codemonkey.ws> Date: Mon, 02 Jan 2012 18:56:33 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <1324399916-21315-1-git-send-email-aliguori@us.ibm.com> <1324399916-21315-2-git-send-email-aliguori@us.ibm.com> <4EF1E094.6080500@redhat.com> <4EF1EEA4.40209@us.ibm.com> <20111222172531.GA24638@morn.localdomain> <4EF36BB4.1070405@codemonkey.ws> <20111222180018.GA29733@morn.localdomain> <4EF38BA0.1090706@codemonkey.ws> <4F023733.2070700@suse.de> In-Reply-To: <4F023733.2070700@suse.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH 01/27] qom: add the base Object class List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?ISO-8859-1?Q?Andreas_F=E4rber?= Cc: Paolo Bonzini , Anthony Liguori , Kevin O'Connor , qemu-devel@nongnu.org, Markus Armbruster On 01/02/2012 05:01 PM, Andreas Färber wrote: > Am 22.12.2011 20:57, schrieb Anthony Liguori: >> On 12/22/2011 12:00 PM, Kevin O'Connor wrote: >>> On Thu, Dec 22, 2011 at 11:41:08AM -0600, Anthony Liguori wrote: >>>> On 12/22/2011 11:25 AM, Kevin O'Connor wrote: >>>>> Why not declare types with something like the following: >>>>> >>>>> TypeInfo my_device_info = { >>>>> .name = "my-device", >>>>> .parentinfo =&device_info, >>>>> .instance_size = sizeof(MyDevice), >>>>> }; >>>>> >>>>> That is, instead of looking up the TypeImpl via a string, lookup the >>>>> TypeImpl via the address of the TypeInfo. (Or possibly store a >>>>> pointer to TypeImpl in TypeInfo during registration.) > [...] >> Yes, thinking about it, I think you're correct that .parent could refer >> to some sort of type handle. >> >> But I think it's a bit nicer to have a string identify the parent type >> than an extern struct. I guess it's more a matter of taste than >> anything else :-) > > The advantage of using some kind of symbolic name is that the compiler > helps us avoid typos. If we use strings, we defer the checking to the > actual instantiation at runtime. That's why I use #define's to make a symbol for the types. The only reason that's not done universally is it would be a bit challenging to script the conversion to do that (I though I did attempt it a couple times). Regards, Anthony Liguori > > Andreas >