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

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.

Badestrand

Die Module hören sich interessant an, aber ich find leider nix dazu. Hat evtl jemand einen Link wie die Module aussehen?

Das mit den Modulen hab ich hier her:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/#mailing2007-12
Den genauen Entwurf von Vandevoorde findest du hier:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2316.pdf (inzwischen Revision 5)

Badestrand

Cool, danke für die Links! Muss mich erstmal durch die 23 Seiten durcharbeiten, aber oberflächlich sieht's schonmal nett aus

Eine Anmerkung:
Sollte man das Beispiel:

int foo ();
auto x2 = foo();
auto const& x3 = foo(); //auto kann mit cv-Qualifizierern, * und & verwendet werden

nicht besser so umschreiben, dass x3 keine Referenz auf eine temporäre Variable ist?

Vielleicht einfach

auto const& x3 = x2;

C++09 schrieb:

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

Ich bezweifle, dass es die Sache für Compilerentwickler vereinfachen wird, da sie den alten Mist trotzdem unterstützen müssen. Aber die Programmierer werden davon natürlich profitieren, weil neue Libs u.U. dieses Feature dann nutzen. Die Compilerbauer tun mir echt langsam leid. Es kommt immer neues freakiges Zeug hinzu, dabei ist offensichtlich, dass sie jetzt schon überfordert sind.

Ich freue mich jedenfalls trotzdem darauf. Ich hoffe, dass zumindest für den nächsten Standard die Concepts noch kommen.

Bashar

Optimizer schrieb:

Die Compilerbauer tun mir echt langsam leid. Es kommt immer neues freakiges Zeug hinzu, dabei ist offensichtlich, dass sie jetzt schon überfordert sind.

Warum votieren sie dann nicht dagegen? Der Standardisierungsprozess läuft ja nicht gerade hinter verschlossenen Türen ab.

Naja ich rede von den Code-Sklaven, die im -87ten Stock im Microsoft-Campus eingesperrt sind. Das sind nicht die Leute, die offiziell die Position vom MS (insert beliebige Firma here) vertreten. Überhaupt bin ich mir nicht sicher, ob sie die Änderungen ablehnen würden - ich sag nur, sie tun mir leid.

Zeus

Bashar schrieb:

Optimizer schrieb:

Die Compilerbauer tun mir echt langsam leid. Es kommt immer neues freakiges Zeug hinzu, dabei ist offensichtlich, dass sie jetzt schon überfordert sind.

Warum votieren sie dann nicht dagegen? Der Standardisierungsprozess läuft ja nicht gerade hinter verschlossenen Türen ab.

Weil die Veränderungen ihre Arbeitstelle sichert

sinamine

UTF-16-String-Literale. Eingeleitet werden diese mit dem Präfix u. Die dahinterstehende Kodierung ist UTF-16 und der Typ der Literale ist "Array von n const char16_t". char16_t ist ein neu eingeführter Typ mit der Kodierung UTF-16, der im Header <cuchar> definiert ist.

Wollte fragen, ob ich mir mit diesem Typ die Konvertierung sparen kann? D.h. wenn ich UTF-16 Daten mit komplexen Zeichen einlese, konvertiert mir char16_t die Daten automatisch nach UTF-16?

Bis wann genau werden die gesamten Erneuerungen zur Verfügung stehen? Und wie sieht es aus mit "Polymorphic Function Objects" welche im TR1 beschrieben sind. Bis wann wird man diese Erneuerungen nutzen können?

Dann wollte ich noch fragen, ob es irgendwelche Erneuerungen bezüglich Objekte zeichnen gibt. Also ob es ander Möglichkeiten gibt um eine Linie oder ein Rechteck zu zeichnen - also ein Kollege meinte, dass es Erneuerungen gibt bzw. geben wird, aber ich habe noch nicht wirklich etwas darüber gefunden! Wäre super wenn ihr mir weiterhelfen könntet!

Warum sollten wir etwas dagegen haben? Wir bekommen ja schließlich Geld dafür :p

queer_boy

sinamine schrieb:

UTF-16-String-Literale. Eingeleitet werden diese mit dem Präfix u. Die dahinterstehende Kodierung ist UTF-16 und der Typ der Literale ist "Array von n const char16_t". char16_t ist ein neu eingeführter Typ mit der Kodierung UTF-16, der im Header <cuchar> definiert ist.

Wollte fragen, ob ich mir mit diesem Typ die Konvertierung sparen kann? D.h. wenn ich UTF-16 Daten mit komplexen Zeichen einlese, konvertiert mir char16_t die Daten automatisch nach UTF-16?

ich weiß jetzt leider nicht aus dem stehgreif, ob es standard-streams gibt, die daten automatisch als UTF-16 einlesen können (basic_iostream<char16_t>), aber im prinzip stünde dem nichts im wege. char16_t werden eben, ganz un-standard-mäßig gesprochen, 2-byte-oder-mehr-character sein, die für UTF-16 ausreichend platz bieten, mehr nicht.

Bis wann genau werden die gesamten Erneuerungen zur Verfügung stehen? Und wie sieht es aus mit "Polymorphic Function Objects" welche im TR1 beschrieben sind. Bis wann wird man diese Erneuerungen nutzen können?

bis wann? die sachen, die im TR1 beschrieben sind, werden beinahe wortwörtlich in den neuen standard übernommen werden. die funktionen rund um std::bind sind durch boost schon seit langem verfügbar und werden eben obligatorisch.

Dann wollte ich noch fragen, ob es irgendwelche Erneuerungen bezüglich Objekte zeichnen gibt. Also ob es ander Möglichkeiten gibt um eine Linie oder ein Rechteck zu zeichnen - also ein Kollege meinte, dass es Erneuerungen gibt bzw. geben wird, aber ich habe noch nicht wirklich etwas darüber gefunden! Wäre super wenn ihr mir weiterhelfen könntet!

hm. andere möglichkeiten? bis jetzt hat der standard nicht definiert, was linien oder rechtecke sind, d.h. du wirst bis jetzt immer irgendein toolkit verwendet haben, das diese funktionen zur verfügung stellt.
zur grafischen ausgabe sagt der neue standard gar nichts (so wie der alte).

queer_boy

so, eine info: hab vor kurzem einige updates mithilfe des neuen working-drafts hier (und im anderen artikel) vorgenommen. C++0x ist nun feature complete und es dürfte wohl viele leute freuen, dass alle features, die hier vorgestellt werden, auch wahrscheinlich in dieser form, teil von C++0x werden. (ob C++0x nun C++09 wird oder C++0A steht zwar noch in den sternen, aber ich bin zuversichtlich )

Da gab's doch in diesem Komitee einen Kerl, der gegen alles gevoted hat was Concepts angeht, mit der Begründung dass er befürchtet, dass es zu unausgereift ist und hier ein falscher Grundstein gelegt wird. Weiß man genaueres darüber, was seine Befürchtungen sind?