qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()


From: Jes Sorensen
Subject: Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()
Date: Mon, 25 Jul 2011 17:17:24 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc14 Thunderbird/3.1.11

On 07/25/11 17:15, Anthony Liguori wrote:
> On 07/25/2011 10:10 AM, Jes Sorensen wrote:
>> On 07/25/11 12:06, Stefan Hajnoczi wrote:
>>>> +#define QEMU_NEW(type) ((type *)(qemu_malloc(sizeof(type))))
>>>>> +#define QEMU_NEWZ(type) ((type *)(qemu_mallocz(sizeof(type))))
>>> Does this mean we need to duplicate the type name for each allocation?
>>>
>>> struct foo *f;
>>>
>>> ...
>>> f = qemu_malloc(sizeof(*f));
>>>
>>> Becomes:
>>>
>>> struct foo *f;
>>>
>>> ...
>>> f = QEMU_NEW(struct foo);
>>>
>>> If you ever change the name of the type you have to search-replace
>>> these instances.  The idomatic C way works well, I don't see a reason
>>> to use QEMU_NEW().
>>
>> You're right, and it will promote even more abuse of the ugly typedefs.
>> This really makes the code less readable, especially for outsiders :(
> 
> I don't think it really matters either way.  If some people prefer to
> use g_new(struct foo, 1) vs. g_malloc(sizeof(*f)), I don't think it
> significantly impacts overall code readability.
> 
> But having nice, documentation for key internal APIs does which is why
> using the glib interfaces makes sense IMHO.

Using the commands consistently does have an impact, and at least with
qemu_malloc() it is obvious what they are and how they behave. The
proposed macros on the other hand requires everybody to go look up the
macro to find out what it is trying to do.

Jes



reply via email to

[Prev in Thread] Current Thread [Next in Thread]