Re: Operator delete question
On Oct 9, 10:22 am, snapwink <snapw...@gmail.com> wrote:
I am running into this weird behavior with operator delete on an
embedded system, so I am wondering if this is standard C++ behavior or
is my compiler doing something wrong (RVCT 2.2 compiler). Appreciate
your patience as this is a long example:
[snip]
class Socket : public ISocket
/* Dont ask about virtual inheritence :-(
* Our embedded compiler does not support that. */
{
public:
/* This does additional ref cnt management, removing for simplicity
*/
virtual void Release () {printf ("Socket::Release\n"); delete this;}
[snip]
Just a design comment / question. This seems kind of convoluted, if I
understand you correctly. Why have an explicit "release" call which
does reference counting? This isn't very RAII. Would it not be better
to have a class ISocket which has single ownership semantics, then use
a shared ptr with a dynamically allocated ISocket instance to get
shared ownership semantics? Ex:
{
shared_ptr<ISocket> socket(new TCPSocket());
/*do whatever with socket, possibly copy-constructing socket to
other shared ptrs.*/
//...
}/*exit the scope. The destructor of shared_ptr will decrement the
shared count, and if it reaches zero, then destroy the ISocket object,
calling the destructor of ISocket, which is virtual, thus calling
~TCPSocket, thus freeing the handle, and thus everyone is happy and
merry.*/
IMO this is far more clear to the end user, far less leak-prone, and
definitely easier on the implementer as well. Also you get the added
bonus of not having a "delete this;" and potentially working around a
(potential?) compiler bug.
RAII, the style of calling deallocation functions only in destructors,
or at least guaranteeing in the presence of an early release that if
the release was "magically skipped" (like with an exception, an early
return, mis-edit of the code, etc.) then a destructor later on would
still take care of it. Moving all deallocation functions to
destructors puts the onus on the implementers of classes to guarantee
a class invariant that if the object dies, then all of its owned
resources will be freed. With that guarantee, then users of the class
just have to worry about object ownership management, which is well
known and easily doable with stack objects and member sub-objects
(including smart pointers and smart-ptr-containers).