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