From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MWA36-0003m7-UO for qemu-devel@nongnu.org; Wed, 29 Jul 2009 10:22:33 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MWA32-0003im-6p for qemu-devel@nongnu.org; Wed, 29 Jul 2009 10:22:32 -0400 Received: from [199.232.76.173] (port=42490 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MWA31-0003ih-Tu for qemu-devel@nongnu.org; Wed, 29 Jul 2009 10:22:27 -0400 Received: from mx2.redhat.com ([66.187.237.31]:39175) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MWA31-0002ZA-Af for qemu-devel@nongnu.org; Wed, 29 Jul 2009 10:22:27 -0400 Date: Wed, 29 Jul 2009 11:22:20 -0300 From: Luiz Capitulino Message-ID: <20090729112220.16ffe414@doriath> In-Reply-To: <4A705536.3020305@redhat.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 01/25] Introduce QEMU dictionary data type List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: jan.kiszka@siemens.com, aliguori@us.ibm.com, dlaor@redhat.com, qemu-devel@nongnu.org On Wed, 29 Jul 2009 16:57:10 +0300 Avi Kivity wrote: > On 07/29/2009 04:46 PM, Luiz Capitulino wrote: > >> > >> I'm worried about all those void *s as they move responsibility for type > >> safety and lifecycle management to the user. I'd much rather see a > >> QObject (or Object) with the following methods: > >> > >> clone() - deep copy an object; dicts will store copies so we'll avoid > >> those leaks or a dictionary member modified after it was stored > >> destroy() > >> type() - return the type > >> as_dict(), as_string(), as_int() - convert to a subclass so its > >> methods can be used > >> > >> Consider an operation such as printing out the dictionary, you have to > >> know the types of the values. > >> > > > > I was thinking in doing a little bit different. > > > > My next patchset (phase 2) will introduce the QType (or QObject) > > data type, as you have suggested in the QMP thread. This one will > > have all those methods to convert from int, string, dict etc. > > > > Then the dictionary can store it and the user can provide > > a iterator to print the objects. > > > > So, the point here is where to have the high-level data type > > conversion: in the dict itself or in a higher layer (QObject). > > > > I slightly prefer to have them in the QObject, this way the > > dict is more flexible and simpler, capable of storing anything. > > > > But I don't known where the clone() method should be, maybe in > > both? > > > > 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? > 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?