Frank Mori Hess writes:
On Friday 15 May 2009, Bryan Green wrote:
It is obviously awkward to be forced to convert this code to use an RAII object, and I'd rather not do a full connect/disconnect for this state change. What do you think? Should I be thinking about this differently? Or can a good case be made for bringing back the block()/unblock() methods?
Is it really so awkward? shared_connection_block has block/unblock methods. The shared_connection_block constructor does always immediately block the connection though, maybe adding a constructor which defers blocking would help.
Having such a constructor might save some work in some cases. It seems less awkward now that I realize the shared_connection_block does not hold a reference to the connection object it is initialized with. That had been my first impression. I guess what I still find awkward is having to dynamically allocate a shared_connection_block object for each of my connections, possibly in addition to a connection or a scoped connection object. I had previously been using one scoped connection object per connection. Now I need one scoped connection and one dynamically allocated shared_connection_block per connection, such as this: class widget { private: boost::signals2::scoped_connection conn; boost::scoped_ptrboost::signals2::shared_connection_block conn_blk; ... public: void initialize(const eventsource &src) { conn = src.event_signal().connect(&widget::update,this); conn_blk.reset(new boost::signals2::shared_connection_block(conn)); conn_blk->unblock(); } void toggle_active_state() { ... if (inactive) conn_blk->block(); else conn_blk->unblock(); } }; I suppose I don't need the connection object at all if the widget itself is trackable. But now that I've looked at the shared_connection_block code, I'm wondering, why is it noncopyable? It looks to me like it could be. If it were copyable/assignable (and ultimately, movable), I wouldn't need to dynamically allocate it. -bryan