|
Boost : |
From: Douglas Gregor (gregod_at_[hidden])
Date: 2004-03-09 13:48:00
On Monday 08 March 2004 09:13 pm, Thomas Witt wrote:
> Douglas Paul Gregor wrote:
> > On Sun, 7 Mar 2004, E. Gladyshev wrote:
> >
> > Yes, but it seems that I've omitted any way to get to the combiner.
> > Sounds like something we should add.
That was me, actually; I'm already convinced, and the omission of the combiner
was an unfortunate oversight.
> Violent agreement. I have another use case, I came across recently.
Always appreciated.
> Think of a container C that stores elements of type E. The container has
> a signal that is called whenever an element is added. The element has
> destroy method and a signal that is emitted when it is destroyed.
>
> The problem is that currently calling remove during a call to a slot
> connected to the add signal of the container leads to desaster.
This is a problem with the data structure storing the E elements, not Signals
itself, right? Signals is designed to be resilient to this type of thing.
> The easy
> solution would be to connect the slot combiner to the remove signal and
> stop slot calling in case the element is removed. Though this is really
> complicated now as there is no direct access to the combiner.
I'll check in the fix in a few hours.
Doug
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk