Re: Is it good to assert after new() everytime
On Mar 29, 11:37 pm, "J.M." <jm_jm_remove_t...@gmx.de> wrote:
Erik Wikstr=F6m schrieb:
On 26 Mar, 12:52, "Alf P. Steinbach" <a...@start.no> wrote:
* Achintya:
Is it good to assert the pointer *each* time after a new() is called?
or it should be a normal if condition check. which of below is good
practice: (I know assert works only in debug)
1)
.....
int* i;
i = new int;
assert( i )
....
OR
2)
....
int* i;
i = new int;
if( i )
{
//do something
}
else { //do something }
....
Both are ungood.
In standard C++ you will never get a nullpointer from ordinary 'new'.
If 'new' fails you get a std::bad_alloc exception.
I never personally check for those exceptions (though they might be
caught in some generic catch-all in main) because in most cases the
risk of running out of memory is very low.
If you're not catching the exception, you should set the new
handler so that it doesn't occur. (Most of my programs set the
new handler to generate an error message and abort.)
That depends a lot on your application...
And the context in which it runs... On many systems (Linux,
Windows), you can't handle out of memory anyway, at least in the
default configurations. And on most systems, you can't
systematically handle it---only if it occurs in a new.
And should you ever run
into it it's usually not much you can do about it anyway except
terminating your app.
Well, you could always stop that particular operation that the user wanted
and give him the option of doing something else.. Letting a program crash
is not really an acceptable to me...
Which is why you set the new handler.
Interrupting a given operation but continuing to handle others
is a good solution for many applications, if:
-- operations are more or less open, so that you cannot know
in advance the amount of memory an operation might need,
-- you can be sure that the out of memory condition will occur
during a new, and not, say, because of stack overflow (most
of the cases I've seen of "open" operations have involved
recursive descent parsing, which means that stack overflow
is more likely than out of memory), and
-- you are sure that the systems you are running on are
configured so that you can actually detect the condtion:
this is not the default configuration for Linux, and the one
time I experimented under Windows NT, I couldn't get an out
of memory condition either.
As a general rule, unless you take a number of special
precautions, you cannot exclude your programming crashing
because of a lack of memory.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34