How to fix the error 'a failure of specialization of function template' (multithreading)?

The project itself is large, so lay out the fragments that are associated with streams.
// In the Declaration of the first class
private:
std::thread firstClassThread;
int run();

// The constructor of this class
FirstClass::FirstClass() : /* initializer list */ firstClassThread(run()) { }

// Use stream
switch (received_data) {
 case FIRST_CONST:
 // ...
firstClassThread.detach();
break;

 case SECOND_CONST:
 if (/* logical condition */) {
 // ...
SuspendThread(firstClassThread.native_handle());
}
 else if (/* logical condition */) {
 // ...
ResumeThread(firstClassThread.native_handle());
}
break;
}

// Second class, which aggregates in itself FirstClass
// in the Declaration
private:
int someFunc(const int& data);

// In one of the public methods of this second class
std::thread someFuncThread(someFunc(data), data);
someFuncThread.detach();
 Sleep(duration);


In the end, I get these two errors:
  1. "std::invoke": no matching overloaded function
  2. A failure of specialization of a function template "unknown-type std::invoke(_Callable &&,_Types &&...)"


First time working with multithreading. Can help to fix these errors?
July 2nd 19 at 13:49
2 answers
July 2nd 19 at 13:51
Solution
en.cppreference.com/w/cpp/thread/thread/thread

int run(); // Is of type `int (FirstClass::*)()`. And the constructor of `std::thread` is needed, or a functor, or a global function.


Rewrite `run()` static and pass the object instance `FirstClass` parameter at startup.
another solution is to use a lambda with a closure on this.
FirstClass::FirstClass() : /* initializer list */ firstClassThread([this](){ run(); }) { }


Keep in mind that the flow will start immediately after the completion of the constructor `std::thread`.

en.cppreference.com/w/cpp/thread/thread
Threads begin execution immediately upon construction of the associated thread object (pending any OS scheduling delays), starting at the top-level function provided as a constructor argument.

Literally, the thread runs immediately after construction.

en.cppreference.com/w/cpp/thread/thread/detach
Separates the thread of execution from the thread object, allowing execution to continue independently.

But `detach` it from the stream or by the stream, does it only reset the state of the stream object, breaks the connection between the stream object and the stream.

Maybe you need some other way to start a thread, at another time? If you had to start a thread at other times, it's time to design.
Yes, to another. Isn't the detach() method runs? How, then, to cancel the run after the constructor? - Horace.Legros75 commented on July 2nd 19 at 13:54
+Can't make these methods static because they use the field object that calls this method. - Horace.Legros75 commented on July 2nd 19 at 13:57
July 2nd 19 at 13:53
Solution
Everything becomes easier with lambdas:

// Was
std::thread someFuncThread(someFunc(data), data);
// Was
std::thread someFuncThread([this, data] { return this->someFunc(data); });

It will be similar elsewhere. Remember:
  1. this is also necessary to capture, and not to avoid calling the method without this, that is, as someFunc(data)
  2. It's your problem to ensure that at the time of the call object *this "alive"
  3. here data is captured by value. If the amount of data is large and you can guarantee their life time, then grab the link: [this, &data]

Upd As to postpone the launch:
std::thread someFuncThread;
//...
someFuncThread = std::thread( condemnations );
What to do to make the stream does not start immediately after the constructor? (to only run detach method) - Horace.Legros75 commented on July 2nd 19 at 13:56
:
this is captured by reference.

Correction... en.cppreference.com/w/cpp/language/lambda
[this] captures the this pointer by value


Circuit protection for all work in the same way. :) - Horace.Legros75 commented on July 2nd 19 at 13:59
: The pointer-that zahvatite by value, but if we are talking about the current object *this, he zahvatite by reference (copy). In C++17 appeared "real" capture *this is the value: [*this] - Horace.Legros75 commented on July 2nd 19 at 14:02
the sources are always welcome. :)

en.cppreference.com/w/cpp/language/lambda
The capture-list is a comma-separated list of zero or more captures, optionally beginning with the capture-default. The only capture defaults are & (implicitly catch the odr-used automatic variables and *this by reference) and = (implicitly catch the odr-used automatic variables implicitly by copy and catch *this by reference if it is odr-used).

I.e. only in the case of Autolock. Ibid., 8-m number, all written in about the 17th standard and capture the value. It's all clear.

Is it possible to make a circuit to *this in 11m/14m standard? O_o
cpp.sh/2cxhl

Only After my clarification it's not true. You have in the sample capture is for the this pointer, and below is written that this grabs the link. Only this little point needs to be clarified. - Benjamin_McClure commented on July 2nd 19 at 14:05
: how to solve the error when calling " SuspendThread(firstClassThread.native_handle());": this was a nullptr? - kenyatta commented on July 2nd 19 at 14:08
as I understand it, the SuspendThread function is taken from the WinAPI?
If so, then `native_handle()` from `std::thread` will store the HANDLE of the stream, cast to void*.
Source: https://msdn.microsoft.com/en-us/library/hh920601....

Consequently, nullptr, there can be two cases that are essentially the same:
1 - the thread object has not been initialized;
2 - the thread object has been unbound from the thread - thread.detach().

In any of these cases, the stream object is not associated with the real flow.
So the output is, perhaps, the detach must be done in a different time. And maybe it is not worth doing? - Benjamin_McClure commented on July 2nd 19 at 14:11
and in General... it's all scary stuff. Why you want to euthanize flows?
You do realize that a thread can be put to sleep in the middle of performing some operation with the data or the object?
It's a terrible thing, from which the hair stand on end. :) - Horace.Legros75 commented on July 2nd 19 at 14:14
thanks, solved the problem) - Benjamin_McClure commented on July 2nd 19 at 14:17
: I confess. I've always talked about [this] as the seizure of the link, especially in light of the fact that [&this] no. But standard will not argue, corrected. - Benjamin_McClure commented on July 2nd 19 at 14:20

Find more questions by tags C++