Re: [top-level] C++-friendly allocators for libiberty

[Bernardo Innocenti <bernie@develer.com>]

Andrew Cagney wrote:

>>Bernando, you've now got an interface which allows reallocating to a
>>variable size, but not allocating to one...  There's no need for a
>>rush, let's give people some time to comment before putting this into
>>libiberty.  As DJ says, it's hard to take things out of libiberty.
> 
> I guess daniel had this in mind:
> 
>>/* Utility macros to allocate typed memory.  Avoids errors like:
>>   struct foo *foo = xmalloc (sizeof struct bar); and memset (foo,
>>   sizeof (struct foo), 0).  */
>>#define XZALLOC(TYPE) ((TYPE*) memset (xmalloc (sizeof (TYPE)), 0, sizeof (TYPE)
>>))
>>#define XMALLOC(TYPE) ((TYPE*) xmalloc (sizeof (TYPE)))
>>#define XCALLOC(NMEMB, TYPE) ((TYPE*) xcalloc ((NMEMB), sizeof (TYPE)))

Hmmm... What's the advantage of using XZALLOC over XCALLOC?

These macros don't address vector allocations and aren't paired
with corresponding macros to release memory.

When it comes to resource management of any kind, I tend to
prefer function pairs such as open/close, lock/unlock, new/delete,
alloc/free, and so on.

It makes it easier to check the code for correctness and to instrument
the allocators for debugging purposes.


> They first appeared in GDB in '99 and were added to GDB's global header 
> file in '02 (and I'm sure the idea was stolen from elsewhere).  Unlike 
> the macros being proposed, these:
> 
> - use uppercase to make it very very clear that they are macros

This contraddicts the GCC addenda to the GNU coding conventions: macros
meant to be used like C functions should be named like C functions.
See http://gcc.gnu.org/codingconventions.html (Miscellaneous Conventions).


> - are named in a way that directly reflects their C herritage

What we're trying to do is getting away from the (dangerous) C
practice of allocating structures by casting around void pointers
to raw memory blocks.

The libcpp macros for type-safe memory allocation resemble C++-style
memory allocation, hence the new/delete names.

(Actually, C++'s new and delete would also perform construction
and destruction, which we can't possibly do in C).


> While I agree with the type casing idea underlying "xnew" et.al. (I was 
> in part responsible for the above :-), I don't see any benefit in 
> adopting C++ names and pretending that we're writing C++.

A better solution would be using inline functions to allocate *and*
initialize common data structures.  This would make our code both
smaller and safer.  I bet there are tons of places in GCC where
structure fields are not being initialized properly because of
manual construction.

 static inline struct options *
 new_options (struct options *next, const char *name, void *info)
 {
   struct options *o = xnew (struct options);
   o->next = next;
   o->name = name;
   o->info = info;
 }

 static inline void
 delete_options (struct options *o)
 {
   xdelete (o);
 }

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/