Subject: Re: More memory bugs
From: Dom Lachowicz (cinamod@hotmail.com)
Date: Mon Mar 19 2001 - 11:55:36 CST
>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...
free() isn't guaranteed to work with NULL, and I'd rather not try to delete
(or delete[]) anything that is null. If you'd like to give this a try, in
ut_types.h remove the if() stmts from the DELETE macros. So many libraries
work around free(NULL) that it's not even funny (g_free, wvFree, FREEP to
name a few). Whether "delete NULL;" *should* work or not isn't an issue for
me - it just doesn't seem right that you should try to delete NULL.
>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; }"
This is already done by FREEP, DELETEP, DELETPV in ut_types.h.
#define FREEP(p) do {if(p) {free(p); (p) = NULL;} while (0)
It might be worth it to turn these into functions, but that's another
argument altogether.
>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).
Oh, yes, sometimes we will still be forced to free() something that was
allocated by some other external C library. My point is basically just that
we shouldn't use (m|c)alloc() ourselves in C++ code, but new instead.
Dom
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
This archive was generated by hypermail 2b25 : Mon Mar 19 2001 - 11:55:42 CST