Re: New New Callbacks Uploaded

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-11-28 10:14:43

--- In boost_at_[hidden], Douglas Gregor <gregod_at_r...> wrote:
> On Mon, 27 Nov 2000 22:01:37 -0000
> "William Kempf" <sirwillard_at_m...> wrote:
> > I'm still on the fence.  I see problems with both sides, but not 
> > clear cut instances where one would be preferred over the other.
> 
> In a GUI system it is very common to have several callbacks target 
the same function object (e.g., a menu item, a keyboard accelerator, 
and a toolbar button all performing the same function). I may 
concisely write this as:
> 
> myButton.onClick = myMenuItem.onSelect = myKeyboardAccel.onPressed 
= make_callback(some_functor);
> 
> If I were to diagram where these events are going, I would of 
course have them pointing to an instance "some_functor". If I were 
concerned with multiple threads, it would be an obvious issue and I 
would write some_functor with the appropriate synchronization 
barrier. Since each event "means" the same thing, creating separate 
instances is unnatural (or wrong, depending on some_functor).

First, GUI programming is just one example of the use of callbacks, 
and not anywhere close to the major usage of them.  Second, such 
callbacks are unlikely to retain state of any kind, making them 
relatively thread safe (I say relatively, because the actual function 
called by the functor must, obviously, still be thread safe, but this 
is outside the discussion at hand here).  So thread safety doesn't 
factor into the choice here at all.  Finally, I don't agree that 
creating seperate instances is unnatural or wrong.  I can see nothing 
to support this claim.  Care to elaborate?

> > > > implementation becomes detrimental you can wrap it in a ref-
> > counting 
> > > > proxy (whether it be shared_ptr or some other proxy).  Going 
the 
> > > > other way, for example if it's deemed too dangerous for 
threading 
> > > > use, is not really possible.
> > > 
> > > This is case where the desire to support multithreaded code is 
> > detrimental to single-threaded code.
> > 
> > I don't think the two issues parallel.  This particular issue has 
> > several work arounds that won't work as nicely for the choice 
between 
> > ref-counting or cloning.
> > 
> > > Either the degradation is in performance, or the degradation is 
in 
> > the remedy to the performance problem - using shared_ptrs makes 
for 
> > ugly usage of the callback code.
> > 
> > Not necessarily.  Especially if the "proxy" supports operator().
> 
> Using shared_ptr (with the operator() overloads) will still require 
a "new" when assigning to callbacks, e.g.:
> shared_ptr< callback<int, int> > cb = new make_callback
(some_function);

Note that I carefully avoided saying "shared_ptr" but instead 
said "proxy".  I'm not sold that shared_ptr is the appropriate proxy 
here, but the concept is still valid and counters your arguments.
 
> Of course, a derivative of shared_ptr could be used, so this isn't 
a major issue.

Not a derivative, just something similar.

Bill Kempf