Re: Operator delete question
On Oct 9, 2:30 pm, Andrey Tarasevich <andreytarasev...@hotmail.com>
wrote:
snapwink wrote:
...
int main()
{
ISocket *pISock = static_cast <ISocket *> (new TCPSocket());
pISock->Release();
return 0;
}
Compiling with GCC and running this, I am getting the expected
results:
my malloc
Socket: Ctor
TCPSock: Ctor
Socket::Release
TCPSock: Dtor
Socket: Dtor
my free
However, compiling with my embedded compiler, I get different results:
after "Socket: Dtor", the global operator delete is getting called
(instead of the one I overloaded). I want to understand what does C++
standard say about this, or is this dependent on compilers?
It is not supposed to be dependent on the compiler. The standard says
that a concrete version of overloaded 'operator delete' should be chosen
as if it was looked up from the destructor of the object being destroyed
(i.e. from the "topmost" destructor). In your case everything seems to
be fine with virtual destructors and the correct destructor is indeed
called by the compiler. GCC also selects the proper 'operator delete'.
Meanwhile, your embedded compiler seems to work incorrectly.
Thanks for the confirmation. I would try to follow up with the
compiler folks to figure out if they can fix this problem.
It would be interesting to make an extra experiment and see which
'operator delete' your embedded compiler would call if you just deleted
the object immediately with an explicit delete-expression right in 'main'
ISocket *pISock = static_cast <ISocket *> (new TCPSocket());
delete pISock;
just to check if it is somehow confused by a more "convoluted" method of
deletion through 'delete this' used in your original code.
--
Best regards,
Andrey Tarasevich
I did try "delete pISock" directly from main(). This results in the
ISocket destructor being invoked (which is not virtual). ISocket
destructor later calls global free method (I overloaded the global
delete operator as well to reconstruct this).
Interfaces having virtual destructor is a good idea (as shown by above
call). However, it would not be possible to change that since that
affects the interface's V-table structure and breaks binary-
compatibility with prior clients.