Dissecting the SS
Lutger
lutger.blijdestijn at gmail.com
Thu Sep 28 17:51:43 PDT 2006
Georg Wrede wrote:
<snip>
> A stab at dissecting the field:
>
> The environment where SS might be used might be multithreaded or not,
> the SS bindings might be entirely known at compile time or be dynamic at
> runtime, the participating classes may be known at compile time or only
> at runtime (e.g. plugins?).
>
> That gives potentially eight separate use cases:
>
> 000 single thread entirely compile time known bindings and classes
> 001 multithread
> 010 bindings known only at runtime
> 011 multithread & bindings only known at runtime
> 100 classes only known at runtime
> 101 multithread & classes only known at runtime
> 110 both bindings & classes only known at runtime
> 111 multithread & both bindings & classes only known at runtime
>
> Obviously 111 would be the "top". But even after it is implemented, can
> there be cases where some of the others would suffice and those cases be
> popular enough that implementing them too would be warranted (especially
> for simplicity and performance)?
<snip>
I'd say yes, but it will depend of how it is actually used. For a lot of
cases, gui perhaps, performance is less important that runtime
connections, but for some things it is the other way around. After
profiling I noticed my non-tracking S&S is 2 to 3 times virtual function
call and tracking is about 5 x the cost, a specialized template for
non-tracking signals would reduce cost even more making it viable for
more use cases.
Syntax matters too, templates can mean it's very clear for the user:
Signal!() signal;
signal ~= { writefln("hello world") };
signal();
For runtime connections, a little more needs to be done I guess.
I would divide the cases in two, each with it's own benefits:
1. Lightweight, compile-time type checked and high-performance. This may
be similar to C# events and is basically a fancy container for delegates
or (preferably) all callable types.
2. Heavy weight, dynamic, with introspection. Slower, this is the QT design.
I think it is possible perhaps to implement 2 on top of 1 with a minimum
of fuss, using D's facilities for compile time string parsing.
More information about the Digitalmars-d
mailing list