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
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