Re: [gtkmm] Slots from non-Gtk subclasses.



On Mon, 2003-02-24 at 05:43, Martin Schulze wrote:

> > Why this solution was not mentioned yet?
> > There is a way to connect method of a class that is not derived from 
> > SigC::Object.
> > I've read something about "use it on your own risk" earlier, but haven't met 
> > any problem with it for now.
> > 
> > 
> > #include <sigc++/class_slot.h>
> > 
> > ...
> > 
> > <SIGNAL>.connect (SigC::slot_class(<MyClass>, &<MyFunc>));
> > 
> > ...
> 
> You will experience problems if the lifetime of the <SIGNAL> object
> exceeds the lifetime of the <MyClass> object: The connection won't
> be destroyed automatically and unless you destroy the connection
> manually your program segfaults on <SIGNAL>.emit()!
> 
> By the way: According to my rusty c++ knowledge you should only
> use virtual base classes if you really need them for efficiency reasons.

Umm, I think you need virtual base class anytime you derive from two
classes that use the same base class.  The classic "diamond" inheritance
tree shows what happens.
            A       A(1)    A(2)
           / \       \       /
          B   C       B     C
           \ /         \   /
            D            D

If B & C didn't inherit virtually from A, then calling B::foo propagates
to A(1)::foo, while calling C::foo propagates to A(2)::foo.  So then
you've got two base classes (B & C) whose ancestors (A(1) & A(2)) are
easily in inconsistent states.  These bugs cause wierd behavior more
often than segfaults, and it's not always clear when debugging why
variables became inconsistent.


-- 
Carl Nygard <cjnygard fast net>




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]