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

[Andrew Cagney <cagney@gnu.org>]

> 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?

It avoids that extra argument (but yes, XZALLOC should be implemented 
using XCALLOC).

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

So far no need.  Since its C everyone already knows to call free().

>>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).

Fortunatly that addenda _only_ applies to GCC :-)

>>> - 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.

Right, and the above achieved that goal, and using a naming convention 
that is very familar to the C programmer.

The bottom line is that there's no "right" answer here.

> 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).

So lets (as in GDB, GCC and BINUTILS) stop beating about the bush and 
accept C++ (and yes I hate C++).

Lets add these to a GCC(?) specific include/ header.  That way projects 
that want those macros can.

Andrew