Re: Operator delete question
On Oct 19, 4:08 pm, Joshua Maurice <joshuamaur...@gmail.com> wrote:
On Oct 9, 10:22 am, snapwink <snapw...@gmail.com> wrote:
I am running into this weird behavior withoperatordeleteon 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");deletethis;}
[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 "deletethis;" 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).
I agree with you on the RAII and scope semantics. That said, the
reason I have an explicit Release() method to perform ref-counting is
as follows:
1. C/C++ compatibility:
Several clients of our API are C clients. In order to support our
interfaces for C clients as well, we export a wrapper interface
implementation. So basically, the following two would be identical
C++ client usage: pISocket->TCPSockMethod();
C client usage: ISocket_TCPSockMethod(pISocket);
2. Remoting between multi-processor OR multi-process-domain
boundaries:
We would usually have a client stub implementation that would perform
the required marshalling for function calls and send it over to the
server. Hence having an explicit Release() method suits better for
clients.
3. Your suggested RAII/scope methods are still followed by many
clients, but that is upto them. The example I gave is a trivial
example which does not follow this.
Clients allocate a interface pointer, and construct a scope object
holding pointer to that interface.
Whenever scope object goes out of scope, the destructor of the scope
object calls Release() method of the interface pointer. That way
refCnt of the interface is correctly managed.