|
new only fails after it runs out of virtual memory.
|
|
|
|
|
"Doing out of memory checking is fairly pointless for desktop apps, because of virtual memory."
Well, well. There are no 2 systems which are the same. One can't expect an unlimited amount of memory, or an unlimited amount of virtual memory. And there are - many - types of apps where memory availability is a real issue, at least from where I'm standing (image and video processing, large scale, large resolution, large databases, and so on). My rule is always to expect the worst.
|
|
|
|
|
Yeah, now that I think about it I'd say it's worth doing, considering it's only 4 extra lines of code. Having said that those large scale apps you're talking about are pretty rare. You're average run of the mill app will never run out of memory.
|
|
|
|
|
I am programing the 3D graphics applications which operate with large amount of data. So memory limit can be hit pretty fast. 
|
|
|
|
|
Computer graphics always hunger for more and faster processors and yet more memory. There is always a higher resolution, a greater color depth, a need for a larger 3D buffer for a more detailed object and a good use for more and more 3D objects. This will never change.
A while ago he asked me what he should have printed on my business cards. I said 'Wizard'.
I read books which nobody else understand. Then I do something which nobody understands. After that the computer does something which nobody understands. When asked, I say things about the results which nobody understand. But everybody expects miracles from me on a regular basis. Looks to me like the classical definition of a wizard.
|
|
|
|
|
he he, neat 
|
|
|
|
|
The consequences are not the same if you program a game or an securty system as a ABS or ESP !
|
|
|
|
|
No, actually it does not. A crashing game may not be a matter of life and death, but an angry gamer also is a dissatisfied customer.
A user interface should always show exactly, what the user's options are at this moment. Also, it should tell the user why an option is not available at the moment. I simply don't let the user do memory intensive stuff and simply wait for the exception to happen. Predicting trouble and telling the user what he can do about it leaves an entirely different impression.
Then there are sequences of operations which may become very complicated to undo if any serious error occurs somewhere in the middle. Checking the most probable causes of errors in advance, including memory limitations, may help by not letting the error occur in the first place.
A while ago he asked me what he should have printed on my business cards. I said 'Wizard'.
I read books which nobody else understand. Then I do something which nobody understands. After that the computer does something which nobody understands. When asked, I say things about the results which nobody understand. But everybody expects miracles from me on a regular basis. Looks to me like the classical definition of a wizard.
|
|
|
|
|
...64K. If the OS can't spare 64K, then my program will be the least of your worries.
- S
50 cups of coffee and you know it's on!
A post a day, keeps the white coats away!
|
|
|
|
|
Commodore 64 lives...! 
|
|
|
|
|
Who needs more than 16 bits worth of address space anyway?
--
Kein Mitleid Für Die Mehrheit
|
|
|
|
|
It seems to me, having a program crash because the system ran out of memory is the most ridiculous thing ever. If there isn't enough memory available to create a new object, the OS shouldn't crash the program--it should simply pause it and give an out of memory warning to the user so they can free some up and then the program would unfreeze when enough is available to continue safely. Yeah there are a few scenarios this would still have problems with (like remoting) but for the most part it would be a lot nicer.
In such a managed world, having your program throw a random exception when there is no more memory is just strange. I remember the first time I got that exception--I was like "are you kidding??".
“Time and space can be a bitch.”
–Gushie, Quantum Leap
{o,o}.oO( Looking for a great RSS reader? Try FeedBeast! )
|)””’) Built with home-grown CodeProject components!
-”-”-
|
|
|
|
|
|
Cristian Amarie wrote: You're kidding, right?
What if you were working on something important and didn't have it saved when you run out of memory? Which do you think is the better situation?
“Time and space can be a bitch.”
–Gushie, Quantum Leap
{o,o}.oO( Looking for a great RSS reader? Try FeedBeast! )
|)””’) Built with home-grown CodeProject components!
-”-”-
|
|
|
|
|
|
Cristian Amarie wrote: I wouldn't drive a car that stops itself in the middle of highway just because the gas is running low.
My 0.2.
Would you prefer it just blew up when it reached 0?
“Time and space can be a bitch.”
–Gushie, Quantum Leap
{o,o}.oO( Looking for a great RSS reader? Try FeedBeast! )
|)””’) Built with home-grown CodeProject components!
-”-”-
|
|
|
|
|
No, that's why we prefer BOSD that tries to prevent disaster when critical error occurs. If system crash cause losing of my _unsaved_ work its my own fault for not saving the documents, but if it trashes my _saved_ files, huh, now that is bad, very bad...
|
|
|
|
|
Mladen Jankovic wrote: If system crash cause losing of my _unsaved_ work its my own fault for not saving the documents
Ur living in the past man!
“Time and space can be a bitch.”
–Gushie, Quantum Leap
{o,o}.oO( Check out my blog! )
|)””’) piHole.org
-”-”-
|
|
|
|
|
Cristian Amarie wrote: My 0.2.
You know 0.2 dollars is actually 20 cents, right?
|
|
|
|
|
Maybe it was only worth a fifth of a cent. 
“Time and space can be a bitch.”
–Gushie, Quantum Leap
{o,o}.oO( Check out my blog! )
|)””’) piHole.org
-”-”-
|
|
|
|
|
The OS can facilitate the application in the background transparently by paging and other means. However, if the application behaves truant and gobbles up all the memory greedily, then it has to pull in the whip and give it a kick.
Vasudevan Deepak Kumar
Personal Homepage
Tech Gossips
All the world's a stage,
And all the men and women merely players.
They have their exits and their entrances;
And one man in his time plays many parts... --William Shakespeare
|
|
|
|
|
Exactly, but what I'm saying is that "kick" should basically pause the app and notify the user, giving them the option of killing it or allowing it to have more ram.
Just cause the app is poorly written doesn't meant there's not important information stored within it. I'm of the opinion the OS should never intentionally do anything that would lose a user's information when an alternative is available. Of course you could argue how "intentional" it is, since the system does give the app an out of memory exception. The problem is at that point the program is so unstable anyway (and that's IF the exception was handled) that it may as well be killing it.
Logan
“Time and space can be a bitch.”
–Gushie, Quantum Leap
{o,o}.oO( Check out my blog! )
|)””’) piHole.org
-”-”-
|
|
|
|
|
|
Cristian Amarie wrote: - declare your application at setup as "interactive" or "OS-interruptible" (sic!)) and "OS should handle extreme memory (rain, calamity, Somalian wars etc. - each with the appropriate flags, of course) conditions"
- then define what's a threshold for your application (a some kind of Darboux property as [minRAM, maxRAM])
- then define callbacks to be published and executed (NULL - OS handler, non-NULL, user handler)
You're using this as an argument that this shouldn't be handled by the OS?
Cristian Amarie wrote: Do you really trust your data to be handled by a POORLY WRITTEN APPLICATION?
No, I trust that the OS will not be responsible for losing it on me.
P.S.
"Interruptible" is correct[^]
“Time and space can be a bitch.”
–Gushie, Quantum Leap
{o,o}.oO( Check out my blog! )
|)””’) piHole.org
-”-”-
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
