C++11 (aka C++0x) - Approval of Final Committee Draft

[drakon]

/rant/ schrieb:

Die ETH mag ja eine der besten Universitäten sein, aber die HSR ist viel schöner.

Ach was. Dann hast du die wahre Schönheit der ETH nicht begriffen. Oder kannst du dir etwas schöneres, als dunkle Vorlesungsääle mit dicken Betonmauern vorstellen?! xD

[Gast]

Also wann der Standard denn jetzt offiziell verabschiedet wird, scheint mir schon gar nicht mehr so relevant zu sein. Die Compilerhersteller haben angefangen, die Neuerungen umzusetzen, das zählt. Dafür ist der Standard auch jetzt schon "final" genug. Natürlich ist die formale Spezifikation wichtig, aber ich denke nicht, dass das noch so einen großen Einfluss darauf hat, ab wann wir die Features in der Praxis benutzen können.

[drakon]

Optimizer schrieb:

ab wann wir die Features in der Praxis benutzen können.

Naja. Das ist ja sowieso sehr relativ. Es geht sicher 1-2 Jahre bis die Compiler dann alles definitiv anbieten, aber in der Praxis nutzen?
Was ich das bei gewissen Firmen so mitbekomme wird das definitiv noch bis zum Standard danach dauern.

Die Verabschiedung ist ja sozusagen das "in-Stein-meisseln". Das, was dann da drin ist wird da bleiben.

Aber ja prinzipiell ist schon genug bekannt.

[evilissimo]

drakon schrieb:

Es geht sicher 1-2 Jahre bis die Compiler dann alles definitiv anbieten, ...

Du bist aber ein Optimist

Edit: Aber ich freu mich ja beim VC 2010 darüber einen Ast das er schon auto, lambda, rvalue references und decltype unterstützt

[drakon]

evilissimo schrieb:

drakon schrieb:

Es geht sicher 1-2 Jahre bis die Compiler dann alles definitiv anbieten, ...

Du bist aber ein Optimist

Edit: Aber ich freu mich ja beim VC 2010 darüber einen Ast das er schon auto, lambda, rvalue references und decltype unterstützt

Hehe. Ich gebe mir Mühe.
Naja. Die beiden gängigen Compiler MSVC++ und GCC sind ja schon recht gut in der Entwicklung und ich bin eigentlich zuversichtlich, dass die das in 3 Jahren eigentlich soweit umgesetzt haben. Ist ja nicht gerade so, dass etwas extrem kompliziertes und kaum umzusetzendes seinen Weg in den Standard gefunden hat (wie damals die templates).

@dein edtit:
Jap. Das ist genau das, was ich meinte damit, dass sie gut in der Entwicklung sind (GCC afaik besser, als MSVC++)

[krümelkacker]

Neben Herb Sutter's Bericht gibt's auch noch einen Bericht von Michael Wong.

Anscheinend hat man sich auch dazu entschieden, mit den Begriffen lvalue/rvalue "aufzuräumen". Zumindest unterscheidet man jetzt zwischen

• lvalue (bleibt so wie vorher)
• xvalue (Objekt, referenziert durch eine unbenannte &&-Referenz)
• prvalue ("pure" rvalue, das sind alle rvalues außer xvalues)

Die ersten beiden fasst man zusammen als "glvalues" und die letzten beiden als "rvalues".

Klar soweit?

[evilissimo]

krümelkacker schrieb:

Neben Herb Sutter's Bericht gibt's auch noch einen Bericht von Michael Wong.

Anscheinend hat man sich auch dazu entschieden, mit den Begriffen lvalue/rvalue "aufzuräumen". Zumindest unterscheidet man jetzt zwischen

• lvalue (bleibt so wie vorher)
• xvalue (Objekt, referenziert durch eine unbenannte &&-Referenz)
• prvalue ("pure" rvalue, das sind alle rvalues außer xvalues)

Die ersten beiden fasst man zusammen als "glvalues" und die letzten beiden als "rvalues".

Klar soweit?

Ja ne is klar. 'Aufräumen' gut das du das gleich in Anführungszeichen geschrieben hast. Das klingt mehr nach 'Machen wir es noch komplizierter'

BR

[C++ Fan 2010]

Bitsy schrieb:

