deleting a null pointer

[ma740988]

Given the snippet.

class foo {
public:
~foo() {
// type id should be able to get the type of the class ( I think )
std::cout << " foo destructing " << std::endl;
}
};
int main() {

foo *ptr = new foo () ;
delete ptr;

foo *ptr_ ( 0 );
if ( ptr_ ) {
delete ptr_ ;
}
}

If memory serves the check "if ( ptr_ )" is NEVER (UN) necessary.
Trouble is, I don't recall the impetus surrounding why or where in the
standard I found this. My standard is not within arms reach that
said, the question: Could I get confirmation on that deleting a void
pointer is indeed valid and where (source) in the standard I could
confirm this?

Thanks alot

[Victor Bazarov]

ma740988 wrote:

Given the snippet.

class foo {
public:
~foo() {
// type id should be able to get the type of the class ( I think )
std::cout << " foo destructing " << std::endl;
}
};
int main() {

foo *ptr = new foo () ;
delete ptr;

foo *ptr_ ( 0 );
if ( ptr_ ) {
delete ptr_ ;
}
}

If memory serves the check "if ( ptr_ )" is NEVER (UN) necessary.
Trouble is, I don't recall the impetus surrounding why or where in the
standard I found this. My standard is not within arms reach that
said, the question: Could I get confirmation on that deleting a void
pointer is indeed valid and where (source) in the standard I could
confirm this?

[expr.delete]/2 :
"In either alternative {delete or delete[] -- vb}, if the value of the
operand of delete is the null pointer the operation has no effect."

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Greg Comeau]

In article <6f************ *************** *******@k13g200 0hse.googlegrou ps.com>,
ma740988 <ma******@gmail .comwrote:

>Could I get confirmation on that deleting a void pointer

....null pointer...

>is indeed valid and where (source) in the standard I could
confirm this?

$12.4p12 and $3.7.3.2p3 help but the exact refernce is $5.3.5p2
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[ma740988]

Victor, Greg as always, thanka alot. One last item on this. There's
a common guideline - if you will - that suggests
if ( ptr_ )
delete ptr_ ;

I'm trying to understand why would I _ever_ do that? Thus far the
only scenario I could concoct surrounds:
delete ptr_ ; // item 1
// in some other translation unit.. later I do
delete ptr_ ; // item 2

item 1: Ok there.
item 2: I suspect here I could solve a potential issues with an 'if
( ptr_ )'. Trouble, is, if I opt to delete a pointer twice, then I'm a
mook, something is amiss in the code.

Oh well, it's a guideline though I might add I find it (literally)
drives me insane wnen I encounter it.

[Bo Persson]

ma740988 wrote:

Victor, Greg as always, thanka alot. One last item on this.
There's a common guideline - if you will - that suggests
if ( ptr_ )
delete ptr_ ;

I'm trying to understand why would I _ever_ do that?

You can find this in old code, from the time before there was a C or
C++ standard. At the time, various compilers had different ideas about
what delete NULL meant.

This is one reason for creating a standard! .-)
Bo Persson

[Greg Comeau]

In article <3P************ *************** ***@posted.comn et>,
Alf P. Steinbach <al***@start.no wrote:

>* ma740988:

>Victor, Greg as always, thanka alot. One last item on this. There's
a common guideline - if you will - that suggests
if ( ptr_ )
delete ptr_ ;
I'm trying to understand why would I _ever_ do that?

The 'if' will always be redundant.

> Thus far the
only scenario I could concoct surrounds:

delete ptr_ ; // item 1
// in some other translation unit.. later I do
delete ptr_ ; // item 2

item 1: Ok there.
item 2: I suspect here I could solve a potential issues with an 'if
( ptr_ )'.

No, you could not.

Anyway that 'if' is performed by 'delete'.

>Trouble, is, if I opt to delete a pointer twice, then I'm a
mook, something is amiss in the code.

Oh well, it's a guideline though I might add I find it (literally)
drives me insane wnen I encounter it.

Good. Because that means you still have a working mind. :-)
As opposed to those writing the guideline.

Once upon a time, in a galaxy far far away, it was actually
unclear what delete of a null pointer did, same as free()ing
a null pointer -- different implementations did different things.
So the original intents of some of these rules makes sense.
On the on side of the coin, consistency in coding guidelines
makes sense, but of course sometimes logic defies itself.
Also, there are some who have determined that for their own
code that the if is faster in some critical code, although
I never quite totally bought that argument even if they
could show me their (no doubt correct) timing results.
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[Gennaro Prota]

ma740988 wrote:

Victor, Greg as always, thanka alot. One last item on this. There's
a common guideline - if you will - that suggests
if ( ptr_ )
delete ptr_ ;

I'm trying to understand why would I _ever_ do that? Thus far the
only scenario I could concoct surrounds:
delete ptr_ ; // item 1
// in some other translation unit.. later I do
delete ptr_ ; // item 2

item 1: Ok there.
item 2: I suspect here I could solve a potential issues with an 'if
( ptr_ )'.

Nope: evaluating ptr in the if invokes undefined behavior, just like
double deletion would do. You can set the pointer to null after every
delete (in which case, of course, you have no UB evaluating the if
condition later), but then the point you make immediately below holds.
(In any case, you can't do anything --except proper design-- against
something like

ptr2 = ptr;
...
delete ptr;
ptr = 0;
...
delete ptr2;
ptr2 = 0;
)

Trouble, is, if I opt to delete a pointer twice, then I'm a
mook, something is amiss in the code.

Right. The code misses proper design.

--
Gennaro Prota | <https://sourceforge.net/projects/breeze/>
Do you need expertise in C++? I'm available.