Revised 2012-01-17 at 14:01:53 UTC
Section: 23.3.6.3 [vector.capacity] Status: Tentatively Resolved Submitter: Rani Sharoni Opened: 2011-03-29 Last modified: 2012-01-14
View other active issues in [vector.capacity].
View all other issues in [vector.capacity].
Discussion:
In C++1x (N3090) there are two version of vector::resize — 23.3.6.3 [vector.capacity]:
void resize(size_type sz); void resize(size_type sz, const T& c);
The text in 23.3.6.3 [vector.capacity]/12 only mentions "no effects on throw" for the two args version of resize:
Requires: If an exception is thrown other than by the move constructor of a non-CopyConstructible T there are no effects.
This seems like unintentional oversight since resize(size) is semantically the same as resize(size, T()). Additionally, the C++03 standard only specify single version of resize with default for the second argument - 23.2.4:
void resize(size_type sz, T c = T());
Therefore not requiring same guarantees for both version of resize is in fact a regression.
[2011-06-12: Daniel comments]
The proposed resolution for issue 2033 should solve this issue as well.
[ 2011 Bloomington ]
This issue will be resolved by issue 2033, and closed when this issue is applied.
Proposed resolution:
Apply the proposed resolution of issue 2033
Section: 30.6.6 [futures.unique_future] Status: Tentatively Ready Submitter: Daniel Krügler Opened: 2011-11-02 Last modified: 2012-01-14
View all other issues in [futures.unique_future].
View all issues with Tentatively Ready status.
Discussion:
30.6.6 [futures.unique_future] paragraph 15 says the following:
R future::get();
…
-15- Returns:future::get() returns the value stored in the object’s shared state. If the type of the value is MoveAssignable the returned value is moved, otherwise it is copied.
…There are some problems with the description:
"If the type of the value is MoveAssignable the returned value is moved, otherwise it is copied."The last criticism I have is about the part
"the returned value is moved, otherwise it is copied" because an implementation won't be able to recognize what the user-defined type will do during an expression that is prepared by the implementation. I think the wording is intended to allow a move by seeding with an rvalue expression via std::move (or equivalent), else the result will be an effective copy construction.[2011-11-28 Moved to Tentatively Ready after 5 positive votes on c++std-lib.]
Proposed resolution:
This wording is relative to the FDIS.
Change 30.6.6 [futures.unique_future] paragraph 15 as indicated:
R future::get();
…
-15- Returns:future::get() returns the value v stored in the object’s shared
state as std::move(v). If the type of the value is MoveAssignable
the returned value is moved, otherwise it is copied.
Section: 30.6.1 [futures.overview] Status: Tentatively Ready Submitter: Jonathan Wakely Opened: 2011-11-20 Last modified: 2012-01-14
View other active issues in [futures.overview].
View all other issues in [futures.overview].
View all issues with Tentatively Ready status.
Discussion:
30.6.1 [futures.overview] says std::launch is an implementation-defined bitmask type, which would usually mean the implementation can choose whether to define an enumeration type, or a bitset, or an integer type. But in the case of std::launch it's required to be a scoped enumeration type,
enum class launch : unspecified { async = unspecified, deferred = unspecified, implementation-defined };
so what is implementation-defined about it, and what is an implementation supposed to document about its choice?
[2011-12-02 Moved to Tentatively Ready after 6 positive votes on c++std-lib.]
Proposed resolution:
This wording is relative to the FDIS.
Change 30.6.1 [futures.overview] paragraph 2 as indicated:
The enum type launch is
an implementation-defineda bitmask type (17.5.2.1.3 [bitmask.types]) with launch::async and launch::deferred denoting individual bits. [ Note: Implementations can provide bitmasks to specify restrictions on task interaction by functions launched by async() applicable to a corresponding subset of available launch policies. Implementations can extend the behavior of the first overload of async() by adding their extensions to the launch policy under the “as if” rule. — end note ]