Wie auch immer - vermutlich kostet's am Ende wieder einen Haufen Geld...

Meinste, danach gibts den GCC nicht mehr umsonst?

[evilissimo]

C++ Fan 2010 schrieb:

Bitsy schrieb:

Wie auch immer - vermutlich kostet's am Ende wieder einen Haufen Geld...

Meinste, danach gibts den GCC nicht mehr umsonst?

Nein den Standard als Dokument zu kaufen ist teuer.

[Ben04]

Gut finde ich, dass export und Exception specifications rausgeflogen sind.

Aber Concepts hätte ich schon gern gehabt. Oder zu mindest irgendetwas was den typename Foo::template Bar<typename Blub::Bla>-Quark leichter zu lesen macht. Ganz böse wird's, wenn man dann noch Typs einstreut welche keine Templateparameter sind.

[*rant*]

Ben04 schrieb:

Gut finde ich, dass export und Exception specifications rausgeflogen sind.

Aber Concepts hätte ich schon gern gehabt. Oder zu mindest irgendetwas was den typename Foo::template Bar<typename Blub::Bla>-Quark leichter zu lesen macht. Ganz böse wird's, wenn man dann noch Typs einstreut welche keine Templateparameter sind.

export ist weg? Exception specs sind auch weg? Yeehaa

[krümelkacker]

evilissimo schrieb:

krümelkacker schrieb:

Anscheinend hat man sich auch dazu entschieden, mit den Begriffen lvalue/rvalue "aufzuräumen". Zumindest unterscheidet man jetzt zwischen

• lvalue (bleibt so wie vorher)
• xvalue (Objekt, referenziert durch eine unbenannte &&-Referenz)
• prvalue ("pure" rvalue, das sind alle rvalues außer xvalues)

Die ersten beiden fasst man zusammen als "glvalues" und die letzten beiden als "rvalues".

Ja ne is klar. 'Aufräumen' gut das du das gleich in Anführungszeichen geschrieben hast. Das klingt mehr nach 'Machen wir es noch komplizierter'

Heheh. So schlimm ist es aber nicht. Man hat "rvalue" eigentlich nur aufgeteilt in "xvalue" und "prvalue". Ich sehe ein, dass es sinnvoll ist, den Dingen einen Namen zu geben. Einige Stellen im Standard unterscheiden nur zwischen glvalues/prvalues, zB wenn es um Polymorphie und dynamische Typen geht. Andere Stellen unterscheiden nur zwischen lvalue/rvalue, zB wenn es um das "Binden" von Referenzen geht. Statt Sonderregeln und Ausnahmen zu bringen, kann man jetzt einfach einen der neuen Begriffe benutzen. Ich hoffe, es ist klar, wie das gemeint ist. "xvalues" hat es vorher (C++98, C++03) einfach nicht gegeben. In C++0x gibt es sie aber und sie haben sowohl Eigenschaften von lvalues als auch Eigenschaften von rvalues. Und so kann man sich auch das x merken... x = Kreuzung oder eXpendable (entbehrlich im Sinne der Move-Semantik). Ich kann mir nur auf das 'gl' in "glvalues" keinen Reim machen...

[krümelkacker]

Sehr geil finde ich aber auch, dass eine überarbeitete (noch nicht öffentlich verfügbare) Version von N3044 akzeptiert wurde [1]. Damit kann ein Compiler automatisch Move-Konstruktoren und Move-Zuweisungen unter gewissen Umständen erzeugen.

[1] comp.std.c++ Diskussion

[krümelkacker]

Ben04 schrieb:

Aber Concepts hätte ich schon gern gehabt. Oder zu mindest irgendetwas was den typename Foo::template Bar<typename Blub::Bla>-Quark leichter zu lesen macht.

Ich hätte gerne so etwas wie Concepts gehabt, was nicht ganz so kontrovers angesehen wird. Ich finde die Idee an sich super. Aber hast Du mal versucht, das Feature im Detail zu verstehen? Ich behaupte, dass es die wenigsten Leute aus dem Komitee richtig verstanden haben. Der Verantworliche der LWG (Howard Hinnant, LWG = library working group) hat sogar offen zugegeben, dass er sich nicht zutrauen würde, Concepts in die StdLib einzubauen und auf die Expertise von anderen angewiesen ist, weil es keinen stabilen Compiler gibt, der die aktuellste Version des Concepts-Proposals implementiert und mit dem man hätte testen können.

