Problem z std::future i Qt

Witam, przy próbie wykoania takiego zabiegu:

auto request = std::async(std::launch::async,&SoftwareManagement::isUpdateAvaible,this,url,responseMessage);

Przy czym metoda wygląda tak:

bool SoftwareManagement::isUpdateAvaible(QUrl &&url, QJsonObject &&response)

Podczas budowania dostaję następujący

error: no matching function for call to 'async(std::launch, bool (SoftwareManagement::*)(QUrl&&, QJsonObject&&), SoftwareManagement*, QUrl&, QJsonObject&)'
     auto request = std::async(std::launch::async,&SoftwareManagement::isUpdateAvaible,this,url,responseMessage);                                                                                                          
C:/Qt/Tools/mingw530_32/i686-w64-mingw32/include/c++/future:1703:5: note: candidate: template<class _Fn, class ... _Args> std::future<typename std::result_of<_Functor(_ArgTypes ...)>::type> std::async(std::launch, _Fn&&, _Args&& ...)
     async(launch __policy, _Fn&& __fn, _Args&&... __args)

Nie mogę jakoś albo wyczuć, albo zrozumieć jak tego używać. Potrzebna pomoc.

Problem wydaje się leżeć w std::async, a nie w std::future - tą zwracaną wartość łapiesz przez auto i nie widzę tu nic złego...
Bardziej wydaje mi się, że problem leży w tym fragmencie: ,&SoftwareManagement::isUpdateAvaible,this,url,

Chyba niepotrzebnie podajesz tutaj this. Rozumiem czemu chcesz to zrobić, bo podajesz wywoływaną metodę konkretnej klasy, więc przekazujesz wskaźnik na obiekt, z którego będzie metoda wywołana. To jest OK. Ale przecież std::async ma składnię:
async(launch __policy, _Fn&& __fn, _Args&&... __args)
a argumenty __args tyczą się jedynie __fn, więc wygląda na to, że Ty próbujesz wrzucić this jako argument SoftwareManagement::isUpdateAvaible.

Może powinieneś spróbować załatwić to lambdą? Niech ona przechwytuje this?

Usunąłem this:

C:/Qt/Tools/mingw530_32/i686-w64-mingw32/include/c++/future:1703:5: error: no type named 'type' in 'class std::result_of<bool (SoftwareManagement::*(QUrl&, QJsonObject&))(QUrl&&, QJsonObject&&)>'
C:/Qt/Tools/mingw530_32/i686-w64-mingw32/include/c++/future:1723:5: note: candidate: template<class _Fn, class ... _Args> std::future<typename std::result_of<_Functor(_ArgTypes ...)>::type> std::async(_Fn&&, _Args&& ...)
     async(_Fn&& __fn, _Args&&... __args)

Jeżeli pokusiłbym się na lambdę, to powinno to wyglądać mniej więcej tak:

std::async(std::launch::async,[&](){SoftwareManagement::isUpdateAvaible(url,responseMessage)};

?

spróbuj tak:

auto request = std::async(std::launch::async,&SoftwareManagement::isUpdateAvaible, this, std::move(url), std::move(responseMessage));

Albo nie używaj move schematics w SoftwareManagement::isUpdateAvaible

Zresztą nazwy wskazują, że coś jest totalnie pomieszane.
Brakuje kontestu by powiedzieć co.

Swoją drogą: wiem, że wielowątkowość jest teraz modna i trzeba nią zaszpanować, ale coś mi się wydaje, że w tym miejscu używasz jej na siłę (niepotrzebnie).

Dzięki, działa.
Pytanie: czy jak będę chciał tam użyć referncji jako argumentu, to move, też pomoże?

W sensie taki scenariusz:
vector<Class> vec;
Class & ref = vec[i]

auto request = std::async(std::async,&SoftwareManagement::isUpdateAvaible, this, std::move(ref), std::move(responseMessage));

UPDATE:

Lambda pomogła, bo sposób @MarekR22 (pewnie moja zła implementacja) gubił wartość po opuszczeniu isUpdateAvaible

BartoSAS napisał(a):

Lambda pomogła, bo sposób @MarekR22 (pewnie moja zła implementacja) gubił wartość po opuszczeniu isUpdateAvaible

To było dla mnie oczywiste, ale jak pisałem brak kontekstu i nazwy, które sugerują że robisz coś źle.
A problemem nie jest "mój sposób" tylko fakt, że isUpdateAvaible używa move schematics.
Najwyraźniej nie rozumiesz co robi && w argumencie funkcji, ale widzisz modę na to, więc używasz.
Wygląda na to, że praktykujesz programowanie permutacyjne (metoda prób i błędów). Musisz się tego oduczyć i zrozumieć najpierw naturę problemu przed próba naprawienia.

No tak. Nie powiedziałem, że Twoje rozwiązanie to problem (a jeżeli tak wynika, to niechcący).
Nie wiem, czy to modne, czy nie. Po prostu szukam rozwiązania, a że akurat trafiłem na takie (posiłkowanie się S. Mayersem).
To że akurat jest możliwość zrobienia wygodniejszy sposób poprzez future i async niż zabawa z mtuxami, to chyba też jeszcze nie tragedia.
Człowiek się naczyta i po prostu czasem jest potrzeba weryfikacji z bardziej doświadczonym. Przecież jakbym wiedział tak na 100%, to bym nie zakładał tematu.

BartoSAS napisał(a):

Lambda pomogła, bo sposób @MarekR22 (pewnie moja zła implementacja) gubił wartość po opuszczeniu isUpdateAvaible

Sam sobie zażyczyłeś, żeby funkcja 'kradła' argumenty stosując tam &&. Dla mnie to trochę z czapy, czym to jest podyktowane? ;)

MarekR22 napisał(a):

Wygląda na to, że praktykujesz programowanie permutacyjne (metoda prób i błędów). Musisz się tego oduczyć i zrozumieć najpierw naturę problemu przed próba naprawienia.

Coś czuję, że to trafna diagnoza. Ciekawe ile zajmie "kuracja" :/

@tajny_agent - człowiek się naczytał o "odwołaniach uniwersalnych / forwarding references" i może stąd :/