Re: NULL pointer in overloaded operator delete []
Rahul wrote:
Rahul wrote:
class Test{
public:
void * operator new [] (size_t t)
{ return malloc(t); }
void operator delete [] (void *p)
{ free(p); }
};
void main () {
Test *p= 0;
delete [] p;
/* What should happen here, Should the call go inside Test::operator
delete []. Because what I learned from books is that deleting a NULL
pointer is safe (calling ::operator delete[] on a NULL pointer does
not crash). But here it causes a crash on Sun CC because it gets
inside Test::operator delete [] whereas on VC++ and g++ it doesn't.
Should I put a check in Test::operator delete [] for "p=
!
=NULL"? Is Sun CC behaving as per the C++ standard?
*/
}
[...]
Sorry for my ignorance. But that is just a dummy code which I wrote
quickly, so actually its "int main" only
and the operator delete [] does not call free(), It manages a double
linked list internally and de-references the pointer p before actually
freeing the memory. Which causes a crash.
Which means your code may be at fault.
So I wanted to know if I should put a platform specific NULL check in
operator delete [] OR should make it general. Doing that would
penalize other platforms un-necessarily, of-course the cost is not
much considering the whole application. But my point is, why to
penalize other platforms if they are behaving as per the standard (If
at all they are ).
You should first write a test program to see what is really happening on
your platform. First, see if free( 0 ) is crashing:
int main() { free( 0 ); }
then see if NULL is being passed to your operator delete []:
class Test {
public:
void* operator new [] ( size_t s ) throw() { return malloc( s ); }
void operator delete [] ( void* p ) throw() { assert( p ); free( p ); }
};
int main()
{
Test* p = 0;
delete [] p;
}
Once you know what's going on, you can decide how to handle your
compiler's non-conformance (assuming there is any).