[haiku-development] Re: Signals and Slots
- From: Pete Goodeve <pete.goodeve@xxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 1 Mar 2012 16:54:18 -0800
On Fri, Mar 02, 2012 at 09:07:31AM +1300, Clemens Zeidler wrote:
> On Wed, 29 Feb 2012 10:56:59 +1300, Pete Goodeve
> <pete.goodeve@xxxxxxxxxxxx> wrote:
>
> >
>
> Does these function pointer approaches support virtual inheritance? If I
> got it right it always points to a function of a certain base class. If
> thats the case this lib is only limited useful, e.q. if you have a class
> that is already wired and you derive this class you may have to rewire the
> same signal/slot or even get unexpected behaviour.
Heh. I guess I never considered that. And a quick test shows that you
are right. It actually just crashes if it encounters a 'virtual slot'.
I don't think your example is quite correct, though. You don't "wire"
a class -- only an object that's been created, So you presumably can
know the actual type of object you're connecting to. But you can't sensibly
use a base class for a derived class in a connect statement (unless you
want a slot in that base class, or use a cast). So yes, it has limitations.
>
> A signal and slot mechanism is more elegant and could be as powerful as
> BMessages but it can't be done without additional code generation via moc
> or something similar. I'm also against having BMessage messaging and
> signal/slot in parallel, both doing the same and there should only be one
> system for it.
Well personally as I said before I'm pretty happy with BMessages, and, as
Alex Wilson pointed out, BHandler's notification feature gives essentially
the same many-to-many connection that slots provide. So I'm also
happy to go back to business as usual!
-- Pete --
Other related posts:
