This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]