3. C++ Standardisierung: Ein erster Blick auf die Papers & C++14

C++ Standardisierung: Ein erster Blick auf die Papers & C++14

  • O

    Naja, mich haut von den proposals jetzt nichts wirklich vom Hocker.

    //edit hätte ich mehr zeit, würde ich ja meine "structural constness" ins Rennen werfen, aber momentan kann ich nicht die notwendige Zeit investieren, ein gutes proposal paper zu schreiben...

    0
  • N

    Sone schrieb:

    Manchmal brauche ich ein Array, das eben eine zur Laufzeit bekannte Größe hat, aber diese nicht verändern kann. Ich verstehe nicht, wieso ich da in vector einen Kompromiss sehen muss. Das ist kein Overbloat.

    Ob es nützlich ist, ist eine Sache. Ob es in die Standardbibliothek muss, eine andere. Meiner Meinung nach gibt es viel wichtigere Dinge als so ein Spezialfall von Container, der so gut wie keine Vorteile gegenüber std::vector bringt. Da wären einige Klassentemplates aus Boost.Container (z.B. stable_vector oder flat_map ) massiv bessere Kandidaten.

    otze schrieb:

    Naja, mich haut von den proposals jetzt nichts wirklich vom Hocker.

    Ja, bisher gibts keine Killerfeatures. std::optional scheint mir am nützlichsten zu sein.

    Bei gewissen Features wie dem const type| -Qualifizierer frage ich mich, wieso es dauernd Leute gibt, die für nahezu-nutzlose Features bereit sind, die Komplexität des Typsystems weiter zu erhöhen 🙄

    0
  • P

    otze schrieb:

    Naja, mich haut von den proposals jetzt nichts wirklich vom Hocker.

    C++14 wird ja eigentlich auch nur dazu da sein, C++11 zu verbessern.
    Z.b. Polymorphic Lambdas oder then() für std::future/std::shared_future.
    Hab mich gestern durch weitere 9 Papers gelesen, da sind schon interessante Sachen dabei,
    aber auch die Frage, was letzten endes dann wirklich wie durchs Committee kommt.

    Im Bereich Parallelism sind viele interessante Proposals, aber wie man die wieder sinnvoll unter einen Hut bekommt ist wohl die Preisfrage.

    Wer von euch nutzt eigentlich schon C++11 aktiv?

    0
  • N

    Ich glaube fast alle.

    0
  • N

    otze schrieb:

    //edit hätte ich mehr zeit, würde ich ja meine "structural constness" ins Rennen werfen, aber momentan kann ich nicht die notwendige Zeit investieren, ein gutes proposal paper zu schreiben...

    Das ist auch sowas. Statt die richtigen Probleme anzugehen (Modulsystem, Concepts), werden tausend kleine Änderungen vorgeschlagen, die in einzelnen Spezialfällen minimale Vorteile bringen. Im Grossen betrachtet führen sie aber zu vielen Nachteilen, weil die Sprachintegration sich als schwierig erweist und viele Probleme mit sich bringt, die anfänglich nicht sichtbar sind. Für so eine grundlegende Änderung wie const muss meiner Meinung nach eine extrem gute Rechtfertigung vorhanden sein. Warum das bei struct const nicht der Fall ist, habe ich hier erklärt.

    Mit jedem neuen Sprachmittel wird C++ noch einmal komplexer, Leute brauchen noch einmal länger, um die Sprache zu lernen, und es bilden sich noch mehr inkompatible Codestile. Würde mich nicht wundern, wenn die massive Häufung solcher "Features" letzen Endes das Todesurteil von C++ bedeutete. Mittelfristig wird sie mindestens zu einer Spaltung in der Community führen (wenn das mit C++11 nicht schon längst passiert ist). Ich finde, man sollte versuchen dem entgegen zu wirken, und langfristig auch über abwärts-inkompatible Änderungen nachdenken. Natürlich ist das leichter gesagt als getan, aber ich hoffe zumindest, dass das Kommitee sehr restriktiv im Bezug auf solche Proposals ist...

    phlox81 schrieb:

    Wer von euch nutzt eigentlich schon C++11 aktiv?

    Dauernd, zumindest die portabel einsetzbaren Features: RValue-Referenzen, nullptr , Lambda-Expressions, Smart Pointers, ...

    std::make_unique() muss unbedingt mit C++14 kommen.

    0
  • P

    Nathan schrieb:

    Ich glaube fast alle.

    Das glaube ich nicht.
    Viele Compiler unterstützen es gerade erst, und in vielen Projekten wird noch sehr lange der ältere Standard verwendet werden.
    Für eigenen Code gilt das natürlich häufig nicht.

    0
  • C

    Nexus schrieb:

    otze schrieb:

    Naja, mich haut von den proposals jetzt nichts wirklich vom Hocker.

    Ja, bisher gibts keine Killerfeatures. std::optional scheint mir am nützlichsten zu sein.

    wtf? Was wäre an SIMD und ernsthafter Unicode Unterstützung bitte kein "Killerfeature"? Beides ist sicherlich hilfreicher als optional.

    Nexus schrieb:

    Das ist auch sowas. Statt die richtigen Probleme anzugehen (Modulsystem, Concepts), werden tausend kleine Änderungen vorgeschlagen, die in einzelnen Spezialfällen minimale Vorteile bringen.

    1. Wurde doch schon 2011 gesagt dass C++14 primär eine Library Erweiterung wird und Dinge wie Concepts und Modules erst 2017 kommen.
    2. Würde ich filesystem, network SIMD und Unicode nicht als "kleine Änderungen, die in einzelnen Spezialfällen minimale Vorteile bringen" bezeichnen.

    0
  • N

    Ich bezog mich auf die Proposals auf phlox81s Seite. Deshalb "bisher"

    "Kleine Änderungen, die in einzelnen Spezialfällen minimale Vorteile bringen" war eine Reaktion auf Vorschläge wie struct const oder const| .

    0
  • P

    Nexus schrieb:

    Ich bezog mich auf die Proposals auf phlox81s Seite. Deshalb "bisher"

    "Kleine Änderungen, die in einzelnen Spezialfällen minimale Vorteile bringen" war eine Reaktion auf Vorschläge wie struct const oder const| .

    Alle Proposals findest du hier: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/#mailing2013-03

    Ja, von type| bin ich auch nicht sehr begeistert, man muss aber immer sehen, dass das ja nur Vorschläge sind.
    Denke dass sowas nicht durch Committee kommt. Generell wird es alles schwer haben, was veränderungen an der Sprache vornehmen will.
    Mit Ausnahmen der Proposals welche sich auf C++11 features beziehen, und diese verbessern oder erweitern.

    0
  • C

    Oh, okay. Sorry Nexus.

    0
  • N

    Danke für den Link, phlox81. Ich werde wahrscheinlich aber deinen Blog verfolgen, da gibts eine schöne Zusammenfassung. Vielen Dank auch dafür! 🙂

    0
  • O

    Nexus schrieb:

    ]Das ist auch sowas. Statt die richtigen Probleme anzugehen (Modulsystem, Concepts), werden tausend kleine Änderungen vorgeschlagen

    Ich glaube weder an das Modulsystem, noch an Concepts. Wahrscheinlich liegt es daran. Der Berg an Komplexität die diese beiden Änderungen mit sich bringen ist nicht abzusehen, eben weil das so riesige Änderungen sind. Es ist nur klar: die Komplexität der Concepts war so groß, dass Stroustrup angst davor hatte. Und wenn wir jetzt concepts-light kriegen, löst das am Ende vielleicht keins der Probleme.

    Und ich sehe auch nicht, wie ein Konzept meinen Vorschlag ersetzen wollte. Das Konzept kann nur auf Ebene der Funktionssignatur funktionieren. Es schützt aber nicht davor, das eine zweite Funktionssignatur eingeführt wird, die nun die Einschränkungen des Konzepts ignoriert. Ich kann mir also nicht sicher sein das, nach sort(vector) noch meine iteratoren auf vector gültig sind. wenn ich aber sagen würde: die struktur von vector ist konstant, dann weiß ich, das sort(vector) niemals meine iteratoren invalidiert, weil der compiler das abfangen würde.

    Ebenso würde ein Konzept nicht ermöglichen, das ein container oder eine Klasse intern ausnutzen könnte, das der Aufrufer nicht beabsichtigt, die Struktur zu verändern. Ich kann also nicht eine Referenz auf meinen container zurückgeben, damit der Bbenutzer die Werte ändern kann, weil ich keinen Weg habe zu garantieren, dass der Benutzer neue Werte hinzufügt oder anderweitig die Struktur verändert.

    Hier zum Beispiel ein Anwendungsfall der sich mit Konzepts nicht darstellen ließe:

    struct const std::vector<double> vec(10,0);
