Boost logo

Boost :

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at