Is there a way to stop a boost::signal from calling its slots if one of them returns true?

Question

I am using the boost library and my question is about boost::signals.
I have a signal that might call many different slots but only one slot will match the call so I want this particular slot to return true and that the calling will stop.
Is it possible?
Is it efficient?
Can you guys suggest me a better way to do it if it's not efficient?

Adriell

Which language are you referring to? The content of your question doesn't give it away. – Fuss

I thought that mentioning in the tags that I'm refering boost was enough. – Adriell

It sounds like what you're doing shouldn't be done with signals/slots. – Landmark

Answer 1

After some research I've found that in boost documentation they write about Slots that return values.
They suggest to use a different combiner like this:

struct breakIfTrue
{
  template<typename InputIterator>
  bool operator()(InputIterator first, InputIterator last) const
  {
    if (first == last)
      return false;

    while (first != last) {
      if (*first)
        return true;
      ++first;
    }
  }
};

boost::signal<bool(), breakIfTrue> sig;

Now why is that the wrong thing to do?

Adriell

Thought combiners ran them all, but checking into the docs it says: "Combiners therefore have the option to invoke only some slots until some particular criterion is met." Given that, sounds like you've got an answer! But I will point out that this seems like a unique property of the boost signal/slot mechanism and you won't necessarily find it in other systems (like Qt) – Clorindaclorinde

+1, I have been using signals for a couple of years and never found that in the docs. Good work. – Sixtieth

Answer 2

While it may be possible, it's certainly contrary to the "generic publish/subscribe" intent of signals & slots.

I think what you're really looking for is the Chain of Responsibility design pattern.

Burnham

Answer 3

As Drew says, this doesn't sound befitting of signals and slots.

And as dribeas says, a workaround is a protocol with a bool& found parameter that starts out false, with every slot checking at the start and returns if its true. If any slot sets the value to true, then processing of the other calls will happen very quickly.

But just to cover all the bases (even the inadvisable ones), I'll mention that since boost::signals are all run on the same thread as the caller you could throw a custom exception from within the signal, then catch it at the call site. For better or worse, people occasionally resort to this when they feel they have no other option...like during visitor algorithms in the boost graph library:

How do I stop the breadth-first search using Boost Graph Library when using a custom visitor?

And now that I've mentioned it, don't do it that way. :)

UPDATE: Didn't know it but you found that boost has a mechanism for handling this elegantly with combiners that take iterators and not result values:

"The input iterators passed to the combiner transform dereference operations into slot calls. Combiners therefore have the option to invoke only some slots until some particular criterion is met."

If you're sure you're sticking with boost then you've answered your own question because that does what you want. Though do note that other signal/slot systems (like Qt's) won't have a parallel to this...

Clorindaclorinde

I stated on the tags that it's boost related. Edited the post to make sure everyone understands I'm talking about boost. My question is, is there something wrong with doing things like this? – Adriell

D'oh :) I've been trying to get the tags orthogonal so that you'd use an AND search on [boost] and [signals-slots] rather than boost-signals-slots, see for instance meta.stackexchange.com/questions/34740/… – Clorindaclorinde

The combiner w/iterators pattern is apparently endorsed in boost and is possible in both signals and signals2, so I'd say go with it if you're sure you aren't switching from boost. – Clorindaclorinde