custom allocator using move for vector of thread

Question

I'm currently learning about concurrency in C++ and came across using a vector of threads, which I believe will be possible in C++0x. However, my current compiler doesn't appear to have an implementation of move-aware containers and so I get errors generated because std::thread::thread(const std::thread&) is deleted, ie I can only use the move constructor/move assignment with std::thread.

Am I correct in thinking I could circumvent this issue by writing a custom allocator using

void MyAllocator::construct (pointer p, reference val)
/* should be non-const reference to val because using move constructor? */
{
    new ((void*)p) T (std::move(val));
}

rather than

void allocator::construct (pointer p, const_reference val)
{
    new ((void*)p) T (val);
}

? Or some other variation on this theme (possibly using an overload of MyAllocator::construct).

NB: This is mainly intended to be a short-term educational exercise and well enough performing work around to play around with threads in containers. I'd only be using MyAllocator in this context. However, please also point me at any libraries that may have this implemented so I can have a poke around the source.

Answer 1

The easiest way to circumvent the problem would be to allocate the threads on the heap and manipulate pointers to them.

Check the Boost Pointer Container library: boost::ptr_vector<std::thread> seems to me what you are looking for.

Answer 2

The requirement that std containers only take copyable objects has more to do with the C++03 container interfaces than it does with the allocator implementation. For example

vector<T> b(100);
vector<T> a;
a=b;
assert(a==b);

The standard assures us a==b is true. However, if T were not copyable, then in the best case a=b will not compile, in the worst a=b is undefined. Furthermore,

a.push_back(T());

may cause a to allocate new space, and under the hood there are copies made to the new underlying storage from the old.

Furthermore, there is nothing in the C++03 standard that says an implementation actually has to call allocator.construct, and in fact many (gcc for example) do not.

The C++0x standard adds new member functions to the container interface for moveable types, and clarifies how things like operator= behave in their presence.

See www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2486.pdf

Answer 3

If your compiler doesn't provide a move-aware std::vector then you'll have to write your own specialization of std::vector<std::thread> rather than just provide a custom allocator. The whole C++03 vector interface relies on copying: push_back() copies elements in; resize() initializes the empty elements with a copy of the element passed as the second parameter (even if that is the default value of T()); resize(), reserve(), insert(), erase() and push_back() will copy elements if the vector needs reallocating, or elements otherwise need moving around, and so forth.

This is such a common problem that I've included such a specialization with my (commercial) just::thread implementation of std::thread.