[Bf-committers] Some words about a strange thing named
j.merritt at pgrad.unimelb.edu.au
Fri Nov 25 11:05:29 CET 2005
Jorrit Tyberghein wrote:
>> 3. (...)?
>>These things should surely be implemented in a high-level memory
>>manager, not peppered throughout the code in every function that
>>allocates memory. Does anyone disagree?
>Well how would you do that? i.e. imagine code like this:
>char* a = malloc (1000000);
>*a = 1;
>How exactly would you ensure that Blender doesn't crash while trying
>to do *a = 1 if there is not sufficient memory? 'malloc' has no choice
>but to return NULL. So I don't think you can avoid checking for NULL
>unless you use C++ and exceptions but that's probably not an option
Fair point! :-) A: by not using malloc() directly. :-)
Blender's MEM_mallocN() function goes some way toward what I'm
suggesting. What it could do is have an extra flag which means "and try
*REALLY* hard"! If that flag is set, the function should try to exit
the program cleanly if memory allocation doesn't succeed. Otherwise,
it's up to the caller to check the return value.
What I'm getting at is that in many cases, running out of memory is
surely a pathological event (the reason, as you point out, why
out-of-memory is normally an exception in higher-level languages).
Since we can't use exceptions, maybe we can implement part of that type
of functionality in a malloc wrapper instead of dealing with it in detail?
More information about the Bf-committers