Is it good to assert after new() everytime

[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 }
.....

[Alf P. Steinbach]

* 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.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[=?iso-8859-1?q?Erik_Wikstr=F6m?=]

On 26 Mar, 12:52, "Alf P. Steinbach" <[e-mail]:

* 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. And should you ever run
into it it's usually not much you can do about it anyway except
terminating your app.

--
Erik Wikström

[Jacek Dziedzic]

Achintya wrote:

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 }
....

In fact, neither. New (used like this) never returns a null
pointer. You should:

try {
int* i = new int;
// do something
}
catch(std::bad_alloc) {
// out of memory
}

HTH,
- J.

[Dennis \(Icarus\)]

"Erik Wikström" <er****@student.chalmers.sewrote in message
news:11**********************@y66g2000hsf.googlegr oups.com...
On 26 Mar, 12:52, "Alf P. Steinbach" <[e-mail]:

* Achintya:

<snip>

>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. And should you ever run
into it it's usually not much you can do about it anyway except
terminating your app.

Nah, there are ways to deal with it much more gracefully.

Dennis

[jk]

On 26 Mar 2007 03:36:59 -0700, "Achintya"
<vs*************@agilent.comwrote:

>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 }
....

i don't quite understand what you are trying to achieve?

if we for sake of argument pretend that new would return a null ptr,
what could you possible gain of an assert here?

assert is better for catching programming errors and not runtime
conditions e.g. checking function in-parameters.

[J.M.]

Erik Wikström schrieb:

On 26 Mar, 12:52, "Alf P. Steinbach" <[e-mail]:

>* 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.

That depends a lot on your application...

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...

Jan

>
--
Erik Wikström

[James Kanze]

On Mar 29, 11:37 pm, "J.M." <[e-mail]:

Erik Wikström schrieb:

On 26 Mar, 12:52, "Alf P. Steinbach" <[e-mail]:

* 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:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[JohnQ]

"James Kanze" <ja*********@gmail.comwrote in message
news:11*********************@d57g2000hsg.googlegro ups.com...
On Mar 29, 11:37 pm, "J.M." <[e-mail]:

the one
time I experimented under Windows NT, I couldn't get an out
of memory condition either.

Do you mean working with a compiler-supplied memory manager you couldn't or
that you built a memory manager directly on top of the virtual memory system
and couldn't identify out-of-mem?

John

[James Kanze]

On Mar 31, 10:49 pm, "JohnQ" <[e-mail]>
wrote:

"James Kanze" <[e-mail] in message

news:11*********************@d57g2000hsg.googlegro ups.com...
On Mar 29, 11:37 pm, "J.M." <[e-mail]:

the one
time I experimented under Windows NT, I couldn't get an out
of memory condition either.

Do you mean working with a compiler-supplied memory manager you couldn't or
that you built a memory manager directly on top of the virtual memory system
and couldn't identify out-of-mem?

Well, I only tried with the compiler-supplied memory manager
(malloc, in my test case). I *think* that the problem was at
the system level, however, and I also wouldn't be at all
surprised to find that it is configurable, and that the code
works with other configurations. However, every time I tried to
exhaust memory, the system would first automatically increase
the swap space, and then pop-up a window telling me that there
wasn't enough memory, and asking me to kill some applications to
make more memory available. In no case did I ever return from
malloc without having successfully allocated memory.

But as I say, that was just one particular test, and I have no
idea whether it depends on some configuration parameters or not.

--
James Kanze (Gabi Software) email: ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]