C++11 (aka C++0x) - Approval of Final Committee Draft
-
Da wäre ich ev. auch dabei... bin immerhin noch bis Ende Sommer ab und zu dort...
-
evilissimo schrieb:
Also wird aus C++0x wohl C++11
Achwas, das wird C++0B16
-
Wie auch immer - vermutlich kostet's am Ende wieder einen Haufen Geld...
-
branleb schrieb:
evilissimo schrieb:
Also wird aus C++0x wohl C++11
Achwas, das wird C++0B16
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.
-
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...
-
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
-
/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
-
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.
-
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.
-
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
-
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++)
-
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?
-
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
-
Bitsy schrieb:
Wie auch immer - vermutlich kostet's am Ende wieder einen Haufen Geld...
Meinste, danach gibts den GCC nicht mehr umsonst?
-
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.
-
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.
-
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
-
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...
-
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.
-
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...