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