C++09 (Teil 1) - Ein Überblick: Sprachfeatures

KasF schrieb:

... Ist decltype überhaupt nen Compile-Zeit-Operator ?

Muss es, da C++ ein statisches Typsystem hat.

Prokkramierer schrieb:

Muss es, da C++ ein statisches Typsystem hat.

Stimmt ja

Was ist mit dem Trick nun:

template<class A, class B>
decltype(A() + B()) operator+( const A& a, const B& b);

anstatt:

template<class A, class B>
auto operator+( const A& a, const B& b) -> decltype(a + b);

Kann das funktionieren ?

Bashar

KasF schrieb:

Was ist mit dem Trick nun:

template<class A, class B>
decltype(A() + B()) operator+( const A& a, const B& b);

Ich würde mal aus dem Bauch heraus sagen, das funktioniert ohne Probleme, wenn A und B default-konstruierbar sind.

camper

KasF schrieb:

[Was ist mit dem Trick nun:
template<class A, class B>
decltype(A() + B()) operator+( const A& a, const B& b);
Kann das funktionieren ?

Daran ist nichts auszusetzen - aber ist das wirklich einfacher?
Die andere Deklarationsform erlaubt es, den typbestimmenden Ausdruck genauso zu schreiben, wie er dann tatsächlich in der Implementation vorkommt - bei traditioneller Schreibweise wie hier sieht das dagegen doch recht umständlich aus (insbesondere wenn die Funktionsparametertypen komplexer werden (häufig genug werden die ja irgendwie komplex aus den Templateparametern zusammengesetzt).
Was ich evtl. kritisieren würde, ist, dass auch bei neuer Schreibweise immer noch Codeduplizität auftritt - der decltype-Ausdruck nimmt ja im Grunde die Implementation vorweg. So gesehen wäre es ggf. wünschenswert, den return-Typ gar nicht explizit angeben zu müssen und auf diesen aus der Implementation zu schließen, z.B.:

template<typename T, typename U>
constexpr auto max(T&& a, U&& b) { return a < b ? b : a; } // implizit inline auch ohne constexpr, statt
template<typename T, typename U>
constexpr auto max(T&& a, U&& b) -> decltype( a < b ? b : a ) { return a < b ? b : a; }

Das wäre denkbar, wenn die Implementation wie bei contexpr dann vornherein auf ein einzelnes return-Statement beschränkt ist (die meisten Fälle, die mir einfallen, sollten sowieso constexpr sein). Ist aber wahrscheinlich nicht wichtig genug, um die Sprache dafür zu ändern.

queer_boy

Bashar schrieb:

KasF schrieb:
Was ist mit dem Trick nun:
template<class A, class B>
decltype(A() + B()) operator+( const A& a, const B& b);
Ich würde mal aus dem Bauch heraus sagen, das funktioniert ohne Probleme, wenn A und B default-konstruierbar sind.

oder man würde auf nummer sicher gehen:

template <class A, class B>
decltype(*static_cast<A*>(0) + *static_cast<B*>(0)) operator + (A const&, B const&);

das ist umständlich.

camper schrieb:

Was ich evtl. kritisieren würde, ist, dass auch bei neuer Schreibweise immer noch Codeduplizität auftritt - der decltype-Ausdruck nimmt ja im Grunde die Implementation vorweg. So gesehen wäre es ggf. wünschenswert, den return-Typ gar nicht explizit angeben zu müssen und auf diesen aus der Implementation zu schließen, z.B.:
template<typename T, typename U>
constexpr auto max(T&& a, U&& b) { return a < b ? b : a; } // implizit inline auch ohne constexpr, statt
template<typename T, typename U>
constexpr auto max(T&& a, U&& b) -> decltype( a < b ? b : a ) { return a < b ? b : a; }

ich habe dunkel in erinnerung, diesen vorschlag irgendwo gelesen zu haben. ein schnelles durchschauen der passenden dokumente hat aber jetzt irgendwie nichts gebracht. ich wüsste jetzt aber nicht einmal mehr, wie weit ausgereift dieser vorschlag wäre.

camper schrieb:

aber ist das wirklich einfacher?

Kommt wahrscheinlich auf die Funktion an. Bei op+ zb sind mir ja die Parameter egal, mich interessiert ja nur der Typ. Hingegen bei deinem max müsste ich die auto -> decltype Variante benutzen.

Wobei ich auto -> decltype irgendwie schöner finde, also decltype( T()+U() )

camper schrieb:

Was ich evtl. kritisieren würde, ist, dass auch bei neuer Schreibweise immer noch Codeduplizität auftritt - der decltype-Ausdruck nimmt ja im Grunde die Implementation vorweg.

Hmmm, das gefällt mir irgendwie gar nicht, wäre schön wenn das so Umgesetzt werden könnte, wie du es vorgeschlagen hast.

Lol wie geil jetzt werden Kritiken an der neuen Syntax schon gelöscht

GPC

Frickler schrieb:

Lol wie geil jetzt werden Kritiken an der neuen Syntax schon gelöscht

Nein, ich lösche Posts die offensichtlich nur einen Flamewar provozieren.

Ich habe doch nur meine subjektive Meinung dazu abgegeben. Gut der letzte Satz konnte auch falsch verstanden werden, aber einen Flamewar wollte ich damit nicht provozieren, sondern nur darauf hinweisen, dass es in anderen Sprachen doch auch mit etwas weniger kryptischer Syntax geht.

Ben04

Langsamer wird das aber wirklich sehr stark OT hier. Hier gehören Beiträge zum und Diskussionen über den Artikel hin, nicht wie man C++09 besser machen könnte und schon gar keine Diskussion über einen Flamewar. Dafür sind NDR und RudP da,

GPC

Diskussionen die nicht direkt zum Artikel gehören ab jetzt hier: http://c-plusplus.net/forum/viewtopic-var-t-is-207658.html

queer_boy

so, ich habe nun nach neuerlichem durchforsten von http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2597.html den status der jeweiligen features neu beurteilt. einige veränderungen kurz: closures (mit einer leicht unterschiedlichen syntax als die, die ich ursprünglich im artikel hatte - schon nachgebessert), die neue funktionsdeklaration und ein paar kleinere sachen sind im working draft; noch nicht dabei: die neue for-schleife und concepts, dafür reif zur aufnahme: thread-lokale variablen und ein standardisiertes __attribute__.

ghorst

also zuerst einmal: sehr guter artikel und vielen dank, dass du die änderungen für uns zusammengetragen hast.

nun zum eigentlichen: dass die concepts noch nicht teil des draft sind, finde ich ehrlich gesagt seltsam, da sie aus meiner sicht eine der sinnvollsten erweiterungen darstellen, da man zum einen endlich sinnvolle fehlermeldungen produzieren kann und zum anderen sich mit concept_map<> einen ganzen batzen adapterklassen sparen kann. ich hoffe, dass die doch noch reinkommen.

Wo sollen sie sonst rein, wenn nicht in den Draft? Sie können nirgendwo besser rein, als dort. Dort wo du sie rein haben willst, können sie noch nicht rein, weil es den C++09-Standard noch garnicht gibt. Wer im Draft ist, ist so gut wie drin. Und drin ist man erst, wenns echte ISO-Norm geworden ist.

ghorst

hmm. in meinem letzten beitrag fehlte ein nicht. jetzt ist es drin. die concepts sind eben noch nicht teil des draft und das stört mich.

queer_boy

aber so wie die momentane arbeitsverteilung des komitees aussieht, werden concepts wahrscheinlich bis zum oder knapp nach dem nächsten meeting drin sein, also keine sorge

Weiß jemand wie es mit dem Zeitplan nach C++09 aussieht?
Der TR2 soll ja zeitnah (was auch immer das bedeutet) folgen. Es soll dort wahrscheinlich eine Netzwerkbibliothek und ein Modulkonzept für C++ entwickelt werden. Wann soll TR2 eigentlich verabschiedet werden?

Für TR2 wurde Boost.asio und Boost.filesystem vorgeschlagen. Da denke ich, werden die das gebacken bekommen. Einen Termin gibt es denke ich nicht. Ich schätze mal, die werden das so in 2 bis 3 Jahren verabschieden.

Das Module reinkommen (wenn du damit dynamische Libs meinst?) bezweifel ich. Das werden die in 10 Jahren nicht schaffen...

Die Netzwerkbibliothek war ja wirklich notwendig. Eigentlich nicht so schön das es noch dauert.
Mit Modulen meine ich das Paper von David Vandervoorde. Es gab Pläne es mit einem dynamischen Modulsystem (Plugins) zu kombinieren, so wie ich mitbekommen habe. Die Einschnitte in den C++ Standard sind aber wahrscheinlich zu groß als das man hier schnell etwas sehen wird. Denn das bedeutet faktisch die Anbschaffung des alten auf #include-Anweisungen basierenden Modulariesierungssystems - wenn man das überhaupt so nennen konnte -. Aber interessant wäre es schon. Das würde Compilezeiten drastisch reduzieren, Namespace pollution
vermeiden und Sachen wie Whole Program Optimisation für Compiler Entwickler deutlich vereinfachen.
Scheinbar interessieren sich aber viele dafür weil es schon oft einem Peer-Review unterzogen wurde und in einen nachfolgenden TR aufgenommen werden soll, zumindest laut www.open-std.com

Zeus

HansiHinterseher schrieb:

Für TR2 wurde Boost.asio und Boost.filesystem vorgeschlagen. Da denke ich, werden die das gebacken bekommen. Einen Termin gibt es denke ich nicht. Ich schätze mal, die werden das so in 2 bis 3 Jahren verabschieden.

Das Module reinkommen (wenn du damit dynamische Libs meinst?) bezweifel ich. Das werden die in 10 Jahren nicht schaffen...

Module sollen ein neues Include-Methode sein. Evtl. hat es was mit den Libs gemeinsam, aber das weiss ich nicht. Module sind für den Standard nach C++09 vorgesehen.