Boost logo

Boost Users :

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

shared_connection_block blk(sig.connect(func));

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;


Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at