Set a pointer to null when deleting?

[Noah Roberts]

Noah Roberts skrev:

Sure? Examples given in this thread would specifically behave that way.
Far to often you write if (p != 0) p->action() instead of assert(p !=
0); p->action();

How are you applying logic here?

1) what example of pointer access would work if ptr is 0 and not
otherwise?
2) what is the relevance of the assert statement you make above?

That is a small problem as this is only something to do while
debugging.

Yes, it is good to introduce hard to read, platform dependant,
undefined behavior during debugging and then replace it with different
code on release.

The arguments against setting a pointer to 0 after deletion just keep
getting dumber and dumber...I don't really find that surprising.

 

[Phlip]

The arguments against setting a pointer to 0 after deletion just keep
getting dumber and dumber...I don't really find that surprising.

Smart code...

- uses smart pointers
- uses references
- use objects with fail-safe behaviors
- reduce 'if' statements on types*
- practices RAII
- generally only delete pointers about to go out of scope
- assign NULL to the tiny fraction of remaining pointers

*If I said "NULL is a type" here, I would get an entire thread of yacking
"NULL is a macro typically defined as 0 which is an integer,
blah-blah-blah". The book Design Patterns calls this topic "program to the
interface". Checking a pointer for NULL is a sign the design could be
generally better. It's using the interface to a pointer instead of an
interface to an object.

 

[Robert Mabee]

private:
A* aptr_;
void B::foo(A* aptr)
{
aptr_ = aptr;
}

B::~B()
{
delete aptr_;
}

OK, this is the case where setting aptr_ to NULL won't have any effect
because B (hence aptr_) is itself being destroyed. (Assuming that it
isn't B that is getting destroyed twice.)

The bug is that B::foo requires an A object that it can own, and delete,
and doesn't have a name/comment/document making that obvious to you.

No doubt you have passed the same A to multiple calls of B::foo, or
kept the A pointer and eventually deleted it, which would be the right
thing to do if B::foo did not have this undocumented requirement.

 

[Phlip]

The bug is that B::foo requires an A object that it can own, and delete,
and doesn't have a name/comment/document making that obvious to you.

It would be nice we could indeed make that problem a "bug". std::auto_ptr
can only get as far as making its constructor explicit, which is as much a
nuisance as a compilable comment. ;-)

Nice thread busting on the evils of RAII, guys...

 

[Paul M. Dubuc]

'boost' is non-standard. 'std::auto_ptr' is not suitable for some
cases due to its particular copy semantics.

No reason not to use boost. Besides, boost smart pointers have been accepted
into TR1, so they are standard and will be supported by newer compilers.

 

[Phlip]

No reason not to use boost.

Also no reason not to suggest or (lightly) discuss Boost here.

 

[Noah Roberts]

No reason not to use boost. Besides, boost smart pointers have been accepted
into TR1, so they are standard and will be supported by newer compilers.

wrong.

"This technical report is non-normative. Some of the library components
in this technical report may be considered for standardization in a
future version of C++, but they are not currently part of any C++
standard. Some of the components in this technical report may never be
standardized, and others may be standardized in a substantially changed
form."

 

[Default User]

Also no reason not to suggest or (lightly) discuss Boost here.

Do you apply that to all non-standard, third-pary libraries?



Brian

 

[Phlip]

Do you apply that to all non-standard, third-pary libraries?

Specific questions about some library X belong on X's forum.

The general question "what [portable] C++ library does X" belong in
the best platform-neutral C++ forum possible.

 

[Kai-Uwe Bux]

Do you apply that to all non-standard, third-pary libraries?

Topicality, as per our FAQ, includes planned extensions to the standard. Can
you get any closer than tr1? Even though not everything in boost is up for
standardization, boost happens to be the default route of an idea into the
standard. I consider that topical.


Best

Kai-Uwe Bux

 

[Paul M. Dubuc]

wrong.

"This technical report is non-normative. Some of the library components
in this technical report may be considered for standardization in a
future version of C++, but they are not currently part of any C++
standard. Some of the components in this technical report may never be
standardized, and others may be standardized in a substantially changed
form."

Thanks for the correction. I see there are no promises about promoting
std::tr1:: into std:: but, practically speaking, this is still no reason not
to use boost or tr1 components.

 

[Noah Roberts]

Thanks for the correction. I see there are no promises about promoting
std::tr1:: into std:: but, practically speaking, this is still no reason not
to use boost or tr1 components.

I agree, and I hope at least smart pointers make it into the standard.
Unfortunately it will be a long time from now before that happens and
even longer before commercial compilers catch up. I prefer to rely on
library versions of such things but since it is not in the standard
yaddda yadda, I have to write my own sometimes.