struct const std::vector<double> vec1(10,1);
struct const std::vector<double> vec2(20,1);
vec=vec1;//okay, selbe struktur, allerdings copy anstatt swap um iteratoren valide zu halten.
vec=vec2; //Laufzeitfehler: inkompatible Größen von vec und vec2
    0
  • C

    Ehm.. wtf? Laufzeitfehler? Nicht dass ich das Concepts-Light Proposal auswendig kennen würde, aber das Beispiel ergibt für mich überhaupt keinen Sinn. Auf welche Sektion im Proposal bezieht sich das? Und deine Abneigung gegenüber Modules hast du auch nicht weiter erklärt.

    0
  • O

    cooky451 schrieb:

    Ehm.. wtf? Laufzeitfehler?

    Es geht um Verhalten, das ich gerne hätte. Das concept verhalten wäre, dass du keinen operator= für ranges verwenden könntest. Denn wenn die Ranges auch assignable wären, dann gibt dir

    template<Range RangeType>
sort(RangeType& range);

    nur sehr schwache Garantien - in der tat schwächere als

    template<class Iterator>
sort(Iterator begin, Iterator end);

    Ichs ehe halt nicht, wie man das mit Konzepts umsetzen kann.

    0
  • C

    Wie jetzt, also das was du willst ist, dass eine Zuweisung auf ein konstantes Objekt kompiliert? 😮 Sorry, aber das kann ich nicht nachvollziehen. Edit: Eine range per Referenz zu nehmen sieht für mich auch nicht sinnvoll aus.

    0
  • P

    otze schrieb:

    Hier zum Beispiel ein Anwendungsfall der sich mit Konzepts nicht darstellen ließe:

    struct const std::vector<double> vec(10,0);
