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

[Bitsy]

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

[Simon2]

branleb schrieb:

evilissimo schrieb:

Also wird aus C++0x wohl C++11

Achwas, das wird C++0B₁₆

Wieso schon auf 16 festlegen? Das schränkt die Gültigkeit des Ausdrucks "C++0x" unnötig ein.
(vielleicht wird's ja tatsächlich erst 2024 was - damit hätte die Angabe von Vorneherein gestimmt )

Gruß,

Simon2.

[krümelkacker]

Dravere schrieb:

August 2-7, 2010: Rapperswil, Switzerland

!!!!
Kann man da hin?

siehe comp.std.c++ Diskussion.

So so. FCD... dann heißt das wohl, dass der nächste Entwurf nach N3035.pdf der "FCD" wird und damit der letzte kostenlos öffentlich erhältliche Entwurf des kommenden Standards sein wird.

Ich finde, es ist genau die richtige Mischung an Neuheuten dabei. Bin auch froh, dass "concepts" vorerst rausgeflogen ist. Ich habe die Entwicklung von "concepts" interessiert verfolgt und viel Zeit investiert, all die Details zu verstehen. Das Ergebnis konnte man in der Form IMHO keinem zumuten. Ich bin mal gespannt, wie "concepts" beim LLVM C++ Compiler aussehen werden. So, wie ich das verstanden habe, will Doug Gregor sich da austoben. Das wird man hoffentlich vernünftig testen können. ConceptGCC war ja absolut nicht zu gebrauchen.

Variadische Tempaltes, Lambdas, Rvalue-Referenzen, auto, decltype, und all die Library Features sind doch toll...

[*rant*]

I like. Ich werde dort sein; immerhin bin ich inzwischen sogar an der HSR eingeschrieben. Die ETH mag ja eine der besten Universitäten sein, aber die HSR ist viel schöner. Da fällt man einmal aufs Maul und schon ist man am See :p

[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.