|
From: | Avi Kivity |
Subject: | [Qemu-devel] Re: [PATCH 01/25] Introduce QEMU dictionary data type |
Date: | Wed, 29 Jul 2009 17:37:31 +0300 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Lightning/1.0pre Thunderbird/3.0b2 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |