Re: [sigc] Range over signals

[Dick Eimers <d eimers marin nl>]

> > Since the types provided as template parameters to class template
> > sigc::signal#<> is a compile-time notion, this can only work if some
> > predefined set of signal instantiations is used and hence not a very
> > flexible solution. But hopefully I am wrong.
> 
> The same would be true whether you are using your own type
> identification system or dynamic_cast<>. I don't see how you can have
> compile-time type-safety when choosing the types at runtime, but I'm not
> sure what you want to achieve.

This is what I'd like to achieve: A 'signal-container' with a list of
(signal_base*, string) pairs to lookup a certain signal by its name.
This container is to be used by various plugins in my
plugin-architecture to achieve anonymous inter-plugin-communication
based on the name of a signal. That is, a plugin can create a signal of
some type 'T' with some name 'N' and any plugin can perform a lookup of
'N' and connect to the resulting plugin. Obviously, the plugin using the
signal needs to cast the signal returned by the container to the correct
type, 'T'. 

So you are right in that I cannot have compile-time type-safety, because
I don't know which plugins are loaded and I don't know what spiffy
signals they'll be introducing. The plugin-writer needs to know the type
of the signal he want to use and cast it to the correct type at runtime.
That's where the dynamic_cast<> would come in handy; to allow for
type-safe downcasting at runtime and more importantly to recover from an
cast that failed. It is true, that I could attach some additional
type-label to a signal and test for that type-label to be as expected,
but using dynamic_cast<> that would be taken care of (by the compiler).