Re: Callbacks Again

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-11-20 17:12:34

--- In boost_at_[hidden], Karl Nelson <kenelson_at_e...> wrote:
> 
> > > You got it.  This is only possible with target cooperation.  
> > > For this to work the target must derive or contain an 
SigC::Object.
> > > If it isn't derived the second call will segfault on access 
> > to 'this'. 
> > > It is just the property of slots that they can handle this 
reverse 
> > case.
> > 
> > Then doesn't it eliminate Slots from being used with generalized 
> > functors, such as those created by the standard library or 
libraries 
> > such as Lambda?
> 
> Not at all.  You simply need to build a slot type for a general
> functor or lambda and it will plug into the system easily.
> 
> Ie.
> 
>   boost::callback<void> cb= Functor();
>   Slot0<void> sl= functor_slot(cb);
>   sl();  // calls cb() -> Functor::operator()()

  Slot0<void> s1;
  {
    Object obj;
    boost::callback<void> cb = Closure(&obj, Object::foo);
    s1 = functor_slot(cb);
    s1();
  }
  s1();

In the above, 'obj->foo' is really the target.  When 'obj' goes out 
of scope the slot can't automatically disconnect the target.

> > > How is the cascade achieved?  When developing SigC I
> > > tried two approaches.  One was to copy the old type into
> > > the new and the other was to separate by some neutral 
abstraction
> > > (without a vtable.)  
> > 
> > I believe it copies, but I could be way wrong here.  You should 
look 
> > at the Lambda library or talk to it's creators.
> 
> Okay, that causes same old type explosion.  It is fine for many
> systems, but would explode into massive bload in something like a 
> widget library.  Obviously the tradeoffs here depend on the
> application.

They appear to, yes, but you're talking implementation details.  
Lambda is general purpose enough that if "type explosion" occurs and 
can be prevented it should be done so there.  That's why I said I 
could be "way" wrong.  Again, I'm not familiar with the internals of 
Lambda, so don't take what I said as anything more than a guess.
 
> > > Yes.  Likely this is the distinction.  The slots are
> > > composable from function and object/member function pairs only.
> > > You can build your own slot types and thus make functors
> > > but that not commonly done.  (The new version will allow more 
tricks
> > > like this
> > > 
> > >   Slot0<void> sl;
> > >     {
> > >       Signal0<void> sig;
> > >       sig.connect(slot(&foo));
> > >       sig.connect(slot(f,&Bar::bar));
> > >       sl=sig;
> > >     }
> > >   sl(); // calls both foo() and f.bar()
> > > 
> > > which further increases the power of the multicast.)
> > 
> > Nice "trick", especially if the overhead is managed by the 
> > implementation.
> 
> Because the signals internals are reference counted they can be
> passed and converted to a slot which will then be able emit the
> signal at a later point.  Thus everything is automated such that
> the user does not need to manage any of the internal workings.
> SigC-1.0 lacked a lot of these type of functionality.

A user never manages the internals ;).  I was suggesting that 
the "trick" was nice enough to be considered by any implementation of 
related concepts, provided the implementation can manage the 
overhead, meaning prevent it from becoming detrimonious.