https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68784
--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Wang Xuancong from comment #2)
> All standards are made by people. No standard is perfect. If a standard
> causes more inconvenience to the users, then it is considered sub-optimal
> and has room for improvement.
The behaviour mandated by the standard is by design, it is not a defect.
> Thus, unless you can give me a counter example that automatic parameter
> resolution can cause problems in some cases, I would consider the standard
> is not good enough, and will probably be fixed in some future C++ standards.
GCC's Bugzilla is not the right place to learn how C++ works.
It has nothing to do with deduction or "automatic parameter resolution", the
error is because you cannot bind a non-const reference to an rvalue, similar to
calling:
thread_add(unordered_map<int, int>(), 0, 9);
This fails because you can't bind a temporary to the reference parameter (MSVC
gets this right).
The standard requires std::thread to copy its arguments for safety reasons, to
avoid silently forming dangling references to stack variables, MSVC gets that
part right too. If you want a reference you must request it explicitly.
If you actually run your program after compiling it with MSVC you will see it
prints:
size: 0
because 'ht' is never modified, because the threads insert into *copies* of the
map, not the original. So even with MSVC your program doesn't do what you think
it does. The standard requires you to use std::ref if you really want to create
a thread with a reference to your variable.
The standard also requires the copied arguments to be forwarded as rvalues, to
avoid surprising behaviour due to functions that take references modifying
copies not the original objects. MSVC gets this wrong, and allows the copies to
bind to lvalue reference parameters, and then your new threads modify the
copies not the original, even though you think you've bound a reference.
> But since g++ is indeed following the standard, it should not be considered
> as a bug for now, formally speaking.
It's not a bug in any sense at all. The bug is in MSVC, I suggest you discuss
it with Microsoft.
