473,327 Members | 1,997 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,327 software developers and data experts.

NULL pointer in overloaded operator delete []

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?
*/
}
Thanks in advance
Nov 13 '08 #1
8 6071
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?
The behaviour of your program is undefined. 'main' must return the type
'int':

int main() {

Seriously, though, everything should be OK because 'free' is explicitly
specified as a NOP if its argument is a null pointer.

You need to investigate further why on Sun it doesn't go into the
overloaded operator delete[]. And even if you don't overload, the
deletion (using 'delete' or 'delete[]') is explicitly defined as OK if
the argument is a null pointer.
*/
}
Thanks in advance
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Nov 13 '08 #2
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.

Meanwhile, I don't understand why it crashes on Sun, even if it gets
into the above 'operator delete[]'. The standard 'free' function is also
a no-op on a null-pointer argument. If it crashes, that would mean that
there's a bug in Sun's 'free' implementation.

BTW, how do you know that VC and g++ don't call it? You really checked
it or you just assumed it because it didn't crash?

--
Best regards,
Andrey Tarasevich

Nov 13 '08 #3
On Nov 13, 8: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.

Meanwhile, I don't understand why it crashes on Sun, even if it gets
into the above 'operator delete[]'. The standard 'free' function is also
a no-op on a null-pointer argument. If it crashes, that would mean that
there's a bug in Sun's 'free' implementation.

BTW, how do you know that VC and g++ don't call it? You really checked
it or you just assumed it because it didn't crash?

--
Best regards,
Andrey Tarasevich- Hide quoted text -

- Show quoted text -
Hi,

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.

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 ).”
Nov 13 '08 #4
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).
Nov 13 '08 #5
Rahul wrote:
>
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 ).”
I would recommend you to pot a _general_ null-pointer check into your
overloaded 'operator delete[]'. The reason for this is that technically
'operator delete[]' is by itself a standalone self-sufficient
resource-deallocation function. It can actually be called explicitly by
the user, should the need arise. I'd say that there's a de-facto
standard (or at least a widespread and accepted practice) to write all
resource deallocation functions so that they permit a null argument and
act as a no-op in that case.

Of course, I understand perfectly well that overloaded 'operator delete'
is not normally intended to be used as a self-sufficient function. But
nevertheless it feels like a good idea to preserve the null->no-op
guarantee for this function as well. (Standard library-provided versions
do that, BTW.) The overhead of doing the null check is less than
negligible, so I'd remove the issue of "penalizing the other platforms"
from consideration entirely.

--
Best regards,
Andrey Tarasevich
Nov 13 '08 #6
On Nov 13, 2:50*pm, Victor Bazarov <v.Abaza...@comAcast.netwrote:
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?
The behaviour of your program is undefined. *'main' must
return the type 'int':
Not undefined. It's an error which requires a diagnosis.

Of course, that is completely orthogonal to his question.
* * int main() {
Seriously, though, everything should be OK because 'free' is
explicitly specified as a NOP if its argument is a null
pointer.
You need to investigate further why on Sun it doesn't go into
the overloaded operator delete[]. *And even if you don't
overload, the deletion (using 'delete' or 'delete[]') is
explicitly defined as OK if the argument is a null pointer.
It's still the responisiblity of operator delete (or delete[])
to check; the standard doesn't guarantee that it won't be given
a null pointer; the standard requires that it be a no-op if
given a null pointer.

But of course, all he's doing is calling free() with the pointer,
and free() is guaranteed to be a no-op when given a null
pointer, so his implementation meets the requirements.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Nov 13 '08 #7
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:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Nov 13 '08 #8
James Kanze wrote:
>
It may be worth raising the issue with the committee.
It has been raised already

http://www.open-std.org/jtc1/sc22/wg...fects.html#348

--
Best regards,
Andrey Tarasevich

Nov 13 '08 #9

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

3
by: matt p | last post by:
example: FunClass myfun; FunClass *lotsofunptr=&myfun; myfun; //calls the overloaded operator; lotsofunptr->;//error help is much apreciated
6
by: Jerry Krinock | last post by:
I'm writing a class which has, as members, dynamically allocated valarrays. I'd like to overload the "=" operator so that, when operating on two objects of my class, the valarray values of the rhs...
4
by: lothar.behrens | last post by:
Hi, I have problems to delare a delete operator in a class and use it to check for valid pointer. Using release() with an additional validation routine from a separate malloc library avoids...
14
by: Ralf Goertz | last post by:
Hi, this might be intentional, but I don't see a reason, why. Running the program ---------------------- #include <iostream> using namespace std; int main(){
6
by: Lighter | last post by:
Big Problem! How to overload operator delete? According to C++ standard, "A deallocation function can have more than one parameter."(see 3.7.3.2); however, I don't know how to use an overloaded...
6
by: Angel Tsankov | last post by:
How can an overloaded operator& take the address of its argument: template<typename T> Smth operator &(T& SomeObject) { // The address of SomeObject is needed here }
13
by: Tristan Wibberley | last post by:
Hi I've got implementing overloaded operator new and delete pretty much down. Just got to meet the alignment requirements of the class on which the operator is overloaded. But how does one...
4
by: abendstund | last post by:
Hi, I have the following code and trouble with ambiguity due to operator overloading.. The code is also at http://paste.nn-d.de/441 snip>>
9
by: itdevries | last post by:
Hi, I've ran into some trouble with an overloaded + operator, maybe someone can give me some hints what to look out for. I've got my own custom vector class, as a part of that I've overloaded...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.