std.experimental.allocator.make should throw on out-of-memory
Era Scarecrow via Digitalmars-d
digitalmars-d at puremagic.com
Wed Apr 20 13:23:53 PDT 2016
On Tuesday, 19 April 2016 at 22:28:27 UTC, Alex Parrill wrote:
> * It fails faster and safer. It's better to error out
> immediately with a descriptive "out of memory" message instead
> of potentially continuing with an invalid pointer and
> potentially causing an invalid memory access, or worse, a
> vulnerability, if the developer forgot to check (which is
> common for boilerplate code).
Guaranteeing that a returned call from requesting memory does
make code simpler. I believe Java does this as well (although the
default memory size wasn't as large as it needed to be :P )
The downside though is the requirement to throw may not be
necessary. Having a failed attempt at getting memory and sleeping
the program for 1-2 seconds before retrying could succeed on a
future attempt. For games this would be a failure to have the
entire game pause and hang until it acquires the memory it needs,
while non critical applications (say compressing data for a
backup) having it be willing to wait wouldn't be a huge
disadvantage (assuming it's not at the start and already been
busy for a while).
This also heavily depends on what type of memory you're
allocating. A stack based allocator (with fixed memory) wouldn't
ever be able to get you more memory than it has fixed in reserve
so immediately throwing makes perfect sense; Although IF the
memory could be arranged and a second attempt made before
deciding to throw could be useful (which assumes not having
direct pointers to the memory in question and rather having an
offset which is used. The more I think about it though the less
likely this would be).
More information about the Digitalmars-d
mailing list