Re: Sv: Sv: Memory allocators

[Christian Reiniger <warewolf@mayn.de>]

Bjarke Hammersholt Roune wrote:

>>(3) Override operator new with a custom one returning 0 on failure
>>
>>I don't like any of these possibilities :(
>>
>Actually, I like throwing an exception better than returning 0, partly
>because its really, really, really a pain to have to check the return value
>of new all the time, partly because running out of memory is pretty fatal to
>the proper functioning of many or even most functions, so you don't want to
>catch the exception anyway. This is what I see as getting both utility and
>functionality "for free".

In theory this is right, but in a function like this one:

int SomeFunc (void)
{
  char *String1 = new [256];
  char *String2 = new [1024];

  // do something

  delete[] String1;
  delete[] String2;
}

(just a silly example. Imagine a function that really needs to allocate the
stuff dynamically).
If the first allocation here fails, everything is fine. But if the second
one fails we have a memory leak.
So you have to check for errors in many cases. The problem is even greater
if the function calls another allocating function instead of the second
allocation - in such a case ommitting the neccessary check is all too easy.

So I check every allocation for failures - and in this case checking for a
zero return value is simpler than catching bad_alloc.

>Nomatter what is decided, getting everything to function uniformly is not
>harder than calling _set_new_handler() with our own handler that does what
>we want it to do.

But then problems arise when the user uses PPlay code together with another
library which also sets its custom _new_handler ().

	Christian
--

Drive A: not responding...Formatting C: instead