Was fehlt in C++11?



  • Irgendwer schrieb:

    Und an {} innerhalb eines Ausdrucks ist auch schon klar genug gemacht, daß jetzt Code kommt.

    sort(vec,{l.z<r.z;});

    Gäbe das nicht ein Problem mit Initialisierungslisten? Schließlich könnte eine Funktion ja auch eine Überladung haben, die als zweiten Parameter ein Objekt übergeben bekommt, das mittels einer std::initializer_list konstruiert wird.

    Solcherlei Probleme hat man in C++ dauernd, und das zeigt nicht nur, dass die Sprache alt ist sondern auch, dass sie syntaxmäßig viel zu alt ist. Alleine auch schon der Mehraufwand um für C++ IDE-Features wie Refactoring umzusetzen ist erheblich höher als bei modernen Sprachen (im Sinne der Syntax) wie Java oder C#.

    MfG SideWinder



  • volkard schrieb:

    #C++-.

    Damit ist aber der Gag im Namen weg. Ich wäre für C#er++ 😃



  • Bin ich der einzige, der solche Container vermisst? 😮



  • SideWinder schrieb:

    Alleine auch schon der Mehraufwand um für C++ IDE-Features wie Refactoring umzusetzen ist erheblich höher als bei modernen Sprachen (im Sinne der Syntax) wie Java oder C#.

    Das liegt aber eher daran, dass die Sprache semantisch viel komplexer ist, oder? Alleine schon die ganzen Templates (welche einen grossen Teil der Standardbibliothek ausmachen), die Trennung von Deklaration und Definition, Zeiger, Referenzen, const , ... Syntaktisch ist C++ recht ähnlich wie Java oder C#, zumindest wenn man "ganz normal" (ohne Metaprogrammierung etc.) programmiert.

    Ich finde es langsam Zeit für Pointer-Container, auch wenn mir Boosts Umsetzung nicht wahnsinnig gefällt. Es gibt zwar jetzt unique_ptr , aber damit hat man keine Kopiersemantik.



  • Echte eingebaute Tupel wären toll. Nur welche Klammern soll man dafür nehmen?

    volkard schrieb:

    #C++-

    Man müsste eine Art neues C++ schaffen, das per Compiler einfach zu C++0x konvertiert wird. Sachen wie R-Value-Referenzen sind imo zu "intern", das sollte automatisch gemacht werden.



  • fdfdg schrieb:

    Sachen wie R-Value-Referenzen sind imo zu "intern", das sollte automatisch gemacht werden.

    C++11 hat implizite Move-Semantik, in einigen Fällen mit unnötigen Kopien kann automatisch der Move-Konstruktor aufgerufen werden. Und der Move-Konstruktor kann wiederum automatisch vom Compiler generiert werden.



  • volkard schrieb:

    Statische Destruktoren? Erkläre mal. Ist das, wenn man vor den Destruktor nicht virtual schreibt?
    Statische Konstruktoren? Erkläre mal. Ist das, wenn man ein Objekt erzeugen will, dessen Typ man zur Compilezeit kennt?

    ipsec schrieb:

    Ich glaube er meint damit ein ähnliches Konzept wie in C#: der statische Konstruktor jeder Klasse wird zum Programmbeginn aufgerufen (seine Aufgabe ist, statische Member der Klasse zu initialisieren), entsprechend räumt der Destruktor am Ende des Programms die statischen Member wieder auf.

    Wie ipsec schon geschrieben hat, möchte ich wie in C# die Möglichkeit haben statische Konstruktoren bzw. Destructoren zu verwenden. Ne gescheite (evtl. optionale) RTTI implementierung wäre auch nicht verkehrt. Damit wäre C++ perfekt für mich. Aber angeblich lässt sich ja beides nicht mit C++ umsetzen. Vielleicht will man aber auch einfach nicht. Sehr schade.



  • Ich seh nicht warum man in C++ statische Konstruktoren brauchen würde, das Problem das in C# damit gelöst wird gibts in C++ doch nicht!?



  • Ich sehe nicht, dass die RTTI-Möglichkeiten in C++ nicht "gescheit" sind.



  • @StellerFragen: Vielleicht willst du so etwas? (ist halt nur ein Nachbau, ungetestet)

    //MyClass.h
    
    class MyClass
    {
        class StaticRAII
        {
            public:
            Initializer()
            {
                MyClass::res.request();
            }
            ~Initializer()
            {
                MyClass::res.release();
            }
        };
        static resource res;
    };
    
    //MyClass.cpp
    MyClass::StaticRAII MyClass_static_raii;
    


  • ipsec schrieb:

    Ich sehe nicht, dass die RTTI-Möglichkeiten in C++ nicht "gescheit" sind.

    Das sehe ich schon.
    Aber sobald man sich

    if(Derived* d=dynamic_cast<Derived>(base))
       d->flyLikeADerived();
    

    und

    if(typeid(base)==typeid(Derived))
       static_cast<Derived*>(base)->flyLikeADerived();
    

    abgewöhnt hat, braucht man RTTI nur noch unglaublich selten.



  • Ich denk sowas sollte man sich besser garnicht angewöhnen :p

    Abgesehen davon verwendest du da oben doch RTTI!?



  • dot schrieb:

    Abgesehen davon verwendest du da oben doch RTTI!?

    Ja, in der Anfänger-Parodie. Selber nehme ich natürlich den Profitrick mit dem Wort virtual.



  • Interessant, dass noch niemand Reflection und Garbage Collector erwähnt hat... Wäre wohl anders, wenn dieses Thema in Rund um die Programmierung eröffnet worden wäre 😉



  • Nexus schrieb:

    Interessant, dass noch niemand Reflection und Garbage Collector erwähnt hat...

    Wer würde denn sowas wollen :p (wobei: Mit "gescheiter RTTI Implementiertung" war wohl ersteres gemeint)

    volkard schrieb:

    dot schrieb:

    Abgesehen davon verwendest du da oben doch RTTI!?

    Ja, in der Anfänger-Parodie. Selber nehme ich natürlich den Profitrick mit dem Wort virtual.

    Ah ok sry, war mir nicht sicher wies gemeint war. Hätt mich aber auch irgendwie ziemlich gewundert 😉



  • Nexus schrieb:

    Interessant, dass noch niemand Reflection und Garbage Collector erwähnt hat... Wäre wohl anders, wenn dieses Thema in Rund um die Programmierung eröffnet worden wäre 😉

    Nagut. Mit Reflection geht's auch, wenn man sich ein wenig Mühe gibt.

    if(auto mf=Reflector(base)->getMemFun("flyLikeADerived"))
       if(mf->parameterlist.count()==0 && mf->returntype().name()=="void")
         static_cast<Derived>(base)->flyLikeADerived();
    


  • Nexus schrieb:

    Interessant, dass noch niemand Reflection und Garbage Collector erwähnt hat

    Jetzt wo dus erwähnst.. Runtimereflection und GC hat für mich mehr Nachteile als Vorteile, aber Compiletimereflection wäre wirklich etwas feines.



  • ipsec schrieb:

    Runtimereflection und GC hat für mich mehr Nachteile als Vorteile [...]

    Prinzipiell geb ich dir recht, ich halte RAII auch für ein bei weitem überlegenes Konzept. Allerdings hat das in Sprachen wie C# imo seine Berechtigung, damit entwickelt es sich sich zugegeben schon sehr viel schneller und einfacher. Reflection hab ich noch nie vermisst, die würd mir wohl nichtmal in C# wirklich abgehn...

    Was ich letztens wieder hatte wo ich mir dachte das wär nice to have: Baut doch bitte mal jemand was ein um bei verschachtelten Schleifen ein break über mehrere Ebenen zu machen. Natürlich kann man mit irgendwelchen Flags arbeiten oder die innere Schleife in eine Funktion packen, aber wenn der Schleifenkörper einfach nur ein Ausdruck is der aber 40 lokale Variablen benötigt dann ist das anstrengend...



  • ipsec schrieb:

    Nexus schrieb:

    Interessant, dass noch niemand Reflection und Garbage Collector erwähnt hat

    Jetzt wo dus erwähnst.. Runtimereflection und GC hat für mich mehr Nachteile als Vorteile, aber Compiletimereflection wäre wirklich etwas feines.

    Ja.
    Wobei die häufigste Anwendung wohl mit decltype, sizeof und alignof gelöst sind und viele weitere mit TMP incl SFINAE wie bei http://www.c-plusplus.net/forum/288521



  • dot schrieb:

    Was ich letztens wieder hatte wo ich mir dachte das wär nice to have: Baut doch bitte mal jemand was ein um bei verschachtelten Schleifen ein break über mehrere Ebenen zu machen...

    Da nimmste return. break2 ist was für PHP.


Anmelden zum Antworten