From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:39253) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QlKIe-0001HE-Tk for qemu-devel@nongnu.org; Mon, 25 Jul 2011 08:30:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QlKId-00008K-Nu for qemu-devel@nongnu.org; Mon, 25 Jul 2011 08:30:20 -0400 Received: from mail-yx0-f173.google.com ([209.85.213.173]:33843) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QlKId-00008A-K7 for qemu-devel@nongnu.org; Mon, 25 Jul 2011 08:30:19 -0400 Received: by yxt3 with SMTP id 3so2655483yxt.4 for ; Mon, 25 Jul 2011 05:30:19 -0700 (PDT) Message-ID: <4E2D61D7.40408@codemonkey.ws> Date: Mon, 25 Jul 2011 07:30:15 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1311583872-362-1-git-send-email-avi@redhat.com> <4E2D3CC2.7000206@redhat.com> In-Reply-To: <4E2D3CC2.7000206@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Peter Maydell , Alexander Graf , kvm@vger.kernel.org, qemu-devel@nongnu.org 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