3. VC11 Compiler

VC11 Compiler

  • C

    😮 Nett. Aber es wird eigentlich noch witziger wenn man die Story dazu kennt. Microsoft hat scheinbar erfragt welches C++11 Feature wohl am beliebtesten sei und ist dann auf variadic Templates gekommen. Dann haben sie versucht das zu implementieren, aber sind wohl leicht an der Performance gescheitert. Und jetzt haben sie mit VS11 weder variadic Templates, noch viele kleine andere Features. Aber angeblich soll das ja nachgeliefert werden. 😃

    0
  • J

    Tja, bleibt die Frage, wie ich das mit dem VC-Compiler umschiffen kann. Ich suche eigentlich eine Lösung ohne Smart Pointer, da ich die Rvalue-Referenzen da sehr mag. Hat jemand 'ne Idee?

    0
  • K

    Erklär doch mal, warum Du überhaupt eine Rvalue-Referenz verwendest. Das sieht nämlich ein bissel komisch aus. Vielleicht kann man das wirklich ganz anders besser lösen.

    0
  • ?

    Mit Lambdas lässt sich std::bind oft vermeiden.
    Unabhängig von deinem Problem, leitet std::bind die gebundenen Argumente nur als lvalues weiter, daher passen die Move-Sematik und std::bind nicht so gut zusammen.

    #include <iostream>
#include <functional>

void innerfun(int a, int&& b)
{
 std::cout << a << " " << b << '\n';
}

template <typename Callable>
void outerfun(Callable && c)
{
 c(12);
}

int main()
{
 outerfun([](int i){ innerfun(11,std::move(i));});
 return 0;
}
    0
  • J

    krümelkacker schrieb:

    Erklär doch mal, warum Du überhaupt eine Rvalue-Referenz verwendest. Das sieht nämlich ein bissel komisch aus. Vielleicht kann man das wirklich ganz anders besser lösen.

    z.B. für eine Callback-Funktion nach einem Socket-accept(). Der neue, nicht-kopierbare Socket soll der Funktion als Parameter übergeben werden.

    @ einwurf:
    Sieht interessant aus, das schau ich mir mal an, danke! Es müsste für std::bind neben std::ref() und std::cref() auch ein std::rref() oder so geben, dann würde es klappen, oder?

    0
  • J

    Hehe, ich sah gerade:
    http://channel9.msdn.com/shows/Going+Deep/Stephan-T-Lavavej-Everything-you-ever-wanted-to-know-about-nullptr/

    Der Herr (dessen Initialisien S.T.L. sind :D) implementiert die STL für MS. Und er sagt, dass er in den Hungerstreik gehen will, falls Variadic Templates nach VS10 nicht implementiert werden. Ich wette, er ist verhungert.

    0
  • N

    Visual Studio 2011 ist ja noch nicht offiziell erschienen, oder? Ist denn definitiv, dass die endgültige Version (wird die immer noch 2011 heissen?) keine Variadic Templates haben wird?

    0
  • K

    Jodocus schrieb:

    z.B. für eine Callback-Funktion nach einem Socket-accept(). Der neue, nicht-kopierbare Socket soll der Funktion als Parameter übergeben werden.

    Und was macht die damit? Warum ist es ein Rvalue-Referenzparameter? Das hast Du immer noch nicht verraten. 🙂

    Jodocus schrieb:

    Es müsste [...] neben std::ref() und std::cref() auch ein std::rref() oder so geben, dann würde es klappen, oder?

    Killefit.

    Das riecht echt nach Rvalue-Referenz-Fehlbenutzung alles.

    Zeig mal mehr Code. Erklär mal mehr.

    0
  • J

    > Und was macht die damit? Warum ist es ein Rvalue-Referenzparameter? Das hast Du immer noch nicht verraten.

    Es ist ein Rvalue-Referenzparameter, weil der Socket innerhalb der Library erstellt wird und dem User zur Verfügung gestellt werden soll, sprich auch außerhalb der Library verwendet werden muss. Hier die Optionen:

    Kopieren: Unmöglich, da einzigartige Resource und Desaster beim Multithreading, wenn die Resource freigegeben wird.

    Referenz: Das bedeutet, dass die Library selbst die Ressourcen speichern muss und dem Client lediglich Referenzen darauf gibt. Allerdings gibt's dann keine Chance die Ressource zeitnah wieder freizugeben, es sei denn, man teilt es der Library explizit mit (á la delete_resource(...) ) und das wäre recht hässlich.

    Pointer: Zu hässlich. Nicht exceptionsicher.

    Smart-Pointer: Bisherige Lösung. Einzig der shared_ptr<> funktioniert damit erfolgreich, da er kopiert werden kann, dabei aber die Resource nicht kopiert. Als Notlösung wollte ich unique_ptr verwenden, da ein shared_ptr<> eigentlich nicht ganz das ausdrückt, was ich will. Aber der kann dank Rvalue-Referenz-Bugs auch nicht benutzt werden.

    Rvalue-Referenzen: Eleganteste Methode. Die Library erstellt die Resource, gibt sie per Move an den Client als Stackvariable und räumt sich von alleine auf, wenn sie nicht mehr gebraucht wird. Leider dank Visual Studio Bugs nicht möglich.

    Edit: @ Nexus: Sie versprachen noch vor der Veröffentlichung von VS 2010, dass Variadic Templates auf Platz 1 der Prioritätsliste sitzt, aber schafften es für VS 10 nicht. Nun ist das erste VS 11 da und die Variadics sind wieder nicht dabei. Siehe: http://connect.microsoft.com/VisualStudio/feedback/details/463677/support-variadic-templates
    Intern heißt es wohl, dass sie es wieder und wieder versucht haben, aber daran scheiterten. Wenn es Intel und GCC schaffen, wieso sollte es MS nicht hinbekommen?
    Bzgl. dem VS-Namen: Dass Visual Studio 10.0 auf das Jahr 2010 fiel, ist Zufall. 10 ist die Versionsname, 2010 der Produktname. Das nächste VS wird definitiv die Version 11.0 sein, als Produktname rate ich 2012 - mit der Veröffentlichung von Windows 8.

    0
  • C

    Jodocus schrieb:

    Kopieren: Unmöglich, da einzigartige Resource und Desaster beim Multithreading, wenn die Resource freigegeben wird.

    Verstehe ich immer noch nicht so ganz:

    void foo(Socket socket)
{
}

int main()
{
  Socket socket;
  foo(std::move(socket));
}

    Warum funktioniert das Vorgehen bei dir nicht?

    0
  • J

    Nene cooky, so einfach ist das nicht. 😉
    Es handelt sich dabei um einen asynchronen Callback. Der kommt sogar aus einem anderen Thread. Das Ziel ist das:

    void callback(socket&& sock) {
 // bla
}

int main() {
  start_accept(callback);
}
    0
Anmelden zum Antworten