C++0x: Batavia Meeting (vor ein paar Tagen)



  • Ich habe so eben ein paar Informationen zum letzten Meeting gefunden und wollte das hier mal verlinken.

    Zusammenfassing:

    1.
    Diese [[base_check]]-Syntax mit samt den [[hiding]] und [[override]] Attributen verschwindet. Stattdessen werden zwei neue kontextabhängige Schlüsselwörter eingeführt (override, final) und zwei andere Schlüsselwörter etwas zweckentfremdet (explicit, new). Beispiel:

    struct Base {
      virtual void foo();
      int x;
    };
    
    struct Derived final explicit : Base {
      virtual void foo() override; // explicitly override Base::foo
      double x new;                // explicitly hide Base::x
    };
    

    explicit in diesem Kontext lässt den Compiler überprüfen, ob man override/new richtig gesetzt hat. Wenn man versehentlich durch eine neue Deklaration einen Namen aus der Basisklasse versteckt, ohne "new" zu verwenden, oder eine virtuelle Funktion überschreibt, ohne "override" zu verwenden, dann wird das als Fehler gewertet. Mit final kann man anscheinend auch verhindern, dass die Klasse als Basisklasse verwendet wird bzw eine virtuelle Funktion nicht mehr überschrieben werden kann.

    2.
    Bjarne Stroustrup hat sich mit seinem Proposal N3174 ("To move or not to move") gegenüber N3153 ("Implicit Move Must Go") durchgesetzt. Im Endeffekt wird jetzt das automatische Generieren von Kopier- und Move-Operationen (ctor und op=) eingeschränkt. Sobald der Benutzer Kopier-Konstruktor, Move-Konstruktor, Kopier-Zuweisung, Move-Zuweisung oder Destruktor deklariert, soll nichts mehr automatisch generiert werden. Nur aus Kompatibilität zu C++03 belässt man die automatisch generierten Kopier-Operationen noch, sind aber als "deprecated" eingestuft. Dann sollte auch Schluss sein mit vielen Anfängerfehlern, wo die Dreierregel verletzt wird. Ein C++0x Compiler sollte in diesen Fällen Warnungen geben a la "Deprecated compiler-generated copy constructor used. Prefer to be explicit via the =default / =delete syntax." oder so ähnlich.

    Mein persöhnliches Fazit:
    1. 👍
    2. 👍

    kk



  • Danke für die Mitteilung.
    und
    Juhu!



  • Und wann kommt's raus?



  • Ebenfalls danke. Ich habe schon lange nichts Neues mehr von C++ gehört. 😉

    Von dem [[base_check]] habe ich ohnehin nicht allzuviel mitgekriegt, doch die Syntax hat mich auch abgeschreckt. Doch ob es eine gute Idee ist, stattdessen noch mehr Schlüsselwörter zu recyceln? Naja, jetzt sind wenigstens beide Speicherverwaltungs-Schlüsselwörter mehrdeutig. 🙂

    Das mit dem Move hört sich aber gut an. Gibts eigentlich irgendwo eine aktuelle Übersicht zu neuen Features? Das aktuellste, das ich kenne, ist das. Vielleicht nicht gerade der Standard-Entwurf selbst, denn besonders übersichtlich ist er nicht gerade...


  • Administrator

    Danke für die Info. Von [[base_check]] höre ich zum ersten Mal, aber diese Syntax hätte mich auch abgeschreckt. So wie es jetzt aussieht, erinnert es fast ein wenig an C#, bzw. C++/CLI. 🙂
    Schade, dass man explicit explizit (🤡) setzen muss, aber wegen Rückwärtskompatibilität ist das wohl nötig.

    Grüssli



  • Dravere schrieb:

    Schade, dass man explicit explizit (🤡) setzen muss, aber wegen Rückwärtskompatibilität ist das wohl nötig.

    Ja, aber "sind aber als "deprecated" eingestuft". Das ist ja eine nette Ankündigung, daß aktiv gewartete Libs es schnell rauswerfen, daß wir bald drauf die Warnung für dieses depri-Feature einschalten können, daß es bald drauf zur default-warning wird und in C++2x abgeschafft wird (aber alle höflichen Compiler einen Schalter haben, es doch noch nehmen zu können).



  • Was ist denn deprecated? Ich dachte, die automatische Generierung der Grossen Drei aus C++98.

    Dravere meint aber eher die Überschreibung/Neudeklaration von Klassenmembern. Wird es in C++0x deprecated sein, Klassen ohne explicit zu definieren?



  • Ist denn schon klar, wofür x stehen wird? B, C oder doch D-F? When it's done?



  • Nexus schrieb:

    Von dem [[base_check]] habe ich ohnehin nicht allzuviel mitgekriegt, doch die Syntax hat mich auch abgeschreckt. Doch ob es eine gute Idee ist, stattdessen noch mehr Schlüsselwörter zu recyceln? Naja, jetzt sind wenigstens beide Speicherverwaltungs-Schlüsselwörter mehrdeutig. 🙂

    Stimmt. 🙂 Aber das mit dem Recyceln finde ich hier nicht so schlimm. Überrascht bin ich aber von der Einführung von kontext-abhängigen Schlüsselwörtern. "override" und "final" sind nur an diesen Stellen Schlüsselwörter und können sonst (aus Kompatibilitätsgründen) als Bezeichner verwendet werden.

    Nexus schrieb:

    Gibts eigentlich irgendwo eine aktuelle Übersicht zu neuen Features? [...] Vielleicht nicht gerade der Standard-Entwurf selbst, denn besonders übersichtlich ist er nicht gerade...

    Als Übersicht ist die C++0x-Wikipedia-Seite doch ganz brauchbar. Wenn's um Details spezieller Features geht, wird's schwieriger. ZB gibt es kein Nxxxx-Paper, was die aktuelle Version von Rvalue-Referenzen zusammenfasst. Da muss man entweder einige Rvalue-Referenz-bezogene Papers lesen, die aufeinander aufbauen, oder es aus dem aktuellen Entwurf rausfischen. Ich schätze, das ist bei dem einen oder anderen Feature ähnlich. Die einzige lesbare und aktuelle Quelle bzgl Rvalue-Referenzen, die ich kenne, ist diese Reihe von Blog-Artikeln.

    Nexus schrieb:

    Was ist denn deprecated? Ich dachte, die automatische Generierung der Grossen Drei aus C++98.

    Automatisch generierter copy_ctor und copy_op= sind deprecated falls der Benutzer irgendwas von diesen Kopier- und Move-Dingern oder auch schon den Destruktor selbst deklariert hat. Bei einer Klasse wie dieser hier:

    class matrix
    {
    public:
      matrix (int zeilen, int spalten);
      double& operator()(int i, int j);
      double  operator()(int i, int j) const;
    private:
      int zeilen_, spalten_;
      std::vector<double> koeffizienten_;
    };
    

    werden immer noch automatisch folgende Konstruktoren und Funktionen vom Compiler implizit deklariert und definiert (falls benutzt) -- ganz ohne Nutzung von irgend etwas, was "deprecated" ist:

    matrix(matrix const&);
       matrix(matrix &&);
       matrix& operator=(matrix const&); 
       matrix& operator=(matrix &&);
    

    Nexus schrieb:

    Wird es in C++0x deprecated sein, Klassen ohne explicit zu definieren?

    Nicht, dass ich wüsste.

    Wenn alles weitere "glatt geht", sollte x für B stehen, also 2011. Zumindest ist das eine der letzten aktuelleren Einschätzungen (Herb Sutter).

    kk



  • krümelkacker schrieb:

    Überrascht bin ich aber von der Einführung von kontext-abhängigen Schlüsselwörtern. "override" und "final" sind nur an diesen Stellen Schlüsselwörter und können sonst (aus Kompatibilitätsgründen) als Bezeichner verwendet werden.

    Daran werden die Syntaxhighlight-Entwickler sicher ihre Freude haben. 🙂

    Aber so wirklich notwendig scheint mir diese Abwärtskompatibilität ja nicht zu sein. Im Notfall wäre Bezeichner-Refactoring immer noch einer der am wenigsten schlimmen Eingriffe (und sei es durch ein angefügtes "_" oder der Sicherheit halber "_langes_wort_um_kollisionen_zu_vermeiden"). Dafür die Komplexität der Sprache nochmals zu erhöhen, ist in meinen Augen unnötig.

    krümelkacker schrieb:

    Automatisch generierter copy_ctor und copy_op= sind deprecated falls der Benutzer irgendwas von diesen Kopier- und Move-Dingern oder auch schon den Destruktor selbst deklariert hat.

    Stimmt, hab ich inzwischen auch im Stroustroup-Paper gelesen. Scheint mir auch sehr sinnvoll so.

    krümelkacker schrieb:

    Bei einer Klasse wie dieser hier [...] werden immer noch automatisch folgende Konstruktoren und Funktionen vom Compiler implizit deklariert und definiert (falls benutzt) -- ganz ohne Nutzung von irgend etwas, was "deprecated" ist:

    matrix(matrix const&);
       matrix(matrix &&);
       matrix& operator=(matrix const&); 
       matrix& operator=(matrix &&);
    

    Destruktor gehört sicher auch dazu, oder? Vielleicht auch der Adressoperator, oder gilt der eingebaute im C++-Sinne gar nicht als Funktion?

    krümelkacker schrieb:

    Nicht, dass ich wüsste.

    Okay. Danke für die Antworten und die Links!



  • Super, die beiden Sachen wurden so entschieden, wie ich gehofft hatte. 👍


Log in to reply