From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW() Date: Mon, 25 Jul 2011 07:30:15 -0500 Message-ID: <4E2D61D7.40408@codemonkey.ws> References: <1311583872-362-1-git-send-email-avi@redhat.com> <4E2D3CC2.7000206@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Peter Maydell , Alexander Graf , kvm@vger.kernel.org, qemu-devel@nongnu.org To: Avi Kivity Return-path: Received: from mail-yx0-f174.google.com ([209.85.213.174]:52943 "EHLO mail-yx0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750864Ab1GYMaT (ORCPT ); Mon, 25 Jul 2011 08:30:19 -0400 Received: by yxi11 with SMTP id 11so2177163yxi.19 for ; Mon, 25 Jul 2011 05:30:19 -0700 (PDT) In-Reply-To: <4E2D3CC2.7000206@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 07/25/2011 04:52 AM, Avi Kivity wrote: > On 07/25/2011 12:48 PM, Peter Maydell wrote: >> On 25 July 2011 10:32, Alexander Graf wrote: >> > On 25.07.2011, at 10:51, Avi Kivity wrote: >> >> qemu_malloc() is type-unsafe as it returns a void pointer. Introduce >> >> QEMU_NEW() (and QEMU_NEWZ()), which return the correct type. >> > >> > What does this buy you over >> > >> > type *x = qemu_malloc(sizeof(type)); >> > >> > ? I find the non-C++ version easier to read even. >> >> Yeah, while we're writing in C we should just stick to the C-like >> APIs, it's less confusing IMHO than wrapping it up in something else. > > That argument can be used to block any change. You'll get used to it in > time. The question is, is the new interface better or not. > >> I assume Anthony's new object model stuff will have a "create me a >> new foo object" API anyway, so QEMU_NEW() is possibly a bit of a >> namespace grab. > > Anthony's stuff is at a much higher level, hopefully he'll come back to > the ground one day. The point of introducing glib was to address things like this. We need to start making heavier use of what it provides. Regards, Anthony Liguori