This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++11 status.

2027. Initialization of the stored task of a packaged_task

Section: 33.10.10.2 [futures.task.members] Status: C++11 Submitter: Alberto Ganesh Barbati Opened: 2011-02-09 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [futures.task.members].

View all issues with C++11 status.

Discussion:

Related with LWG issue 1514.

The move constructor of packaged_task does not specify how the stored task is constructed. The obvious way is to move-construct it using the task stored in the argument. Moreover, the constructor should be provided with a throws clause similar to one used for the other constructors, as the move constructor of the stored task is not required to be nothrow.

As for the other constructors, the terms "stores a copy of f" do not reflect the intent, which is to allow f to be moved when possible.

[2011-02-25: Alberto updates wording]

[2011-02-26 Reflector discussion]

Moved to Tentatively Ready after 5 votes.

Proposed resolution:

(wording written assuming LWG 1514 is also accepted)

1. Change 33.10.10.2 [futures.task.members] paragraph 3:

   3 Effects: constructs a new packaged_task object with an associated asynchronous state and stores a copy of f as the object's stored taskinitializes the object's stored task with std::forward<F>(f). The constructors that take an Allocator argument use it to allocate memory needed to store the internal data structures.

2. Change 33.10.10.2 [futures.task.members] paragraph 5:

   5 Effects: constructs a new packaged_task object and transfers ownership of other's associated asynchronous state to *this, leaving other with no associated asynchronous state. Moves the stored task from other to *this.