Re: AddRef/Release side effects - is this ok?
Igor R. wrote:
In my project I've got COM objects, whose sole purpose is to be
wrappers for the corresponding c++ objects: a) every COM wrapper
forwards calls to its implementation object; b) every COM wrapper
listens to some async. signals from the implementation object and
forwards them to COM client(s) through connection points.
The problem origins in (b): I have to ensure that COM wrapper outlives
any async. signal coming from the implementation. The best way to do
this is to bind the CComPtr to the slot functor:
wrapper::init()
{
impl_->listenToSignals(bind(&wrapper::handler, CComPtr<wrapper>
(this)));
}
This implies that the COM-object cannot "die" until it's explicitly
disconnected from the signal, so when the user of my library wants to
get rid of such an object, he must call one more function (say, obj-
close()) before resetting his smart-ptr to the object -- which is not
just inconvenient, but also threatens the exception safety of user's
code.
I'd like to eliminate the need for this additional "finalization". The
only way I can see is to try and count those "internal" references,
and when the ref.count == internal_refcount, disconnect all the
signals.
Can't you disconnect the signals in wrapper's destructor, without
playing these pointless refcount games? The net effect of your current
scheme (assuming it works) is the same: all external clients release,
refcount reaches internal_refcount, whereupon you disconnect the
signals, which results in Release being called internal_refcount times;
on the last such Release call, refcount reaches zero and the object
destroys itself.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925