Question about free store memory location and recommendation to user when new fails.

Started by
16 comments, last by grill8 17 years, 1 month ago
Hello all, I have a question about free store memory location and a recommendation to present to the user when operator new fails. I do know how to use the operator new, overload it, customize it etc. but I do not know much about hardware or where the free store memory actually resides. As such I do not know the proper recommendation to present to users when the operator new fails and there are no more fallback mechanisms. I understand the basics of memory structure system memory/virtual memory etc. but do not know the underlying location of the free store memory to be honest with you. I also am needing a short (one sentence or so) message that I should present to end-users of my software if/when new or new[] fails. Some short recommendation such as the following: "ERROR: This application requires more RAM than is available." "TO FIX: Try installing more RAM memory on your computer." Thank you for your help, Your friend, Jeremy (grill8)
Advertisement
I wouldn't worry about giving the user any more than a "Out of memory!". From that message it is pretty obvious what is wrong. Chances are their system isn't meeting your min specs.

Dave
IMHO you can't (usefully) handle the case where 'new' fails. Catching it at presenting an error dialog isn't as easy as it sounds, as you're not really allowed to allocate any more memory (and even a standard windows error dialog will probably allocate somewhere along the line).

Instead what's more likely is that you'll allocate more than is physically available, and your performance will suffer as memory gets swapped in and out. In this case you should probably provide some options for the user to use less memory (which will probably be specific to your app, such as loading in lower quality textures or models).
Quote:Original post by OrangyTang
IMHO you can't (usefully) handle the case where 'new' fails. Catching it at presenting an error dialog isn't as easy as it sounds, as you're not really allowed to allocate any more memory (and even a standard windows error dialog will probably allocate somewhere along the line).


Surely you can catch bad_alloc after all the main resources of the program have been cleaned up and released?
The chances of actually getting a new failure are slim in the first place. The computer will run out of physical memory long before the operating system reports an out of memory condition. At this point, the memory swapping will have probably brought the machine to a halt. Chances are, your application will run unusably slow long before you ever have a new failure.
Unless this has to deal with embedded system, I don't think you need to worry about "new" failing.

Resource allocations, graphics, sound, network and similar, yes. But new shouldn't be an issue.

If you do have low memory issues, then you're probably better off handling memory manually, and attempting to allocate *all* memory at application startup. Then your application will use only these pre-allocated blocks, not worrying about low memory in the first place.

But again, unless you have really large (gigabyte range) memory allocations, or using some old OS, the new itself shouldn't be much of an issue.
Quote:Original post by Deyja
The chances of actually getting a new failure are slim in the first place.
It depends. Severe heap fragmentation plus a large allocation can cause this to happen; it's frequently a problem for server type applications that run a long time. You can get a similar effect by simply trying to allocate a huge block of memory, like 2 GB or something. It will fail, even if your system has enough physical memory to handle it.
SlimDX | Ventspace Blog | Twitter | Diverse teams make better games. I am currently hiring capable C++ engine developers in Baltimore, MD.
Hello all,

Thank you.

So what it sounds like is for a medium sized non-ongoing-server-style program (3D FPS game) that does not allocate more memory than is mission critical you don't actually need to worry about handling new failures / bad_alloc / new_handler / set_new_handler and such?

Perhaps as mentioned provide some sort of mechanism that downgrades the texture sizes/resources/poly count etc. if the frame rate stays low for a relatively long duration (10 seconds or so)?

Thank you for your help.

Jeremy (grill8)
Your application should determine the capabilities of the computer before it gets into runtime, ie during application load time. It would be extremely slow to reload all of your textures at runtime to accomodate for only just realising you don't have enough memory.

Dave
Quote:Original post by Dave
Your application should determine the capabilities of the computer before it gets into runtime, ie during application load time.
Won't help. Out of memory errors deal purely with available virtual memory, which is a fixed quantity and has nothing to do with the computer.
SlimDX | Ventspace Blog | Twitter | Diverse teams make better games. I am currently hiring capable C++ engine developers in Baltimore, MD.

This topic is closed to new replies.

Advertisement