为什么在传递给异步时从默认构造函数调用移动构造函数？

Question

i have a class like this:

class move_only
{
public:
    int valut;
    move_only() {}
    move_only(move_only&&);
    void operator()();
};

move_only::move_only(move_only&&)
{
    cout << "here";
}

void move_only::operator()()
{
}

i wonder why when you call:

auto flow = std::async(move_only());

first called

move_only() 

(which is understandable), but why then:

move_only(move_only&&);

and only then

void move_only::operator()

I will be glad to help, thank

Answer 1

The backtrace of gcc 10.2 at the moment the move constructor is invoked:

1 move_only::move_only
2 std::_Head_base<0ul, move_only, false>::_Head_base<move_only>
3 std::_Tuple_impl<0ul, move_only>::_Tuple_impl<move_only>
4 std::tuple<move_only>::tuple<move_only, true, true>
5 std::thread::__make_invoker<move_only>
6 std::async<move_only>
7 std::async<move_only>
8 main

Please note how move_only , the name of your class, is smoothly transferred 6 levels of indirection to the point where it is really needed!

Let's work this backtrace out, in reverse order:

1. main calls async - that's what we can see. The rest the implementation
2. async calls itself with a proper execution policy explicitly given as an argument
3. async is a friend to future and calls __future_base::_S_make_async_state to create a __state , which is a shared pointer that will be used by async to create a future . We don't see _S_make_async_state - it is a trivial function and perhaps gcc has inlined it even in Debug miode, this is a bit weird.
4. The first argument of _S_make_async_state is of type std::tuple . It is generated by std::thread::__make_invoker
5. std::tuple inherits publicly from _Tuple_impl
6. _Tuple_impl inherits privately from _Head_base
7. _Head_base has a data member _M_head_impl , of type _Head :

   _Head _M_head_impl;

Please notice that apparently this member is embedded "by value" - we can see no evidence of pointer, * , reference, ' & , etc. But this is C++, these might be hidden in the definition of _Head . But when we look at the backtrace, we can identify _Head with your class name, move_only . Hurray!

This data member is constructed in this line:

_M_head_impl(std::forward<_UHead>(__h))

Here, std::forward provides the perfect forwarding of your function or function object: if you use an r-value as the argument, the constructor of _Head_base will have this information passed all the way from your main . No references, no pointers - the member will be constructed by value. But since it is being constructed from a temporary object and the move constructor is available, the move constructor will be used here. The mystery is solved.

The really big question is this: is this call to move constructor guaranteed by the standard or is it an implementation "detail"? Since C++ sports a feature like guaranteed or just optional copy elision, one should write the constructors in such a way that they have no side effects and it should not matter whether an object is copied, moved or "copy-elised".

The next question: how can I guess, given the signature of std::async , that the function object will be copied, moved or passed by reference? Let's see:

std::future<std::result_of_t<std::decay_t<Function>(std::decay_t<Args>...)>>
    async( Function&& f, Args&&... args );

This may be confusing at first, for clearly, without doubt, std::async accepts all its parameters by reference and no move constructor can be called here . But can it be called elsewhere?

One hint is perfect forwarding seen in && applied to arguments with a type deduced from a template parameter. In particular, f is being passed by perfect forwarding. If anyone uses perfect forwarding, they want to keep the information whether the argument is an l- or r-value, so be prepared for invocation of a copy or move constructor somewhere . The second hint is purely logical. std::async is supposed to be rock-solid, safe means of using multithreading. If it is to be safe, it must do literally everything to obtain all its arguments by value. If they were passed by reference or pointer, the parameters passed to a function called asynchronously may cease to exist long before this function returns. In this case the function parameter would at some point of time turn into rubbish and the function would have no clue as to when. So, you should expect that by default all arguments to std::async are effectively (and perhaps indirectly ) passed by value, and keep your fingers crossed that the implementation is so smart that it can actually move them whenever it is legitimate to do so.