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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
