Re: NULL pointer in overloaded operator delete []
On Nov 13, 4:13 pm, Andrey Tarasevich <andreytarasev...@hotmail.com>
wrote:
Rahul wrote:
Please read the following code
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?
*/
}
Unfortunately, the language specification is (was?) not
sufficiently clear on whether the control should go into the
overloaded 'operator delete' when the delete-expression is
invoked on the null-pointer of corresponding type, even though
the standard does say that delete-expression on null-pointer
is a no-op. Apparently Sun compiler thinks that it should be
called.
Or that the implementation is allowed to call it. According to
the latest draft, "The value of the first argument supplied to a
deallocation function may be a null pointer value; if so, and if
the deallocation function is one supplied in the standard
library, the call has no effect." I'm not quite sure what the
implications of that "is one supplied in the standard library"
are meant to be---taken literally, since his function is not one
provided by the standard library, the sentence wouldn't seem to
apply. But somehow, that doesn't make sense.
It may be worth raising the issue with the committee.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34