struct const std::vector<double> vec1(10,1);
struct const std::vector<double> vec2(20,1);
vec=vec1;//okay, selbe struktur, allerdings copy anstatt swap um iteratoren valide zu halten.
vec=vec2; //Laufzeitfehler: inkompatible Größen von vec und vec2

    Laufzeitfehler?!? Soll dann ne Exception fliegen?
    Wenn sollte dass zur Compiletime abgefangen werden.
    Und was du hier als container brauchst, wäre ja DynArray, und nicht vector.

    0
  • N

    Ich wollte nicht sagen, dass man genau den Anwendungsfall mit Concepts umsetzen könnte. Dazu kenne ich diese ehrlich gesagt zu wenig. Aber ich fürchte, dass du dir struct const als kleine Änderung vorstellst und über die Tragweite nicht im Klaren bist. CV-Qualifizierer sind so stark in die Sprache verankert, da müsstest du an etlichen Stellen anpassen.

    Und dass ein Laufzeitfehler auftritt, macht das Feature noch weniger vorteilhaft. Könnte man das Gleiche nicht mit Ranges erreichen?

    std::vector<double> vec(10,0);
std::vector<double> vec1(10,1);
std::vector<double> vec2(20,1);

auto r = make_range(vec);
auto r1 = make_range(vec1);
auto r2 = make_range(vec2);

