From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MW9hq-00043V-SK for qemu-devel@nongnu.org; Wed, 29 Jul 2009 10:00:34 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MW9hm-00040b-4S for qemu-devel@nongnu.org; Wed, 29 Jul 2009 10:00:34 -0400 Received: from [199.232.76.173] (port=57225 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MW9hl-00040W-TH for qemu-devel@nongnu.org; Wed, 29 Jul 2009 10:00:29 -0400 Received: from mx2.redhat.com ([66.187.237.31]:42480) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MW9hl-00060M-BN for qemu-devel@nongnu.org; Wed, 29 Jul 2009 10:00:29 -0400 Message-ID: <4A705716.9040209@redhat.com> Date: Wed, 29 Jul 2009 17:05:10 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 01/25] Introduce QEMU dictionary data type References: <1248818713-11261-1-git-send-email-lcapitulino@redhat.com> <1248818713-11261-2-git-send-email-lcapitulino@redhat.com> <4A701AA3.4060902@redhat.com> <4A704E99.9020107@us.ibm.com> In-Reply-To: <4A704E99.9020107@us.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: jan.kiszka@siemens.com, dlaor@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino On 07/29/2009 04:28 PM, Anthony Liguori 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() > > > It probably would be just as easy to do a ref()/unref() such that the > deep copying was avoided. > Shallow copies have their own pitfalls, you put something in a dict and then modify it later. I keep getting bitten by this in Python. I guess we could live with it though. The important thing is to have proper lifecycle management, which refcounting solves as well. -- error compiling committee.c: too many arguments to function