The above is plausible... but it's just plain stupid if you've something
akin to the following in your code:
{
int* p = new int;
//do some stuff
delete p;
p = 0;
//do some stuff
delete p;
}
Well, lets take a more elaborate example (I'll keep it brief, but I
realise we need copy constructors etc, so don't crit me on that). This
was typically code to be written before the age of auto_ptr's and
scoped_ptr's.
class XC
{
public:
XC();
~XC();
void doSomethingCausing_A_ToDie();
private:
AC* a_;
BC* b_;
DC* c_;
void Allocate(); //creates dynamically allocated objects
void Cleanup(); //cleans ....
};
XC::XC()
: a_(0), b_(0), c_(0)
{
try
{
Allocate();
}
catch(...)
{
Cleanup();
throw;
}
}
void XC::doSomethingCausing_A_ToDie()
{
delete a_; a_ = 0;
}
XC::~XC()
{
Cleanup();
}
From above example - a couple of things.
1) It was necessary to initialise the members to zero in the beginning.
This way Cleanup could be envoked consistently during failure to
construct, as during destruction.
2) It was necessary to set a_ to 0 after deletion during
doSomethingCausing_A_ToDie(), this way Cleanup still worked correctly
during destruction. No, not only during debugging - always.
However, the following is grand:
void SomeFunction()
{
int* p = new int[10];
//do some stuff
delete [] p;
#ifdef DEBUG
p = 0;
#endif
}
Well, for this example I would rather use:
void foo()
{
int p[10] = {}; //or
std::vector<int> q(10, 0 ); //or
boost::scoped_array<int> r( new int[100] );//or
boost::array<int,10> s = {};
}
.... but I get your point. Actually, in the above case (your example)
setting p to NULL would be worthless, even during debugging. The
example is just not adequate (p is on the stack, why set it to NULL
just prior to the stack vanishing?). However, sometimes it is very
necessary to set p to NULL (in other examples).
What's the name for the most used macro which indicates if you're in DEBUG
mode? I recall seeing something like NDEBUG. Would it be:
Yes, it NDEBUG - used with assert macro.
W
.