Why can't 2 or more boost::thread objects represent the same thread? [modified]
-
After creating some thread, I want to keep track of them in a vector (vectorboost::thread ), but it fail. So I need to use vectorboost::thread\*, but in this way, I have to free them manually.
modified on Monday, August 17, 2009 9:16 AM
-
After creating some thread, I want to keep track of them in a vector (vectorboost::thread ), but it fail. So I need to use vectorboost::thread\*, but in this way, I have to free them manually.
modified on Monday, August 17, 2009 9:16 AM
followait wrote:
(vector ), but it fail.
What do you mean by "it fails" ? I never used boost::thread before but if you are getting a compilation error, it probably means that the class do not allow to make copies of an instance (e.g. they made the assignement operator and copy constructor private).
Cédric Moonen Software developer
Charting control [v2.0] OpenGL game tutorial in C++ -
followait wrote:
(vector ), but it fail.
What do you mean by "it fails" ? I never used boost::thread before but if you are getting a compilation error, it probably means that the class do not allow to make copies of an instance (e.g. they made the assignement operator and copy constructor private).
Cédric Moonen Software developer
Charting control [v2.0] OpenGL game tutorial in C++Cedric Moonen wrote:
the class do not allow to make copies of an instance (e.g. they made the assignement operator and copy constructor private).
Exactly right - just like IOstreams
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
After creating some thread, I want to keep track of them in a vector (vectorboost::thread ), but it fail. So I need to use vectorboost::thread\*, but in this way, I have to free them manually.
modified on Monday, August 17, 2009 9:16 AM
Use a
std::vector<boost::shared_ptr<boost::thread> >. That way you get a copyable object that manages its resources itself. it makes a lot of sense for a thread object to be non-copyable[^] - just like it makes sense for an iostream to be non-copyable. When you have a link to a concept visible outside your program, you only want one object to manage it otherwise you could get contradictory scenarios happening, like one object killing the thread while another is trying to join the thread or something.Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
After creating some thread, I want to keep track of them in a vector (vectorboost::thread ), but it fail. So I need to use vectorboost::thread\*, but in this way, I have to free them manually.
modified on Monday, August 17, 2009 9:16 AM
Or you can use boost::ptr_vectorboost::thread and it will delete the pointers for you when it goes out of scope. Of course, Stuart's solution with shared pointers will work as well and may be even safer.
-
Use a
std::vector<boost::shared_ptr<boost::thread> >. That way you get a copyable object that manages its resources itself. it makes a lot of sense for a thread object to be non-copyable[^] - just like it makes sense for an iostream to be non-copyable. When you have a link to a concept visible outside your program, you only want one object to manage it otherwise you could get contradictory scenarios happening, like one object killing the thread while another is trying to join the thread or something.Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
But when using pointer, this still will happen. Maybe things should be synchonized, but it'll be inefficient.
followait wrote:
But when using pointer, this still will happen.
No it won't - you'll be copying the pointer, not the object it refers to.
followait wrote:
Maybe things should be synchonized, but it'll be inefficient.
Really? I think not.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
followait wrote:
But when using pointer, this still will happen.
No it won't - you'll be copying the pointer, not the object it refers to.
followait wrote:
Maybe things should be synchonized, but it'll be inefficient.
Really? I think not.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
Stuart Dootson wrote: No it won't - you'll be copying the pointer, not the object it refers to. More than one pointers can do things than conflicts simultaneously in different threads. Stuart Dootson wrote: Really? I think not. Agree, it's good to keep it simple for the fundamental concept. It can be encapsulated as needed.