command window - Page 270

Force deletion of slot in boost::signals2

- by villintehaspam

Hi! I have found that boost::signals2 uses sort of a lazy deletion of connected slots, which makes it difficult to use connections as something that manages lifetimes of objects. I am looking for a way to force slots to be deleted directly when disconnected. Any ideas on how to work around the problem by designing my code differently are also appreciated! This is my scenario: I have a Command class responsible for doing something that takes time asynchronously, looking something like this (simplified): class ActualWorker { public: boost::signals2<void ()> OnWorkComplete; }; class Command : boost::enable_shared_from_this<Command> { public: ... void Execute() { m_WorkerConnection = m_MyWorker.OnWorkDone.connect(boost::bind(&Command::Handle_OnWorkComplete, shared_from_this()); // launch asynchronous work here and return } boost::signals2<void ()> OnComplete; private: void Handle_OnWorkComplete() { // get a shared_ptr to ourselves to make sure that we live through // this function but don't keep ourselves alive if an exception occurs. shared_ptr<Command> me = shared_from_this(); // Disconnect from the signal, ideally deleting the slot object m_WorkerConnection.disconnect(); OnComplete(); // the shared_ptr now goes out of scope, ideally deleting this } ActualWorker m_MyWorker; boost::signals2::connection m_WorkerConnection; }; The class is invoked about like this: ... boost::shared_ptr<Command> cmd(new Command); cmd->OnComplete.connect( foo ); cmd->Execute(); // now go do something else, forget all about the cmd variable etcetera. the Command class keeps itself alive by getting a shared_ptr to itself which is bound to the ActualWorker signal using boost::bind. When the worker completes, the handler in Command is invoked. Now, since I would like the Command object to be destroyed, I disconnect from the signal as can be seen in the code above. The problem is that the actual slot object is not deleted when disconnected, it is only marked as invalid and then deleted at a later time. This in turn appears to depend on the signal to fire again, which it doesn't do in my case, leading to the slot never expiring. The boost::bind object thus never goes out of scope, holding a shared_ptr to my object that will never get deleted. I can work around this by binding using the this pointer instead of a shared_ptr and then keeping my object alive using a member shared_ptr which I then release in the handler function, but it kind of makes the design feel a bit overcomplicated. Is there a way to force signals2 to delete the slot when disconnecting? Or is there something else I could do to simplify the design? Any comments are appreciated!

Search Results

Search found 33882 results on 1356 pages for 'command window'.

Page 270/1356 | < Previous Page | 266 267 268 269 270 271 272 273 274 275 276 277 | Next Page >

- by villintehaspam

- by SunLiWei

- by Pobe

- by user1775315

- by Geertjan

- by BBK

- by Robz / Fervent Coder

- by Geertjan

- by Lori Kaufman

- by Jason Faulkner

- by Geertjan

- by BubbaJ

- by Asian Angel

- by user295189

- by Trevor Bekolay

- by user295189

- by Sean Feldman

- by user12609056

- by Mark W

- by muralekarthick

- by Prabin Dahal

- by Greg Low

- by bohohasdhfasdf

- by Tom

- by Adrian Grigore

< Previous Page | 266 267 268 269 270 271 272 273 274 275 276 277 | Next Page >