This is the mail archive of the mailing list for the GCC 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:
>>Andrew Cagney wrote:
>>Hmmm... What's the advantage of using XZALLOC over XCALLOC?
> It avoids that extra argument (but yes, XZALLOC should be implemented 
> using XCALLOC).

Yes, I've always hated the few C library functions with size/number
of elements pair, as if the caller couldn't do multiplications.
(fread() and fwrite() come to mind.)

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

This violates incapsulation IMHO.  A function alloc_foo()
should always be paired with free_foo(), even when there's
no immediate need for it.  The cost of this abstraction is
zero.  The benefits range from easier debugging to extensibility.

>>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 (Miscellaneous Conventions).
> Fortunatly that addenda _only_ applies to GCC :-)

If so, I may rename these macros for libiberty.  Expecially for
allocation and locking, I tend to like uppercase names because
it makes them more visible in the code.

Making allocations easier to spot in the code is good because
thery're a notorious source of hard to track bugs in large

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

My preference for XNEW() over XMALLOC() isn't at all
strong (I find the first one a little faster to type
and read).

What I really care about is that we use a corresponding
XDELETE() or XFREE() to release that memory.

I also think we need XNEWVEC() (or XMALLOCVEC()) and
their deallocators.  This not only makes it easier to
support C++, it's also useful for debugging.

I don't care too much about the realloc() interface
since it's rarely used, but we can have it for the
sake of completeness.

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

Agreed.  Then we should pick a solution that doesn't
displease too many developers and use that as
consistently as possible.

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

I'd hope we could all agree on a common set of memory
allocation helpers and put them in libiberty for the
benefit of all projects.

The proposed xnew/xdelete interface is clearly a superset
of what GDB has been using.  It's already used by libcpp
and I've got a patch extending its usage all over GCC.

The GDB macros would have to be augmented to be useful
for GCC's long term plans, so we can't just move them
to libiberty.

Couldn't we just agree on a few naming issues and use the
same macros everywhere?   I'd like to hear from the
binutils people too.

  // Bernardo Innocenti - Develer S.r.l., R&D dept.

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