Boost logo

Boost Users :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2007-02-25 18:44:42


Timmo Stange wrote:
> Peter Dimov wrote:
>
>> You don't need tracking for the above example; bind( slot, _2, _1 )
>> stores a copy of slot. Signals currently need tracking because
>> they're noncopyable and are bound using ref(). A copyable signal
>> does not, regardless of the semantics of the copy (deep, shallow, or
>> something in between - deep for the signal, shallow for the
>> contained slots).
>
> How would such a copy behave regarding connect() and disconnect()?
> Neither should affect the original signal, so this would be either
> a deep copy or an implementation with copy on write semantics.

A shared signal is mostly equivalent to the current noncopyable signal,
except that it's less inconvenient and less unsafe. Currently you are forced
to use references or pointers to the signal, and every entity that posesses
such a reference can connect() and disconnect(). A shared_ptr<signal_impl>
reformulation has the same effect, minus the possibility of a dangling
reference.

The next step is to have a shallow slot (shared_ptr<slot_impl>) but a one
level deep copy in the signal (vector<slot>). In this case connects and
disconnects will only affect the copy, although the sharing at the
SlotFunction level may still be undesirable at times. Immutable
SlotFunctions would handle sharing (and concurrent calls) fine, of course;
only stateful function objects will have a problem.

A fully deep copy (vector< function<> >) avoids any sharing, but makes the
signal quite expensive to copy.

> I already don't like the fact that there is no distinction between
> control over connections and control over invocation. Every entity
> that is allowed to connect to a signal can also emit it, unless you
> provide a separate connect() yourself and hide the actual signal.

Is this a problem in practice?


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net