Re: [boost] New New Callbacks Uploaded

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-11-24 02:31:45

In message <200011232346.PAA22491_at_[hidden]>, Jesse Jones
<jesjones_at_[hidden]> writes
>My callback usage almost always looks something like this:
>
>   mPushButton = new PushButton(...);
>
>   boost::callback<void> callback(this, &MyObject::OnClicked);
>   mPushButton->SetNotifier(callback);
>
>This pretty much mandates at least one copy. It's true that I don't 
>*need* to have callbacks be copyable, but if they're not I think I'll 
>always be wrapping them up with shared_ptr which seems silly.

I don't see the need for any reference counting in this at all, which I
think demonstrates the point I was getting at. The context you've used
above is that of a GUI framework, where the effect of reference counting
such objects is, at best, going to be a drop in the ocean :-}

Also don't forget that shared_ptr allocates two objects, so in theory
you couldn't recover any ROI until your second copy anyway. Also note
that the footprint (single pointer) and working set (single heap object
with vptr + sizeof(funcobj)) of a cloning version is lower than that of
the detached reference-counted version. [Aside: This would be different
for countable_ptr, http://www.boost.org/more/count_bdy.htm, which I must
get round to Boostifying at some point.]

More generally, there is a general trend away from hidden body reference
counting as an optimisation as it has proved to be awkward and not
always an optimisation. For instance, the standard basic_string makes
effective reference counting awkward, and often a waste of effort. And
then there's multithreading. IIRC, the next (or even current) version of
Dinkumware has dropped reference counting, and SGI doesn't use it at
all. I don't see a technical reason to buck this trend and plenty of
technical reasons to follow it.

Kevlin
____________________________________________________________

  Kevlin Henney                   phone:  [phone]
  Curbralan Limited               mobile: [phone]
  mailto:kevlin_at_[hidden]     fax:    [phone]
  http://www.curbralan.com
____________________________________________________________