This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Resolved status.
map<K, V>::emplace
and explicit V
constructorsSection: 21.3.8.7 [meta.trans.other] Status: Resolved Submitter: Peter Dimov Opened: 2014-06-12 Last modified: 2015-05-05
Priority: 1
View all other issues in [meta.trans.other].
View all issues with Resolved status.
Discussion:
Please consider the following example:
#include <map> #include <atomic> int main() { std::map<int, std::atomic<int>> map_; map_.emplace(1, 0); // fail map_.emplace(1); // fail map_.emplace(1, {}); // fail map_.emplace(std::piecewise_construct, std::tuple<int>(1), std::tuple<>()); // OK }
The first three calls represent attempts by an ordinary programmer (in which role I appear today) to construct
a map element. Since std::atomic<int>
is non-copyable and immovable, I was naturally drawn to
emplace()
because it constructs in-place and hence doesn't need to copy or move. The logic behind the
attempts was that K=int
would be constructed from '1
', and V=std::atomic<int>
would be
(directly) constructed by '0
', default constructed, or constructed by '{}
'.
map::emplace
or pair
.
Ville:
There exists a related EWG issue for this.
Daniel:
If the proposal N4387 would be accepted, it would solve the first problem mentioned above.
[2015-02, Cologne]
AM: I think Peter's expectation is misguided that the second and third "//fail" cases should work.
DK: Howard's paper [note: which hasn't been written yet] will make the second case work... AM: ...but
the third one will never work without core changes.
[2015-05, Lenexa]
STL: think this is covered with N4387
MC: this was accepted in Cologne
STL: only want to fix the first emplace
MC: leave alone and mark as closed by N4387
Proposed resolution:
Resolved by acceptance of N4387.