Re: [Boost-users] [signals2] connection blocking

Subject: Re: [Boost-users] [signals2] connection blocking
From: Bryan Green (bryan.d.green_at_[hidden])
Date: 2009-05-18 13:19:04

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_ptr<boost::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