0

Compiler: MSVS 2008

Boost: 1.49

Code:

#include <boost/signals2.hpp>
#include <boost/thread.hpp>

class SigOwner
{
public:
    typedef boost::signals2::signal<void (int)> OSig;
    OSig _signal;

    void doConnect(OSig::slot_type slot) { _signal.connect(slot); }
};

class SigUser
{
public:
#if defined(FAIL2)
    boost::mutex sync;
#endif
#if defined(FAIL1)
    boost::condition_variable evSig;
#endif

    void setup(SigOwner &so)
    {
        so.doConnect(*this);   // failure 1 traces back to this line
    }

    void operator()(int value) // signature to make SigUser a slot
    {
    }
};                             // failure 2 flags on this line

As presented, this compiles OK.

If I define FAIL1 (with or without FAIL2), a compiler error occurs within signals2/slot_template.hpp: error C2679: binary '=' : no operator found which takes a right-hand operand of type 'const SigUser' (or there is no acceptable conversion)

I don't know why the *this is being considered const.

If I define FAIL2 (without defining FAIL1) a compiler error occurs at the indicated line: error C2248: 'boost::mutex::mutex' : cannot access private member declared in class 'boost::mutex'

I don't know what private member is trying to be accessed.

Can anyone provide me a clue? Preferably a clue that allows me to define both FAIL1 and FAIL2 and get a successful compilation.

Mike C
  • 1,224
  • 10
  • 26

1 Answers1

2

Neither mutex nor condition_variable are copiable, so your SigUser is not copiable, so you cannot pass it to doConnect this way. One way to work-around this is to define sync and evSig as (smart)pointers.

Igor R.
  • 14,716
  • 2
  • 49
  • 83
  • This sounds plausible; I will follow up Monday. Any idea why the errors are different with only a mutex member vs. only a condition_variable member? – Mike C Aug 25 '12 at 16:12
  • @Mike C yes, this is because of the difference in `mutex` vs `condition_variable` definitions. In `mutex` private copy-ctor is defined correctly: `mutex(mutex const&);`, while in cond.var it's defined like this: `condition_variable(condition_variable&);` . – Igor R. Aug 26 '12 at 07:18
  • It turns out that the entire approach was not useful anyway: since connecting a slot makes a copy of the slot, the data in the original slot object don't get updated by the slot call. What worked for me was to replace `operator()(int)` with an `OnSignal(int)` method, and then pass a functor to the `connect()` call. The functor is instantiated as: `boost::bind(&SigUser::OnSignal, this, _1)` – Mike C Aug 28 '12 at 17:09
  • @Mike C of course the whole object get copied! The most simple workaround is to use pImpl idiom where possible (which is good for many other aspects as well). – Igor R. Aug 28 '12 at 17:59