Re: [gtkmm] Slots from non-Gtk subclasses.
- From: Carl Nygard <cjnygard fast net>
- To: Martin Schulze <MHL Schulze t-online de>
- Cc: gtkmm-list <gtkmm-list gnome org>
- Subject: Re: [gtkmm] Slots from non-Gtk subclasses.
- Date: 24 Feb 2003 16:12:16 -0500
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]