MADNESS 0.10.1
|
Files | |
file | future.h |
Implements Future and related items. | |
Namespaces | |
namespace | madness |
Namespace for all elements and tools of MADNESS. | |
Future
class. Maybe move it here? Hell, I went ahead an copied (cut, really) it here, right here, just for you. A common misconception is that STL containers initialize their contents by invoking the default constructor of each item in the container (since we are told that the items must be default constructable). But this is incorrect. The items are initialized by invoking the copy constructor for each element on a single object made with the default constructor. For futures this is a very bad problem. For instance,
is equivalent to the following with an array of three elements
Since the Future copy constructor is by necessity shallow, each element of v
ends up referring to the future implementation that underlies junk
. When you assign to an element of v
, you'll also be assigning to junk. But since futures are single assignment variables, you can only do that once. Hence, when you assign a second element of v
you'll get a runtime exception.
The fix (other than using arrays) is to initialize STL vectors and other containers from the special element returned by Future<T>::default_initializer()
, which if passed into the copy constructor will cause it to behave just like the default constructor. Thus, the following code is what you actually need to use an STL vector of futures
which is laborious. Instead, we provide the factory function
which enables you to write