exhaustive_copy(r, r1);
exhaustive_copy(r, r2); // BAM

    template <typename RaRange1, typename RaRange2>
void exhaustive_copy(RaRange1 src, RaRange2 dest)
{
    assert(src.size() == dest.size()); // <-- oder Exception
    for (; !src.empty(); src.pop_front(), dest.pop_front())
        dest.front() = src.front();
}
    0
  • C

    Auch so, "struct const" soll was neues sein. Was das alles mit Concepts und Modules zu tun hat, verstehe ich allerdings immer noch nicht...

    0
  • O

    cooky451 schrieb:

    Auch so, "struct const" soll was neues sein. Was das alles mit Concepts und Modules zu tun hat, verstehe ich allerdings immer noch nicht...

    mir wurde gessagt, dass man das mit Concepts modellieren könnte und concepts und modules the holy grail sind. Was sie nicht sind.

    @Nexus Mir ist durchaus sehr bewusst, wie groß diese Änderung wäre. Ja, ich habe mehr als 20 Minuten darüber nachgedacht.

    Klar kann man das immer irgendwie anders implementieren. Genauso wie man auch ohne concepts und modules gut klar kommt.
    Der Punkt ist: deine Version hat mehr Aufwand im Code und lagert mehr Verantwortung auf den Nutzer ab. Ich versuche das zu minimieren.

    Zum Laufzeitfehler:
    Ich wüsste nicht, wie man das Verhalten mit irgendeinem Sprachfeature in irgendeiner Implementation nicht zur Laufzeit abfangen sollte. Immerhin ist erst bekannt ob die Invariante "size()" des Vektors verletzt wird, wenn die Größe des anderen Vektors bekannt ist. Der Punkt ist aber: der Code sagt kürzer aus, was er macht und wir beschäftigen uns weniger mit dem "wie" ( exhaustive_copy oder op=) als mit dem "was", weil wir das direkt zentral im vector implementieren können:

    struct vector{
      vector operator=(vector other){//copy& swap idiom als normalfall
          swap(*this,other);
      }
      vector operator=(vector const& other)struct const{//strukturerhalted
          assert(size() == other.size()); // <-- oder Exception
          std::copy(other.begin(),other.end(),begin());
      }
};

    natürlich ist da smit dem laufzeitfehler hier ein Spezialfall des Algorithmus. In anderen Fällen kann der Compiler natürlich genau entscheiden, ob und was geht:

    struct const vector<double> vec(20);
vec.resize(10);//Compilefehler.

    Das ist natürlich etwas suboptimal, weil vec.resize(20) die invariante nicht verletzt, naja, aber auch das wäre lösbar:

    template<class T>
void resize(T& vec, std::size_t size){
    vec.resize(size);
}
template<class T>
void resize(T struct const& vec, std::size_t size){
    assert(vec.size() == size); // <-- oder Exception
}
    0
  • C

    otze schrieb:

    mir wurde gessagt, dass man das mit Concepts modellieren könnte und concepts und modules the holy grail sind. Was sie nicht sind.

    Doch, das sind sie. Oder sagen wir mal so, ohne sie ist C++ quasi tot. Und was "structural constness" jetzt genau mit Concepts zu tun hat, verstehe ich immer noch nicht. Der Anwendungsbereich scheint sich ja relativ groß zu überschneiden, wenn das als Alternative vorgeschlagen wird, was ich einfach nicht sehe. (Concepts haben generell keine Auswirkung auf erzeugten Code?) Hast du die Idee irgendwo mal ausführlicher erklärt?

    0
Anmelden zum Antworten