From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MWAD7-0003Jn-Kr
	for qemu-devel@nongnu.org; Wed, 29 Jul 2009 10:32:53 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MWAD2-000389-JM
	for qemu-devel@nongnu.org; Wed, 29 Jul 2009 10:32:52 -0400
Received: from [199.232.76.173] (port=53660 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MWAD2-00037k-Fy
	for qemu-devel@nongnu.org; Wed, 29 Jul 2009 10:32:48 -0400
Received: from mx2.redhat.com ([66.187.237.31]:34339)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <avi@redhat.com>) id 1MWAD2-0004lw-2F
	for qemu-devel@nongnu.org; Wed, 29 Jul 2009 10:32:48 -0400
Message-ID: <4A705EAB.1030200@redhat.com>
Date: Wed, 29 Jul 2009 17:37:31 +0300
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
References: <1248818713-11261-1-git-send-email-lcapitulino@redhat.com>	<1248818713-11261-2-git-send-email-lcapitulino@redhat.com>	<4A701AA3.4060902@redhat.com>	<20090729104600.17deb355@doriath>	<4A705536.3020305@redhat.com>
	<20090729112220.16ffe414@doriath>
In-Reply-To: <20090729112220.16ffe414@doriath>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: [PATCH 01/25] Introduce QEMU dictionary data type
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Luiz Capitulino <lcapitulino@redhat.com>
Cc: jan.kiszka@siemens.com, aliguori@us.ibm.com, dlaor@redhat.com, qemu-devel@nongnu.org

On 07/29/2009 05:22 PM, Luiz Capitulino wrote:
>
>    
>> I meant QObject as a base type, so it is a lower layer than QDict; QDict
>> implements the QObject methods, as do QString, QNumber, etc.
>>      
>
>   Ok, I'm failing at imagining "QDict implements the QObject methods"
> in C, can you elaborate more and/or sketch something?
>    

It's really no different than in other languages, except that you have 
to write a ton of boilerplate.  The kernel is riddled with object 
hierarchies:

typedef struct QType {
     const char *name;
     void (*destroy)(QObject *);
     QObject *(*clone)(QObject *)
} QType;

typedef struct QObject {
    QType *type;
} QObject;

typedef struct QDict {
     QObject base;
     // hash stuff
} QDict;

static QType qdict_type = {
   .destroy = qdict_destroy,
   .clone = qdict_clone,
};

QObject *qobject_clone(QObject *obj) { return obj->type->clone(obj); }

QObject *qdict_clone(QObject *obj)
{
     ...
}

>> The problem with void *, beyond requiring the user to know what the
>> object type is, is that it is impossible to control object lifecycle.
>> When you destroy a QDict containing void *, you cannot destroy the
>> contained objects.  On the other hand if QDict values are all QObjects,
>> then qdict_destroy() can call qobject_destroy() on all of them
>> (qobject_destroy might end up calling qdict_destroy() is a value
>> happened to be a QDict).
>>      
>
>   Right, but as you said in other email, can we get this merged first
> and then improve or should I do the change for this series?
>    

I think we should merge first, doing this sort of change on a 25-patch 
series is no fun.

-- 
error compiling committee.c: too many arguments to function