Re: [boost] Re: New New Callbacks Uploaded

From: Karl Nelson (kenelson_at_[hidden])
Date: 2000-12-05 16:09:43

> I think the point here is that sharing is not a solution to a problem:
> It is only ever a part of a solution, never the whole solution. The
> reference counting itself does not really raise many profound issues,
> but the thing being counted must be considered. Is it immutable? Should
> its semantics reflect sharing? If yes, then is it safe to do so? If no,
> then how can it be unshared?
> 
> Reference counting of mutable objects presents challenges for both the
> yes and no case: the requirement of additional locking in the former for
> an MT environment, and the issues with COW in the latter. It turns out
> to be bad whichever way you look. You cannot debate the merits of
> reference counting without considering the solution it is a part of.

Just for reference, sigc++ uses reference counting but the objects
created are immutable as far as the programmer is concerned.  
I do not address the threading problems or most ominous is a 
reference stored in the callback.  Those are undefined behavior.

> >>  Sharing just is a bigger can of 
> >> worms unless there is a compelling reason to favor it over cloning.
> >
> >One of the reason I agreed with for choosing cloning.  It's just not 
> >the reason we've been debating here.
> 
> Definitely.
> 
> >> (Personally I prefer sharing over cloning, but I don't feel that
> >> it would meet the needs thus far described.)
> >
> >The other reason to prefer cloning is that a sharing version can be 
> >trivially built on top of the cloning version, or shared_ptr can be 
> >used for simplicity.
> 
> Agreed, so that we can build from the bottom up.

I should point out that shared pointer to a cloned object is not
the same as a a pure refcounted system.   Rather that trying
to explain it a picture is worth a thousand words...

Clone system

   _____       ____________________
        |     |                    |
 handle |---->|  adaptor 2         |
   _____|     | __________________ |
              || adaptor 1        ||
              || ________________ ||
              ||| generic_functor|||
              ||| ______________ |||
              |||| user functor ||||
              ||||              ||||
              |____________________|
 
The object pointed to by the handle is composite of all the objects.

shared pointer to cloned object..
   _____
        |--------------------------------> counter
        |      ____________________
 smart  |     |                    |
  ptr   |---->|  adaptor 2         |
   _____|     | __________________ |
              || adaptor 1        ||
              || ________________ ||
              ||| generic_functor|||
              ||| ______________ |||
              |||| user functor ||||
              ||||              ||||
              |____________________|

Pure counter system
  _______     _______     _______     _________________
         |   |       |   |       |   |                 |    
  handle |-->| adp 1 |-->| adp 2 |-->| generic_functor |
  _______|   |(count)|   |(count)|   |  (counter)      |
             |_______|   |_______|   | _______________ |
                                     || user functor  ||
                                     |_________________|

In other words, I don't think you could get a counted 
system from uncounted system.  And thus since 
as multicast system is inevitably a counted system 
you can't build up.  

The best you can do is build a good self contained system
to solve a select set of problems.  Then build a second system
to solve different set of problems and describe a reasonable
set of interaction between the two.

Similarly, I showed earlier that you can't build a system
which takes a functor from a system which does not track
dependencies and create the dependencies.  (William agree or
gave up in frustration when we discussed this a few weeks ago.)

If you were to allow it you could do this....

   functor<void,int> f= functor_from_method( object, &Object::method);
   slot<void,int> sl=f; 

Unless you pierce the f to get the object from which the functor
was made you can't add the dependency for the slot to track.  

--Karl