[kevin_thibedeau]

You can recover from failed allocations without catastrophic failure. It is a fundamentally lazy programming practice to pretend that error handling has to be an out of band operation that can't be dealt with locally and bubble up progressively.

[Chaosvex]

You can try but realistically, you shouldn't bother in the overwhelming majority of software. Depending on whether you're on a platform that allows for overcommit, you won't necessarily know that an allocation has failed until you attempt to make use of it and the OS tries to back the pages, by which point, you could be far from the source of the allocation.

You're just going to end up with an insane amount of error handling only to discover that in the real world, there's likely nothing you can really do anyway.

[DustinGadal]

On platforms that allow overcommitment, you can guarantee your commit charge is physically backed by writing to each page in a memory pool at allocation time (probably at application startup, or at the end of the main loop), then allocating out of that pool.

Using memory that's been allocated but not committed seems like a recipe for disaster.

[cma]

> Using memory that's been allocated but not committed seems like a recipe for disaster.

It can greatly accelerate sparse datastructures.