Re: [sigc] dynamic signals?

[Martin Schulze <martin-ml hippogriff de>]

Am 05.04.2005 18:16:23 schrieb(en) Aaron Griffin:
> > Your scenario seems to be possible to implement. You are aware, of
> > course, that you loose any kind of type safety! Wrong connect/emit
> > function calls would not be detected at compile time and cause the
> > program to segfault at run time.
>
> That's one of my biggest concerns, I believe what I am going to do,
> is
> to use dynamic_cast to check the proper types... in debug mode of
> course, I don't want dynamic_cast mucking things up in a non-debug
> build
>
> > Note that
> >
> > > sc.connect("second-signal", sigc::ptr_fun(foo));
> >
> > cannot be implemented like this. Normally, the argument to
> > signal.connect() is converted to a slot object implicitly according
> to
> > the type the parameter to signal.connect(). This type depends on
> the
> > template signature of the signal. Since in the code above the
> > information from the signal's template signature is not available,
> the
> > exact type of the slot has to specified manually like in:
>
> hmmm, what about the following:
> connect(const std::string& signame, sigc::slot_base& s);
> the signal_base::connect(slot_base) would not fail then... is there
> any operation, besides emit, which would cause this to fail, in the
> context of using signal_base/slot_base?

Still, sigc::mem_fun() & Co. don't return a sigc::slot object and an  
implicit conversion to sigc::slot_base is not possible. Therefore you  
have to insert an explicit conversion.
To answer the second question: emit() will be the only function that  
fails if there is something wrong with the types.

> > > sc.emit("second-signal",2);
>
> in combination of the previous 2 responses, the emit function would
> have 8 overloads (for 0 params to 7 params) which would dynamic_cast
> the signal_base object to a proper sigc::signal<...> based on the
> parameters.  dynamic_cast should throw a bad_cast (assuming I'm
> casting as a reference) if the types don't match...
>
> The problem with this idea is that, the only type I can successfully
> type-check would be in the emit function, and at runtime.  I'm
> concerned if there would be any other operations which would require
> proper types (I'd have to dynamic_cast there as well).  It wouldn't
> bother me too much to require runtime checking while in debug...
> _______________________________________________
> libsigc-list mailing list
> libsigc-list gnome org
> http://mail.gnome.org/mailman/listinfo/libsigc-list