0

The following piece of code compiles fine under gcc/clang 

#include <memory>
#include <vector>
#include <unordered_map>

int main() {
    using hash_int_uptr = std::unordered_map<int, std::unique_ptr<int>>;
    std::vector<hash_int_uptr> v;
    v.emplace_back(hash_int_uptr{}); 
}

but fails under MSVC 16.2.1 (2019) _MSC_VER = 19.21 with the error

xmemory(761,1): error C2280: 'std::pair::pair(const std::pair &)': attempting to reference a deleted function

This should be related to the non-copyability of unique_ptr, but I'm trying to create the object in place and move semantics should kick in.

Same error if I simply use v.emplace_back(); or v.emplace_back({});.

Is this a MSVC bug and is there any workaround this?

BTW, the code works fine if I just replace unique_ptr with shared_ptr, or if I simply try to emplace_back only unique_ptrs (and not maps of them).

vsoftco
  • 55,410
  • 12
  • 139
  • 252
  • What happens if you use `v.emplace_back();`? – NathanOliver Aug 19 '19 at 14:05
  • "_but fails under MSVC with the error_" This statement doesn't tell much. Which MSVC version? Since it [compiles fine](https://rextester.com/OVRFDM6504) under MSVC Version 19.00.23506. – Algirdas Preidžius Aug 19 '19 at 14:05
  • Also, which version of MSVS are you using? – NathanOliver Aug 19 '19 at 14:05
  • 1
    "_MSVC 2017/2019_" is not a compiler version. Please elaborate on which compiler version, you are actually using. – Algirdas Preidžius Aug 19 '19 at 14:09
  • Creating a default object to copy from seems unnecessary. Not that removing it helps, but still... – molbdnilo Aug 19 '19 at 14:11
  • @AlgirdasPreidžius See the edit – vsoftco Aug 19 '19 at 14:13
  • 2
    My crystal ball points to `noexcept` being the culprit here. MSVC is/was pretty feisty when it comes to containers vs move semantics. See e.g. https://stackoverflow.com/questions/47604029/move-constructors-of-stl-containers-in-msvc-2017-are-not-marked-as-noexcept (although I don't know whether this is really the same issue). – Max Langhof Aug 19 '19 at 14:13
  • 1
    @vsoftco "See the edit" It's the version of Visual Studio. Not the version of MSVC (MS Visual **Compiler**). – Algirdas Preidžius Aug 19 '19 at 14:15
  • 1
    For the record, here is an answer to the inevitable _"why does MSVC do this?"_/_"is this in agreement with the standard?"_: https://social.msdn.microsoft.com/Forums/vstudio/en-US/f6332282-45e7-4c60-a918-00c8adeaeb71/msvc-2017-compiler-does-not-use-move-constructor-in-stl-containers-if-it-is-not-noexcept-from?forum=vcgeneral – Max Langhof Aug 19 '19 at 14:20
  • 1
    @vsoftco 1) "About" page, wherever I've seen one, shows a version, of application, on which you clicked "about". I doubt you are using the compiler, when you click "about". 2) https://stackoverflow.com/questions/1233312/finding-version-of-microsoft-c-compiler-from-command-line-for-makefiles – Algirdas Preidžius Aug 19 '19 at 14:21
  • 1
    To find the version of the Microsoft compiler, I go to the command line and type `cl /?` (possibly first running `vcvars64.bat` to set up my CMD.EXE shell's environment variables). Mine is version `19.16.27031.1` (which came as part of VS 2017 v15.9.13). – Eljay Aug 19 '19 at 14:23
  • @Eljay Thanks. I also expected that there should be a 1-to-1 correspondence between the IDE version (2019, 16.2.1) and the compiler version. – vsoftco Aug 19 '19 at 14:25
  • It seem to fail with all msvc version: https://godbolt.org/z/v38lE7 – Guillaume Racicot Aug 19 '19 at 14:25
  • @MaxLanghof Thanks, that seems to be the case indeed. – vsoftco Aug 19 '19 at 14:26

0 Answers0