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

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

[Bernardo Innocenti]

Hello,

this patch has been discussed here:

  http://gcc.gnu.org/ml/gcc-patches/2004-06/msg02122.html

The idea is to use a familiar C++ idiom for allocation and
destruction of structures.

Hiding both the sizeof expression and the cast from void *
(or char *) inside the macro avoids problems with
mismatching types, allows a shorter syntax.

Moreover, using these macros make client code portable
across all C dialects (K&R C, C89, C99 and C++).


top-level:

2004-06-26  Bernardo Innocenti  <bernie@develer.com>

	* include/libiberty.h (xnew, xcnew, xnewvec, xcnewvec, xobnew): Move
	here from libcpp/internal.h.
	(xcrealloc, xdelete, xdeletevec): New macros.

libcpp:

2004-06-26  Bernardo Innocenti  <bernie@develer.com>

	* internal.h (xnew, xcnew, xnewvec, xcnewvec, xobnew): Move these
	macros to include/libiberty.h.

diff -u -p -u -r1.35 libiberty.h
--- include/libiberty.h	15 May 2003 19:02:12 -0000	1.35
+++ include/libiberty.h	26 Jun 2004 00:27:50 -0000
@@ -250,6 +250,21 @@ extern PTR xmemdup PARAMS ((const PTR, s
 extern double physmem_total PARAMS ((void));
 extern double physmem_available PARAMS ((void));
 
+/* These macros provide a K&R/C89/C++-friendly way of allocating structures
+   with nice encapsulation.  The xdelete*() macros are technically
+   superfluous, but provided here for symmetry.  Using them consistently
+   makes it easier to update client code to use different allocators such
+   as new/delete and new[]/delete[].  */
+
+#define xnew(T)		(T *) xmalloc (sizeof(T))
+#define xcnew(T)	(T *) xcalloc (1, sizeof(T))
+#define xnewvec(T, N)	(T *) xmalloc (sizeof(T) * (N))
+#define xcnewvec(T, N)	(T *) xcalloc (N, sizeof(T))
+#define xcrealloc(P, T) (T *) xrealloc (P, sizeof(T))
+#define xobnew(O, T)	(T *) obstack_alloc (O, sizeof(T))
+#define xdelete(P)	free (P)
+#define xdeletevec(P)	free (P)
+
 /* hex character manipulation routines */
 
 #define _hex_array_size 256



diff -u -p -u -r1.3 internal.h
--- libcpp/internal.h	9 Jun 2004 20:10:13 -0000	1.3
+++ libcpp/internal.h	26 Jun 2004 00:27:50 -0000
@@ -559,11 +559,6 @@ extern const char *_cpp_default_encoding
 
 /* Utility routines and macros.  */
 #define DSC(str) (const uchar *)str, sizeof str - 1
-#define xnew(T)		(T *) xmalloc (sizeof(T))
-#define xcnew(T)	(T *) xcalloc (1, sizeof(T))
-#define xnewvec(T, N)	(T *) xmalloc (sizeof(T) * (N))
-#define xcnewvec(T, N)	(T *) xcalloc (N, sizeof(T))
-#define xobnew(O, T)	(T *) obstack_alloc (O, sizeof(T))
 
 /* These are inline functions instead of macros so we can get type
    checking.  */


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

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

[Bernardo Innocenti]

Bernardo Innocenti wrote:

> +#define xcrealloc(P, T) (T *) xrealloc (P, sizeof(T))

This should have been "xrenew" (unless someone comes up
with a better name for it).

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

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

[Ian Lance Taylor]

Bernardo Innocenti <bernie@develer.com> writes:

> 2004-06-26  Bernardo Innocenti  <bernie@develer.com>
> 
> 	* include/libiberty.h (xnew, xcnew, xnewvec, xcnewvec, xobnew): Move
> 	here from libcpp/internal.h.
> 	(xcrealloc, xdelete, xdeletevec): New macros.
> 
> libcpp:
> 
> 2004-06-26  Bernardo Innocenti  <bernie@develer.com>
> 
> 	* internal.h (xnew, xcnew, xnewvec, xcnewvec, xobnew): Move these
> 	macros to include/libiberty.h.

The libiberty part is fine except for xcrealloc.  That name clearly
shouldn't have a 'c' in it.  Also, it doesn't seem to fit the general
copying of C++ names.  In C++ there isn't realloc to correpond to new
and delete.  Still, I suppose C needs realloc.  But we can't use
xrealloc, because that is taken.  So how about xresize?

Ian

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

[Bernardo Innocenti]

Ian Lance Taylor wrote:
> Bernardo Innocenti <bernie@develer.com> writes:
> 
> 
>>2004-06-26  Bernardo Innocenti  <bernie@develer.com>
>>
>>	* include/libiberty.h (xnew, xcnew, xnewvec, xcnewvec, xobnew): Move
>>	here from libcpp/internal.h.
>>	(xcrealloc, xdelete, xdeletevec): New macros.
>>
>>libcpp:
>>
>>2004-06-26  Bernardo Innocenti  <bernie@develer.com>
>>
>>	* internal.h (xnew, xcnew, xnewvec, xcnewvec, xobnew): Move these
>>	macros to include/libiberty.h.
> 
> 
> The libiberty part is fine except for xcrealloc.  That name clearly
> shouldn't have a 'c' in it.  Also, it doesn't seem to fit the general
> copying of C++ names.  In C++ there isn't realloc to correpond to new
> and delete.  Still, I suppose C needs realloc.  But we can't use
> xrealloc, because that is taken.  So how about xresize?

On second thought, the interface for xrenew() or xresize() wasn't
even usable without a size argument.

Maybe this would be better?

   #define xrenewvec(P, T, N)	(T *) xrealloc ((P), sizeof(T) * (N))

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

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

[Ian Lance Taylor]

Bernardo Innocenti <bernie@develer.com> writes:

> On second thought, the interface for xrenew() or xresize() wasn't
> even usable without a size argument.

Oh yeah.

> Maybe this would be better?
> 
>    #define xrenewvec(P, T, N)	(T *) xrealloc ((P), sizeof(T) * (N))

No, people use realloc with variable size arrays at the end of
structs.  xrenewvec (or xresizevec) is a good idea, but you still need
xrenew (or xresize).

Also I noticed that you should have a space between "sizeof" and "("
in each use of "sizeof".

I prefer xresize, since that was my idea.  Any other ideas?

Ian

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

[Bernardo Innocenti]

Ian Lance Taylor wrote:
> Bernardo Innocenti <bernie@develer.com> writes:
> 
> 
>>On second thought, the interface for xrenew() or xresize() wasn't
>>even usable without a size argument.
> 
> Oh yeah.
> 
> 
>>Maybe this would be better?
>>
>>   #define xrenewvec(P, T, N)	(T *) xrealloc ((P), sizeof(T) * (N))
> 
> 
> No, people use realloc with variable size arrays at the end of
> structs.  xrenewvec (or xresizevec) is a good idea, but you still need
> xrenew (or xresize).
> 
> Also I noticed that you should have a space between "sizeof" and "("
> in each use of "sizeof".

I keep forgetting about it.  Fixed.


> I prefer xresize, since that was my idea.  Any other ideas?

I have no preferences.  For consistency, I've renamed mine
to xresizevec() and moved the type argument in front of the
others.

This is what I'm going to commit:


include/
2004-06-26  Bernardo Innocenti  <bernie@develer.com>

	* include/libiberty.h (xnew, xcnew, xnewvec, xcnewvec, xobnew): Move
	here from libcpp/internal.h.
	(xresize, xresizevec, xdelete, xdeletevec): New macros.

diff -u -p -u -r1.35 libiberty.h
--- include/libiberty.h	15 May 2003 19:02:12 -0000	1.35
+++ include/libiberty.h	26 Jun 2004 00:27:50 -0000
@@ -250,6 +250,21 @@ extern PTR xmemdup PARAMS ((const PTR, s
 extern double physmem_total PARAMS ((void));
 extern double physmem_available PARAMS ((void));
 
+/* These macros provide a K&R/C89/C++-friendly way of allocating structures
+   with nice encapsulation.  The xdelete*() macros are technically
+   superfluous, but provided here for symmetry.  Using them consistently
+   makes it easier to update client code to use different allocators such
+   as new/delete and new[]/delete[].  */
+
+#define xnew(T)			(T *) xmalloc (sizeof (T))
+#define xcnew(T)		(T *) xcalloc (1, sizeof (T))
+#define xnewvec(T, N)		(T *) xmalloc (sizeof (T) * (N))
+#define xcnewvec(T, N)		(T *) xcalloc (N, sizeof (T))
+#define xresize(T, P, S)	(T *) xrealloc (P, S)
+#define xresizevec(T, P, N)	(T *) xrealloc (P, sizeof (T) * (N))
+#define xobnew(O, T)		(T *) obstack_alloc (O, sizeof (T))
+#define xdelete(P)		free (P)
+#define xdeletevec(P)		free (P)
+
 /* hex character manipulation routines */
 
 #define _hex_array_size 256


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

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

[Daniel Jacobowitz]

On Sat, Jun 26, 2004 at 04:39:04AM +0200, Bernardo Innocenti wrote:
> Ian Lance Taylor wrote:
> > Bernardo Innocenti <bernie@develer.com> writes:
> > 
> > 
> >>On second thought, the interface for xrenew() or xresize() wasn't
> >>even usable without a size argument.
> > 
> > Oh yeah.
> > 
> > 
> >>Maybe this would be better?
> >>
> >>   #define xrenewvec(P, T, N)	(T *) xrealloc ((P), sizeof(T) * (N))
> > 
> > 
> > No, people use realloc with variable size arrays at the end of
> > structs.  xrenewvec (or xresizevec) is a good idea, but you still need
> > xrenew (or xresize).

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.

-- 
Daniel Jacobowitz

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

[Bernardo Innocenti]

Daniel Jacobowitz wrote:
> On Sat, Jun 26, 2004 at 04:39:04AM +0200, Bernardo Innocenti wrote:
> 
>>Ian Lance Taylor wrote:
>>
>>>Bernardo Innocenti <bernie@develer.com> writes:
>>>
>>>
>>>
>>>>On second thought, the interface for xrenew() or xresize() wasn't
>>>>even usable without a size argument.
>>>
>>>Oh yeah.
>>>
>>>
>>>
>>>>Maybe this would be better?
>>>>
>>>>  #define xrenewvec(P, T, N)	(T *) xrealloc ((P), sizeof(T) * (N))
>>>
>>>
>>>No, people use realloc with variable size arrays at the end of
>>>structs.  xrenewvec (or xresizevec) is a good idea, but you still need
>>>xrenew (or xresize).
> 
> 
> 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've not yet committed anything, but I see your point.

There's good symmetry here:

  struct foo *v = xnewvec (struct foo, 42);
  v = xresizevec (struct foo, v, 666);
  xdeletevec (v);

But not here:

  struct varsize *s = ???
  s = xresize (struct varsize, s, sizeof (struct varsize) + strlen (name));
  xdelete (s);


Maybe we should add this:

  #define xvarnew(T, S)   (T *) xmalloc (S)


Another possibility would be dropping this realloc interface
altogether and sticking with a simpler interface that has
the same limitations of C++.

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

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

[Alexandre Oliva]

On Jun 25, 2004, Bernardo Innocenti <bernie@develer.com> wrote:

> +#define xcnewvec(T, N)		(T *) xcalloc (N, sizeof (T))
> +#define xresize(T, P, S)	(T *) xrealloc (P, S)
> +#define xresizevec(T, P, N)	(T *) xrealloc (P, sizeof (T) * (N))
> +#define xobnew(O, T)		(T *) obstack_alloc (O, sizeof (T))

You're missing parentheses around N, P (twice), S and O.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

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

[Bernardo Innocenti]

Alexandre Oliva wrote:
> On Jun 25, 2004, Bernardo Innocenti <bernie@develer.com> wrote:
> 
> 
>>+#define xcnewvec(T, N)		(T *) xcalloc (N, sizeof (T))
>>+#define xresize(T, P, S)	(T *) xrealloc (P, S)
>>+#define xresizevec(T, P, N)	(T *) xrealloc (P, sizeof (T) * (N))
>>+#define xobnew(O, T)		(T *) obstack_alloc (O, sizeof (T))
> 
> 
> You're missing parentheses around N, P (twice), S and O.

I had used them the first time, but then removed them because
I thought there would be no way to pass an argument containing
a comma through the C89 preprocessor.

Actually, there's:

  #define foo ,
  xresize(struct foo, f, 10);

...but how could one possibly abuse this to generate code
that actually compiles?

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

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

[Zack Weinberg]

Alexandre Oliva <aoliva@redhat.com> writes:

>> +#define xcnewvec(T, N)		(T *) xcalloc (N, sizeof (T))
>> +#define xresize(T, P, S)	(T *) xrealloc (P, S)
>> +#define xresizevec(T, P, N)	(T *) xrealloc (P, sizeof (T) * (N))
>> +#define xobnew(O, T)		(T *) obstack_alloc (O, sizeof (T))
>
> You're missing parentheses around N, P (twice), S and O.

They're not actually necessary in this context.

zw

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

[Falk Hueffner]

Zack Weinberg <zack@codesourcery.com> writes:

> Alexandre Oliva <aoliva@redhat.com> writes:
>
>>> +#define xcnewvec(T, N)		(T *) xcalloc (N, sizeof (T))
>>> +#define xresize(T, P, S)	(T *) xrealloc (P, S)
>>> +#define xresizevec(T, P, N)	(T *) xrealloc (P, sizeof (T) * (N))
>>> +#define xobnew(O, T)		(T *) obstack_alloc (O, sizeof (T))
>>
>> You're missing parentheses around N, P (twice), S and O.
>
> They're not actually necessary in this context.

How about parentheses around the whole cast? Somebody might want to
write

&xnew(T)->el

Not very likely, but IMHO it's not really worth the trouble to try to
think of every possible or sensible use instead of just adding a bunch
of parentheses.

-- 
	Falk

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

[Bernardo Innocenti]

Falk Hueffner wrote:
> Zack Weinberg <zack@codesourcery.com> writes:
> 
> 
>>Alexandre Oliva <aoliva@redhat.com> writes:
>>
>>
>>>>+#define xcnewvec(T, N)		(T *) xcalloc (N, sizeof (T))
>>>>+#define xresize(T, P, S)	(T *) xrealloc (P, S)
>>>>+#define xresizevec(T, P, N)	(T *) xrealloc (P, sizeof (T) * (N))
>>>>+#define xobnew(O, T)		(T *) obstack_alloc (O, sizeof (T))
>>>
>>>You're missing parentheses around N, P (twice), S and O.
>>
>>They're not actually necessary in this context.
> 
> 
> How about parentheses around the whole cast? Somebody might want to
> write
> 
> &xnew(T)->el
> 
> Not very likely, but IMHO it's not really worth the trouble to try to
> think of every possible or sensible use instead of just adding a bunch
> of parentheses.

Agreed.  This is the full patch again updated with your suggestions
and a proposed fix for the realloc() interface.


include/
2004-06-26  Bernardo Innocenti  <bernie@develer.com>

	* include/libiberty.h (xnew, xcnew, xnewvec, xcnewvec, xobnew): Move
	here from libcpp/internal.h.
	(xdelete, xresizevec, xdeletevec, xnewvar, xcnewvar, xresizevar): New
	macros.

diff -u -p -r1.35 libiberty.h
--- include/libiberty.h	15 May 2003 19:02:12 -0000	1.35
+++ include/libiberty.h	26 Jun 2004 16:35:34 -0000
@@ -250,6 +250,37 @@ extern PTR xmemdup PARAMS ((const PTR, s
 extern double physmem_total PARAMS ((void));
 extern double physmem_available PARAMS ((void));
 
+
+/* These macros provide a K&R/C89/C++-friendly way of allocating structures
+   with nice encapsulation.  The xdelete*() macros are technically
+   superfluous, but provided here for symmetry.  Using them consistently
+   makes it easier to update client code to use different allocators such
+   as new/delete and new[]/delete[].  */
+
+/* Scalar allocators.  */
+
+#define xnew(T)			((T *) xmalloc (sizeof (T)))
+#define xcnew(T)		((T *) xcalloc (1, sizeof (T)))
+#define xdelete(P)		free (P)
+
+/* Array allocators.  */
+
+#define xnewvec(T, N)		((T *) xmalloc (sizeof (T) * (N)))
+#define xcnewvec(T, N)		((T *) xcalloc (N, sizeof (T)))
+#define xresizevec(T, P, N)	((T *) xrealloc (P, sizeof (T) * (N)))
+#define xdeletevec(P)		free (P)
+
+/* Allocators for variable-sized structures and raw buffers.  */
+
+#define xnewvar(T, S)		((T *) xmalloc (S))
+#define xcnewvar(T, S)		((T *) xcalloc (1, S))
+#define xresizevar(T, P, S)	((T *) xrealloc (P, S))
+
+/* Type-safe obstack allocator.  */
+
+#define xobnew(O, T)		((T *) obstack_alloc (O, sizeof (T)))
+
+
 /* hex character manipulation routines */
 
 #define _hex_array_size 256

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

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

[Andrew Cagney]

>>>> > No, people use realloc with variable size arrays at the end of
>>>> > structs.  xrenewvec (or xresizevec) is a good idea, but you still need
>>>> > xrenew (or xresize).
> 
> 
> 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)))

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
- are named in a way that directly reflects their C herritage

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

Andrew

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

[Daniel Jacobowitz]

On Sat, Jun 26, 2004 at 01:21:59PM -0400, Andrew Cagney wrote:
> 
> >>>>> No, people use realloc with variable size arrays at the end of
> >>>>> structs.  xrenewvec (or xresizevec) is a good idea, but you still need
> >>>>> xrenew (or xresize).
> >
> >
> >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:

No, not at all.

> 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
> - are named in a way that directly reflects their C herritage
> 
> 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++.

You might want to read the discussion on gcc@ and gcc-patches@ that
prompted the use of C++ style names...

-- 
Daniel Jacobowitz

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

[Andrew Cagney]

> You might want to read the discussion on gcc@ and gcc-patches@

I did, Bernardo provided a helpful cross reference.

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

[Alexandre Oliva]

On Jun 26, 2004, Bernardo Innocenti <bernie@develer.com> wrote:

>   #define foo ,
>   xresize(struct foo, f, 10);

> ...but how could one possibly abuse this to generate code
> that actually compiles?

If it's C++, one could overload xrealloc.  I tend to prefer to enclose
all macro arguments in parentheses, even when not strictly necessary,
than to risk missing one case.

And, as Falk pointed out, the full expansion of the macro should be
enclosed in parentheses as well.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

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

[Bernardo Innocenti]

Alexandre Oliva wrote:
> On Jun 26, 2004, Bernardo Innocenti <bernie@develer.com> wrote:
> 
>>  #define foo ,
>>  xresize(struct foo, f, 10);
> 
>>...but how could one possibly abuse this to generate code
>>that actually compiles?
> 
> If it's C++, one could overload xrealloc.  I tend to prefer to enclose
> all macro arguments in parentheses, even when not strictly necessary,
> than to risk missing one case.

OK, better safe than sorry, I guess.


> And, as Falk pointed out, the full expansion of the macro should be
> enclosed in parentheses as well.

Done already.


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

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

[Bernardo Innocenti]

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/

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

[Andrew Cagney]

> 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

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

[Bernardo Innocenti]

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 http://gcc.gnu.org/codingconventions.html (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
applications.


>>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.
\X/  http://www.develer.com/

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

[Joseph S. Myers]

On Mon, 28 Jun 2004, Bernardo Innocenti wrote:

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

While I generally agree with this view of such functions (fread and fwrite
are worse than calloc, as if the item size isn't 1 you cannot use them
reliably in the presence of possible interrupts by signals), they do at
least if properly implemented check for integer overflow in the
multiplication.  See glibc's calloc for how to avoid a division in most
cases in this check, and gnulib's xalloc.h for optimizing the case where
the element size is a constant.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)

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

[Bernardo Innocenti]

Bernardo Innocenti wrote:

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

I'm leaving for vacation and I'll be (mostly) away from the
keyboard for one week.

This is the libiberty patch again updated with the latest
suggestions.

The X*VAR() macros try to provide a full interface to
allocat structures of variable lenght.  They're not
used anywhere at the moment, so I could drop them in
case the interface doesn't seem useful enough.

Andrew Cagney suggested using a different naming scheme
(XMALLOC, XCALLOC...) that has the advantage of being more
familiar to C programmers and has been used in GDB for a
few years.  I still prefer XNEW/XDELETE, but I'm open to
changes if someone suggests names for the full set,
including the deallocators.


include/
2004-06-26  Bernardo Innocenti  <bernie@develer.com>

	* include/libiberty.h (xnew, xcnew, xnewvec, xcnewvec, xobnew): Move
	here from libcpp/internal.h.
	(xdelete, xresizevec, xdeletevec, xnewvar, xcnewvar, xresizevar): New
	macros.

diff -u -p -r1.35 libiberty.h
--- include/libiberty.h	15 May 2003 19:02:12 -0000	1.35
+++ include/libiberty.h	26 Jun 2004 16:35:34 -0000
@@ -250,6 +250,37 @@ extern PTR xmemdup PARAMS ((const PTR, s
 extern double physmem_total PARAMS ((void));
 extern double physmem_available PARAMS ((void));
 
+
+/* These macros provide a K&R/C89/C++-friendly way of allocating structures
+   with nice encapsulation.  The XDELETE*() macros are technically
+   superfluous, but provided here for symmetry.  Using them consistently
+   makes it easier to update client code to use different allocators such
+   as new/delete and new[]/delete[].  */
+
+/* Scalar allocators.  */
+
+#define XNEW(T)			((T *) xmalloc (sizeof (T)))
+#define XCNEW(T)		((T *) xcalloc (1, sizeof (T)))
+#define XDELETE(P)		free ((P))
+
+/* Array allocators.  */
+
+#define XNEWVEC(T, N)		((T *) xmalloc (sizeof (T) * (N)))
+#define XCNEWVEC(T, N)		((T *) xcalloc ((N), sizeof (T)))
+#define XRESIZEVEC(T, P, N)	((T *) xrealloc ((P), sizeof (T) * (N)))
+#define XDELETEVEC(P)		free ((P))
+
+/* Allocators for variable-sized structures and raw buffers.  */
+
+#define XNEWVAR(T, S)		((T *) xmalloc ((S)))
+#define XCNEWVAR(T, S)		((T *) xcalloc (1, (S)))
+#define XRESIZEVAR(T, P, S)	((T *) xrealloc ((P), (S)))
+
+/* Type-safe obstack allocator.  */
+
+#define XOBNEW(O, T)		((T *) obstack_alloc ((O), sizeof (T)))
+
+
 /* hex character manipulation routines */
 
 #define _hex_array_size 256



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