
Anthony Williams
writes: Chris Ross
writes: Hi there. This is an introductory question as I've just started to play with boost libraries. If this would be better on the threads- devel list, let me know, but I thought starting here would be good.
Here is fine.
I was playing with the threads library in 1.35, and I noticed that I can't (with gcc 4.3 on Linux) put boost::thread objects into an STL container. I think I was trying with a std::vector, in case that matters.
No, you can't do that. You need a container that can handle movable-but-not-copyable objects. Not only that, but it needs to handle the thread move emulation.
I was reading in some of the C++0x documents that it's expected that the standard library thread implementation is expected to be able to have this work. The boost documentation doesn't explicitly say whether it should work or not. Is being non-copyable but movable enough to make this work? Or, would an object have to be copyable to be put into an STL container? I thought that was not the case, but.
Non-copyable but movable is indeed enough for a class to be used in a C++0x STL container. I don't know whether the containers with gcc 4.3 have that support in -std=c++0x mode or not. The current trunk has some rvalue reference support in boost::thread, so it may well work, but I haven't tried it.
Wouldn't another option be to create a vector of shared_ptr's of boost::thread objects?? The shared_ptr's work in vectors just fine, plus they provide a convenient way to pass around a non-copyable object like a thread, as well as other thread-pool functions. Cheers, Rick Aurbach, Ph.D. Aurbach & Associates, Inc.