Subject: Re: More memory bugs
From: Joaquin Cuenca Abela (cuenca@celium.net)
Date: Mon Mar 19 2001 - 10:23:06 CST
On 19 Mar 2001 09:24:11 -0500, Dom Lachowicz wrote:
> > > Dom:
> > > I have also added DELETEPV(p) which is a vector/array form of
DELETEP.
> > >
> >
> >I feel that the FREE / DELETE macros obscure the code are the
> >principal reason why the bug Mike pointed out went on unnoticed. I
> >would really prefer to do away with them (it is not like they stand
in
> >for a dozen lines of code ...).
>
> I actually couldn't disagree more. I feel that these macros are great.
> What's obscuring our code is that we have 2 dueling memory allocation
> schemes. These macros are only helping us from passing NULL to free,
which
> isn't guaranteed to work, AFAIK.
delete and delete[] are (in theory) guaranteed to work with NULL. Now,
I don't know if all the compilers do the right thing...
And for "free", I don't know if it should work with NULL...
> What we need to do is to standardize on an allocation mechanism and
make
> sure tha people follow it. I propose one of the following:
>
> 1) We use new everywhere
> 2) We use new for complex types and alloc for basic types
>
> I'd prefer #1, but I'd be happy so long as we picked something and
stuck
> with it...
>
> I'm very much opposed to any patch which removes these macros. Macros
that
> only do "if(p) free(p)" don't obscure our code - not having a standard
just a little correction, the macros do something like "if (p) free(p);
p = NULL;"
I suggest to do (at least) "if (p) { free(p); p = NULL; }"
> allocation mechanism (and memory ownership mechanism for that matter)
does
> that to us.
I would go for #1. Anyway sometimes we will be still forced to use free
(for instance, if Gtk+ gives us a pointer and states that we should free
it, we should use g_free and no delete).
Cheers,
-- Joaquín Cuenca Abela cuenca@celium.net
This archive was generated by hypermail 2b25 : Mon Mar 19 2001 - 10:24:59 CST