Re: [sigc] dynamic signals?

[Aaron Griffin <aaronmgriffin gmail com>]

> 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?

> > 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...