3. Async und move-only Typen

Async und move-only Typen

  • K

    Hi! Kurze Frage. Ich fürchte, dass mein g++ (4.6.3) und die aktuell bei installierte libstdc++ da etwas buggy ist; denn laut Standard (bzw meiner Interpretation) müsste ich das hier doch kompiliert bekommen, oder?

    #include <future>
#include <memory>

void foo(std::unique_ptr<int>)
{
}

int main()
{
   std::unique_ptr<int> p (new int(42));
   auto f = std::async(foo,move(p));
   f.get();
}

    Bei mir will das nicht. Quasi endlos viele Fehlermeldungen vom Compiler -- habe da auch etwas mit const tuple<...> entdeckt, was mich glauben lässt, dass libstdc++ da was zu kopieren versucht, was nicht zu kopieren ist -- unique_ptr ist ja move-only.

    Laut meiner Interpretation des Standards müsste das aber so klappen und der unique_ptr müsste "korrekt geforwarded" werden, also zumindest als rvalue, da ja DECAY_COPY ein rvalue in diesem Fall zurück gibt. Liege ich da falsch oder richtig?

    0

  • Probier den Code mal mit nem anderen Compiler (über ideone.com oder so).

    0
  • N

    hustbaer schrieb:

    Probier den Code mal mit nem anderen Compiler (über ideone.com oder so).

    Bei ideone kompiliert es, es gibt aber ne Exception, weil dort kein Threading unterstützt wird. Die Frage ist jetzt, ob async jetzt wirklich das alles ausführt mit moven, wo der Fehler auftritt, oder direkt eine Exception wirft.
    Edit: Und bei meinem gcc 4.8.1 auch, also liegts wohl am Compiler.

    0

  • Vermutlich an der Standardlibrary Implementierung.

    0
  • C

    VS2013:
    error C2280: 'std::unique_ptr<int,std::default_delete<_Ty>>::unique_ptr(const std::unique_ptr<_Ty,std::default_delete<_Ty>> &)' : attempting to reference a deleted function : c:\program files (x86)\microsoft visual studio 12.0\vc\include\functional : 1112

    0
  • N

    hustbaer schrieb:

    Vermutlich an der Standardlibrary Implementierung.

    Ja, Compiler, Standardimplementierung, IDE,... alles dasselbe. 😉

    0
  • K

    ok, wenn es also bei neueren Versionen funktioniert, gehe ich mal davon aus, dass die alte Version diesbezüglich buggy ist und dass meine Interpretation richtig ist.

    Danke.

    0
  • Mod

    Das ist natürlich konform; async forwarded bzw. moved alle Argumente. Mein GCC 4.8.1 (wie der Nathans) führt es vollständig fehlerfrei aus.
    Was passiert, wenn du als Launch-Policy nur async angibst?

    Edit: Ein wenig zu spät.... :p

    0
  • ?

    Die Implementation der stdlibc++ ist völlig konform: Alle Argumente in ein Tupel reinmoven zum Zwischenspeichern und dann über das Tupel die Argumente forwarden. Dafür brauchts halt rvalue-References auf *this, was der GCC 4.6.3 offensichtlich noch nicht unterstützt.

    0
  • K

    aergds schrieb:

    Dafür brauchts halt rvalue-References auf *this, was der GCC 4.6.3 offensichtlich noch nicht unterstützt.

    Ich bin mir ziemlich sicher, dass man das dafür nicht braucht. 🙂

    0
Anmelden zum Antworten