Dann lieber beim nächsten Mal...

[Ben04]

krümelkacker schrieb:

Aber hast Du mal versucht, das Feature im Detail zu verstehen?

Ich kenne mich mit der Problematik aus. Man hat versucht zu viele Teilprobleme mit einem großen Hammer zu erschlagen und ist dabei gescheitert. Wenn man die Teile separat angegangen hätte, dann hätte man für viele Fortschritte erreicht. So hat man gar nichts erreicht und unter anderem dieser typename-Blödsinn lebt weiter.

Die älteren GCCs konnten ohne weiteres auch im Templatekontext ohne typename überleben, dann kam der Standard und hat dafür gesorgt, dass die Länge der Typnamen sich etwa verdreifacht haben ohne, dass es für den Programmier den geringsten Mehrwert gegeben hätte. So etwas nennen dann wohl einige Fortschritt.

Es gibt einfach so viele Stellen an denen der Standard einfach nur Müll ist. Ein paar davon werden nun auch aufgeräumt aber viele bleiben und die Vorstellung, dass das wieder etwa 15 Jahre dauern soll bis sich etwas ändern macht mich traurig.

[krümelkacker]

Ben04 schrieb:

So hat man gar nichts erreicht und unter anderem dieser typename-Blödsinn lebt weiter.

Naja, Blödsinn ist das ja nicht. Und bei Concepts denke ich in erster Linie an das "constraining" von Templates und weniger daran, dass ich irgendwo typenames sparen kann. Wir haben ja auch noch auto und decltype.

Ben04 schrieb:

Die älteren GCCs konnten ohne weiteres auch im Templatekontext ohne typename überleben, dann kam der Standard und hat dafür gesorgt, dass die Länge der Typnamen sich etwa verdreifacht haben ohne, dass es für den Programmier den geringsten Mehrwert gegeben hätte. So etwas nennen dann wohl einige Fortschritt.

Der "Mehrwert" ist das Zwei-Phasen-Lookup, mit dem auch einige Fehler schon vor dem Instanziieren eines Templates gefunden werden können. Ich finde das eigentlich eine super Idee. Je eher/vollständiger ein Template überprüft werden kann, desto besser. Concepts geht ja in dieselbe Richtung. Ich habe aber mit dem alten pre-Standard-Verhalten, also ohne ZPL, keine Erfahrung und kann daher nicht sagen, ob das ZPL das Programmieren signifikant erleichtert hat oder nicht -- mal abgesehen davon, dass man hier und da ein typename benötigt.

Ben04 schrieb:

Es gibt einfach so viele Stellen an denen der Standard einfach nur Müll ist.

Nenne mal bitte ein paar Beispiele. Ich sehe jetzt nicht, wie man C++0x in der Zeit mit den Ressourcen, die zur Verfügung standen, hätte besser machen können.

Ben04 schrieb:

[...] und die Vorstellung, dass das wieder etwa 15 Jahre dauern soll bis sich etwas ändern macht mich traurig.

Der Plan ist zumindest ein kürzerer Entwicklungszyklus. Stroustrup will den Nachfolger von C++0x eigentlich noch in dieser Dekade sehen -- C++1y sozusagen.

[rüdiger]

http://gcc.gnu.org/projects/cxx0x.html
http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.200x

[Ben04]

Der Grund warum man typename und template überhaupt braucht ist, damit Sachen wie 1.

A::A<A::B<A::C,A:: D<A::E> >

sizeof(A::X)

ohne Typinformationen geparst werden können. In der Essenz ist es genau das selbe Problem wie mit

A<B<C>>

Letzteres hat man gefixt in dem man von den Leuten verlangt, dass sie die Operatoren einfach mit ()-Klammern umgeben. Wenn man das einfach konsequent immer fordern würde, dann wären die typenames & templates in 1. auch überflüssig.

Dann bleiben noch Exoten wie 2. wo man tatsächlich auch dann nicht aus dem Kontext entscheiden kann, ob ein Typ oder eine Variable gemeint ist, weil beides gültig ist.

