|
"It makes my code ugly."
Only if you do it wrong. Production code should not look like code samples from the internet. Code that doesn't check for errors is uglier!
"Everybody has enough memory."
There is no way to know this unless you have complete control over everything, including the hardware and O/S.
"The program is kaput anyway."
Depends on the program, but even so, you should TELL THE USER WHAT HAPPENED instead of merrily going along until you crash or write bad data to a database or corrupt open files. For services and background applications, log an error (to an already-open log file -- avoids allocation on open).
These things will make YOUR job easier when they call.
|
|
|
|
|
In mobile applications, we are testing for out of memory conditions. But for web applications and desktop applications, we are not doing this type of testing.
|
|
|
|
|
 
Usually while programming we don't check memory overflow
|
|
|
|
|
For those of us who cut our teeth on 8 bit systems, the habit is so firmly ingrained that it can't really be broken.
I can certainly think of worse habits. 
|
|
|
|
|
I guess you are right about that, not testing for these types of condition goes against the grain. If a program I wrote could just crash without shutting down cleanly, I would feel like I failed to do may job.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
|
|
|
|
|
I cut my teeth on 8 bit systems and I think it's a bad habit to waste time on something so unlikely in this day and age, particularly if working with a managed runtime like .net.
"It's so simple to be wise. Just think of something stupid to say and then don't say it."
-Sam Levenson
|
|
|
|
|
Heh. You obviously aren't cursed with having to maintain legacy PalmOS code 
|
|
|
|
|
There's exceptions to everything, kind of a goes without saying deal.
"It's so simple to be wise. Just think of something stupid to say and then don't say it."
-Sam Levenson
|
|
|
|
|
I only check in debug mode for my C/C++ applications.
I guess I would always check for big allocations, but I never had to deal with those.
|
|
|
|
|
In Debug mode?
My experience has been that just because something works on my machine (i.e., a developer setup) does not mean it will work on that of a typical user. My previous employers at first were angry about stuff I wrote not working the same - but they saw it for themselves a few times and knew that they needed to use it on a 'real' machine (i.e., one that's just like their customers have - which they built and sold). (NO, I didn't have one of my own - they were a bit cheap in that reguard)
Sure - if it craps out in Debug mode, then it's going to need some fixing, but not doing so (when it's important to know) is a shakey position. Your system is very unrepresentative of the target systems.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"How do you find out if you're unwanted if everyone you try to ask tells you to go away?" - Balboos HaGadol
|
|
|
|
|
Oh hell yeah! I once wanted to showcase a project that we didn't got a chance to test much, it worked on our systems (which we of course run in debug mode all the time), but when I tried to start it on the interviewer's machine... crash! (although it worked just fine in release mode on my home PC; at least the 2nd program worked...)
Then again, I mostly write for my own needs, because so much of the software out there, even the good stuff like Winamp, is retarded. When my program crashes, which is exceptionally rare, I know why. I guess in an out-of-memory situation, I could only inform the user, log it, and close the program, but even doing that would be hard knowing I can no longer allocate memory. (ie: does MessageBox allocate from the heap? would have to test...)
But I guess you can never be sure. I've read in Symbian's documentation (another retarded piece of software, that Symbian) that you should not use the default stack size of 8KB or whatever it is, because even if your program works today, the functions you call could use more stack space in a next OS update, and run your program into a stack overflow!
|
|
|
|
|
Mobile/hand held computers suck at out-of-memory detection and notification. It is therefore mandatory to perform graceful detection and reporting BEFORE the O.S. has a chance to screw things up.
Gary
|
|
|
|
|
I think that it's very importat check the increase of the used memory during the running of
an application that never stops its main loop (like control process applications).
|
|
|
|
|
Regardless how much memory a particular application you may be writing consumes, said application must be able to "operate under low memory conditions", since you are not likely to be able to know what other applications will be running concurrently.
By "operate under low memory conditions" I mean:
1. The application doesn't crash.
2. If the application cannot perform user tasks because it cannot allocate memory, it must at least be able to inform the user that they may have to close down other applications in order to continue. Remember that simply trying to dynamically display a dialog may also fail because of the low-memory situation.
3. It must be able to exit cleanly and save any unsaved work.
|
|
|
|
|
Adrian Cole wrote: you are not likely to be able to know what other applications will be running concurrently.
What a relief. Finally a comment that makes sense.
But I fear that it may be disguised in the noise by other I-don't-use-that-much-memory illusions people seem to have thinking their application is the only one running.
Thank you Adrian and keep up the good work!
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Am I the only one stunned at the "why bother" responses?
For memory intensive things such as numerical modelling, image processing, data feeds or whatever there are many, many times when there simply isn't enough memory to do what has been asked and to have an application simply keel over and die is absolutely unacceptable.
Has software developement really sunk to these depths? Is this what a managed runtime has done to us.
Garrrr! When I was a lad...
cheers,
Chris Maunder
CodeProject.com : C++ MVP
|
|
|
|
|
It's not that the managed runtime has made most of us dumb. I think there are a lot of people out there that work on applications that don't have that requirement. So why bother?
I'm currently working on an application that has that requirement and I test for conditions where I explicitly mess up the C++ code to generate out-of-memory exceptions.
Times have changed with the managed runtime, but not that much 
|
|
|
|
|
I'm stunned as well...
Even in manage world, I think it's worthwhile to call GC.Collect() from time to time. This is very true if you do a lot of COM interop calls.
In the end, we will remember not the words of our enemies, but the silence of our friends. - Martin Luther King Jr.
Ernest Laurentin
|
|
|
|
|
Actually using GC.Collect is generally a bad practice in .NET
This article explains why: http://blogs.msdn.com/ricom/archive/2003/12/02/40780.aspx
|
|
|
|
|
Like I said...If you do a lot of COM interop, you will find resources not being reclaimed in timely manner.
In the end, we will remember not the words of our enemies, but the silence of our friends. - Martin Luther King Jr.
Ernest Laurentin
|
|
|
|
|
What exactly would you do in a situation where you just ran out of memory? Doing pretty much anything at all is going to require allocating memory. Memory that is probably unavailable. In C++, if you do anything, you could override the default 'new' allocator and display a message box or something and then bail. But if you just ran the system out of memory, there isn't a whole lot of chance that the message box is even going to appear in the first place. An unhandled exception from a RAM allocation failure, on the other hand, that gets to the top and terminates the application allows the application to be debugged later by leveraging WER. This allows the author to focus on getting code written and not writing a zillion different little "what-if" lines of code. Additionally, a lot of authors simply assume low memory scenarios will get handed off to swap, which generally works - sluggishly, but it works. Granted, this perhaps isn't the way to handle low memory scenarios, but I can't remember the last time Windows said, "This program crashed because it couldn't allocate the necessary memory." Nor have I ever seen Windows offer to tell the user that if they kill programs X, Y, and Z off, the program they are running will have more memory and run faster.
|
|
|
|
|
I remember back in my C++ days it was a trick to allocate a big chunk of "emergency buffer" memory that could then be freed and used in such situations, but that was really low-level stuff. Can it even be done in a managed environment? (I mean you can't even explicitly "free" memory anymore.)
“Time and space can be a bitch.”
–Gushie, Quantum Leap
{o,o}.oO( Check out my blog! )
|)””’) piHole.org
-”-”-
|
|
|
|
|
I am always shocked when I don't see any testing for this; just crashing is unacceptable behavior. 
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
|
|
|
|
|
When I wrote in C++, every allocation was followed by a check for null-ness. In .Net I don't perceive the necessity for everyday code. I suppose that if you're loading a crap-load of data, you should be concerned, but I haven't been in that situation yet.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Anyone working on that kind of stuff would (should) undoubtedly care about memory but I suspect few of us are working on those things when we can just by a component to handle it for us. There's little profit in re-inventing wheels after all.
"It's so simple to be wise. Just think of something stupid to say and then don't say it."
-Sam Levenson
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
