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 19:24:50

Frank Mori Hess writes:
> On Monday 18 May 2009, Bryan Green wrote:
> > Bryan Green writes:
> > > 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.
> >
> > I have correct what I said here.  The problem isn't copyability (they are
> > copyable).  Its that the shared_connection_block cannot be
> > default-constructed.  What would be the repercussions of allowing default
> > construction of shared_connection_block objects?
> 
> It probably wouldn't hurt.  In the meantime you can also use
> boost::optional<shared_connection_block> to unintrusively add an
> uninitialized state and avoid dynamic allocation.

Thanks for the tip.  That does the trick.  Now, here's a crazy suggestion.
How about adding a connection accessor method to the shared_connection_block?
Since the shared_connection_block implicitly contains a connection object
anyway, allowing access to it would alleviate the need to keep another one
around:

shared_connection_block blk(sig.connect(func));
 ...
blk.get_connection().disconnect();

I may be naive, but the implementation looks like it would be as simple as:

connection shared_connection_block::get_connection() {
    connection c(_weak_connection_body);
    return c;
}

-bryan