In der ersten Phase kann der Compiler aber eh nur eine Verwendung eines A::X einmal als Typ und einmal als Variable als Fehler ankreiden. Mehr kann er gar nicht mit der Information anfangen. (Eventuell braucht man die Information noch um export zu implementieren aber das wurde ja entfernt.) In den Situationen wie 2. ist es aber völlig egal was A::X ist, weil es in jedem Fall gültig ist und des Wegen in jedem Fall keine Fehlermeldung geben würde.

Du siehst man kann auch ein ZPL ohne typename & template machen.

ZPL findet nur Fehler die bei jeder Instanziierung eh gefunden worden wären. Das heißt es bringt nur etwas für Templates die nie instanziiert werden. Das ist ein Vorteil, aber einer den du mit der Luppe suchen musst.

Concepts hätten den typename&template-Quark wahrscheinlich bedeutungslos gemacht, da wahrscheinlich niemand mehr unconstrainted Parameter verwendet hätte.

krümelkacker schrieb:

Ben04 schrieb:

Es gibt einfach so viele Stellen an denen der Standard einfach nur Müll ist.

Nenne mal bitte ein paar Beispiele.

Siehe oben für ein erstes Beispiel.

Ein weiteres (umstrittenes) Beispiel sind C-Regeln für void*. Jeder der void* verwendet scheißt auf Typsicherheit an der Stelle und ist sich dessen vollends bewusst. Typcasts nerven also nur und bringen eh keine zusätzliche Sicherheit, weil der Programmier eh nur castet bis der Compiler das Maul hält. Man kann nun sagen, dass void* allgemein böse ist, dann soll man es aber bitte einfach ganz entfernen. Mit char* und ein paar zusätzlichen Casts kommt man auch ohne aus. Der aktuelle Weg ist nichts Halbes und nix Ganzes.

Dann wäre es noch sinnvoll zu erlauben private Methoden außerhalb der Klasse zu deklarieren. Diese sind ein Implementierungsdetails welches nicht benötigt werden um die Größe eines Objekts zu berechnen. Es gibt also keinen Grund warum man sie in den Header packen müssen soll.

Die neuen variadischen Parameter gefallen mir auch nicht. Warum nicht einfach

template<class T>
void f(T...t){
  // T ist ein std::tuple und t eine Instanz davon
}

und std::tuple dann direkt in den Compiler einbauen.

krümelkacker schrieb:

Der Plan ist zumindest ein kürzerer Entwicklungszyklus. Stroustrup will den Nachfolger von C++0x eigentlich noch in dieser Dekade sehen -- C++1y sozusagen.

Ich glaube, das x in C++0x war anfangs auch keine Hex-Ziffer.

EDIT: Smiley entfernt

[Old McDonald]

typename löst potenzielle Mehrdeutigkeiten auf. Gerade in generischem Code sollten die nicht passieren, da sonst total verrückte Dinge passieren können (Multiplikation statt Zeigerdeklaration und solche Sachen). Das wird in 99% der Fälle dann nicht kompilieren, doch wenn es kompiliert...
Gerade bei generischem Code in C++ weiß man nichts über den Typ, man kann nur Constraints textuell definieren. Entweder muss man also zusätzliche Constraints hinschreiben, die die Verwendbarkeit der Bibliothek unnötig begrenzen, man verschluckt die Hinweise darauf einfach (ganz schlecht) oder man zwingt den generischen (Bibliotheks-)Programmierer, immer im Quelltext explizit zu sein. Warum man nun auch den Programmierer in offensichtlichen Fällen, in denen nur Typen gehen, dazu zwingt, hat Stroustrup mal vor langer Zeit zusammengefasst: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1994/N0578.pdf
Kurz gesagt: Um den Programmierer davon abzuhalten, darüber nachzudenken, ob er jetzt ein typename schreiben muss oder nicht, er muss es einfach immer schreiben.
(Noch ein kleiner Hinweis: class ist nicht geeignet als Schlüsselwort; was wäre, wenn der Typ eine Union ist? Das wäre eine unnötige künstliche Einschränkung).
Außerdem werden auto und decltype typename seltener machen.

Concepts/Constraints wären zwar toll, aber da versuchen sich schon einige Leute seit jetzt 2 Jahrzehnten dran und es wird immer noch nicht im Standard drin sein. Es scheint doch ein eher komplexes Thema zu sein.

