Re: [sigc] derive from sigc::trackable directly?

[Chris Vine <chris cvine freeserve co uk>]

On Wednesday 28 December 2005 16:35, John K. Grant wrote:
> Hi,
> This is might be my first post, I've enjoyed reading this list for a
> while, but I'm a newbie, so bare with me.
>
> Does a class actually *need* to derive from trackable?  Can one
> implement an auto-disconnect feature in one's Base class without using
> trackable?  I am working with an engine whose base class supports
> signals/slots, but is also reference counted.  The authors chose to use
> multiple inheritance, deriving from trackable and a Referenced class.  I
> would like to help eliminate this multiple inheritance, so I was
> wondering if it is necessary to derive from trackable.
>
> Also, has this thread ended?  What was the resulting recommended usage?
> Thank you much, -John
>
> Dick Eimers wrote:
> >> When DerivedX derives from sigc::trackable as you show, the order is
> >> the same (IIRC), but in this case it depends on the order, i.e.
> >>    struct X: base, sigc::trackable{..};
> >> is not equivalent to
> >>    struct X: sigc::trackable, base{..};
> >
> > You remember correctly and I should have paid more attention to this..
> >
> >> Auto-disconnecting is fundamentally flawed when achieved via this
> >> baseclass. The problem is that if you derive from a class, there is a
> >> time between ~derived() is called and when it is disconnected in
> >> ~trackable(). If in between a call to one of its slots is done, these
> >> slots end in nirvana. I'd say the solution is to disconnect in the
> >> most derived dtor manually.
> >
> > This explanation sounds plausible except for the "[..] the solution is
> > to disconnect in the most derived dtor manually"-part. It heads for
> > auto-disconnecting being fundamentally flawed.
> >
> > Is manually disconnecting considered to be the best practice and should
> > sigc::trackable be avoided and used only with flat-hierarchies?

The explanation seemed implausible to me.  Once the object in question has 
begun its destruction, the only circumstances in which a member slot of the 
object undergoing destruction could be called from the same thread of 
execution before sigc::trackable's destructor is invoked is if the destructor 
of the object or of any of its base or member objects attempts to invoke it.  
It is entirely valid for a destructor of an object to access its own methods 
(including its own slots) and its own member data, and this would not end in 
"nirvana".  For the destructor of a base class to call a derived class's 
member functions (including a member slot) would be ridiculous and would be 
an obvious coding error.

If the slot is invoked on an object undergoing destruction from another thread 
of execution, this would also be a coding error since such race conditions in 
threaded applications should have been avoided at the design stage or 
appropriate mutual exclusion or synchronisation techniques employed.  That 
would equally be the case if the slot were to be disconnected manually.

Chris