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

[Jes Sorensen <Jes.Sorensen@redhat.com>]

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