Die neuen variadischen Parameter gefallen mir auch nicht. Warum nicht einfach

template<class T>
void f(T...t){
  // T ist ein std::tuple und t eine Instanz davon
}

Dein Vorschlag für die variadischen Parameter wäre zumindest syntaktisch Mist. Schon mal ausprobiert, was passiert, wenn du folgende Funktion in einem heutigen Compiler definierst:

template <typename T>
void f(T...)
{
}

Daneben bin ich mir nicht sicher, ob das das Problem überhaupt löst... Du kannst ja schlecht in einer Schleife Variablen unterschiedlichen Typs definieren, wirst also vermutlich auch auf Rekursion zurückgreifen müssen wie mit dem System im aktuellen Standard (und das vielleicht noch deutlich häufiger). Ich glaube, es gibt schon gute Gründe, warum man Variadic Templates so gelöst hat und nicht anders.

Exception specifications sind im Übrigen nicht rausgeflogen; sie sind nur "deprecated", so wie auto_ptr oder die automatische Konvertierung bei Zeichenkettenliteralen von const char* nach char* . Und dafür hat man eine neue Art Exception specification eingeführt, noexcept , für den Fall, das keine Ausnahme fliegen darf/soll. Für den normalen Programmierer sieht das auf den ersten Blick so aus, wie das bisherige throw() , und es gibt wohl im Kommittee eine Mehrheit, die auch noch eine ähnliche, nahezu gleiche Semantik bei fliegenden Ausnahmen beibehalten will (nämlich direkt nach terminate() ). Aber noexcept wird man voraussichtlich viel häufiger in Code sehen als throw() , denn man wird es für Move Semantics benötigen und kann es dazu verwenden, auf No-throw-Garantien zur Compilezeit in C++ zu testen. Zumindest, wenn der Blog-Eintrag von Dave Abrahams noch einigermaßen stimmt.

[Nexus]

Ben04 schrieb:

Ein weiteres (umstrittenes) Beispiel sind C-Regeln für void*. Jeder der void* verwendet scheißt auf Typsicherheit an der Stelle und ist sich dessen vollends bewusst. Typcasts nerven also nur und bringen eh keine zusätzliche Sicherheit, weil der Programmier eh nur castet bis der Compiler das Maul hält. Man kann nun sagen, dass void* allgemein böse ist, dann soll man es aber bitte einfach ganz entfernen. Mit char* und ein paar zusätzlichen Casts kommt man auch ohne aus. Der aktuelle Weg ist nichts Halbes und nix Ganzes.

Das sieht aber sehr stark nach deiner persönlichen Meinung aus, verallgemeinern kannst du das so nicht. Kein vernünftiger Programmierer castet, bis der Compiler das Maul hält. Und Typcasts nerven sicher nicht, abgesehen davon hättest du sie bei char* erst recht, während zu void* immerhin noch eine implizite Konvertierung existiert.

Überhaupt finde ich nicht, dass void* unsinnig ist. Man schafft damit explizit einen typlosen Zeiger. Was brächte es, wenn die Leute diesen mit einem Dummy-Typen wie char assoziierten? Damit würde man nur sinnlose Operationen erlauben, wie zum Beispiel Dereferenzierung oder Zeigerarithmetik.

Ben04 schrieb:

Dann wäre es noch sinnvoll zu erlauben private Methoden außerhalb der Klasse zu deklarieren. Diese sind ein Implementierungsdetails welches nicht benötigt werden um die Größe eines Objekts zu berechnen. Es gibt also keinen Grund warum man sie in den Header packen müssen soll.

Doch, es gibt einen guten Grund dafür. Denn ganz so einfach wäre die Alternative nicht. Eine (private) Memberfunktion hat einen ganz besonderen Status: Sie darf auf alle Member der Klasse zugreifen, ungeachtet des Zugriffsspezifizierers (Basisklassen ausser Acht gelassen). Ich denke nicht, dass es so eine gute Idee wäre, dieses Privileg allen zur Verfügung zu stellen und somit die Kapselung komplett über Bord zu werfen.

Ausserdem kannst du das gewünschte Verhalten in vielen Fällen mit globalen Funktionen erreichen, wenn du ein wenig flexibel bezüglich Syntax bist.