C++1y in GCC
-
Eben entdeckt.
http://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html
C++1y?
Was ist denn da dabei? Ich konnte nichts konkretes finden. Weiß da jemand was?/pi
-
314159265358979 schrieb:
Eben entdeckt.
http://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html
C++1y?
Was ist denn da dabei? Ich konnte nichts konkretes finden. Weiß da jemand was?Steht doch dabei: der vorläufige Namen für den nächsten Standard (nach C++11), derzeit für 2017 geplant. Es gibt sehr viel was nicht in den C++11 Standard aufgenommen, und auf später verschoben wurde (z.B. ein Modulsystem), ebenso könnten noch weitere Neuheiten hinzu kommen.
Da die Standardisierung selbst im besten Fall 5 Jahre in der Zukunft liegt, sollte dir das heute noch keine Schmerzen bereiten. Bei anderen Sprachen finden Neuerungen teilweise wesentlich schneller Einzug...
-
asc schrieb:
Da die Standardisierung selbst im besten Fall 5 Jahre in der Zukunft liegt, sollte dir das heute noch keine Schmerzen bereiten. Bei anderen Sprachen finden Neuerungen teilweise wesentlich schneller Einzug...
Diese Mal hat man sich vorgenommen, schnell zu machen. Wird bestimmt klappen. Ganz sicher.
-
Wenn man das mal mit dem Dreisatz überschlägt: aus 10 Jahren sind 13 geworden. Aus den angepeilten 5 Jahren werden vielleicht 7.
Vielleicht klappts ja dieses mal doch schneller und das "1y" wird 18 oder weniger. Es soll ja höchstens nur ein "major language feature" hinzukommen und dann eben noch Bugfixes (und Libraries?).
-
Naja, diesmal hat man ja, wenn man zu Hex aufrüstet, bis 2031 Zeit.
-
seldon schrieb:
Naja, diesmal hat man ja, wenn man zu Hex aufrüstet, bis 2031 Zeit.
Dann ist Struppi vermutlich nicht mehr.
-
314159265358979 schrieb:
seldon schrieb:
Naja, diesmal hat man ja, wenn man zu Hex aufrüstet, bis 2031 Zeit.
Dann ist Struppi vermutlich nicht mehr.
Und C++ wohl auch nicht mehr.
-
Das bezweifle ich.
-
314159265358979 schrieb:
Das bezweifle ich.
Wenn sich die nächsten 20 Jahre nichts ändert? Das wäre eine sehr harte Probe.
Da ist genügend Zeit einige bessere General-Purpose Sprachen zu entwickeln und gut umzusetzen.
-
Ethon schrieb:
Und C++ wohl auch nicht mehr.
Bei der typischen Lebensdauer von Anwendungen wirst du mit deiner Einschätzung wohl falsch liegen (es sei den die Menschheit schafft sich vorher ab).
-
Concepts und Modul-System müssen noch rein.
Ansonst wird es nur Bugfixes und noch viele Bibliotheken dazu kommen. Da fallen spontan die TR2 Bibliotheken ein: Netzwerk (Kandidat: Boost Asio), XML und Filesystem.
Das ist nicht sehr viel, wird also bestimmt 2017.
-
xml ist doch eher uninteressant, das kann sich jeder selbst in 20 Minuten selbst machen oder irgendeine lib nutzen. Jedenfalls reicht Standard-C++ dafür völlig aus - weswegen ich nicht so ganz verstehen konnte, warum Sutter den Kram so toll fand. Netzwerk und Filesystem dagegen sind klare TR vor C++1y Kandidaten, denn dafür muss man sonst immer irgendwelchen Systemkram kapseln.
-
Ich fände static_message, static_if und static_warning noch cool. Und wie wäre es mit Boost.Range ?
-
eine GUI wäre noch hübsch
evtl. auch noch OpenGL Integration in den Standard, um mal DirectX etwas entgegen zu wirken :p
-
cooky451 schrieb:
xml ist doch eher uninteressant, das kann sich jeder selbst in 20 Minuten selbst machen.
Dann schreib mal einen Standardkonformen XML-Parser in 20 Minuten. Soweit ich weiß gibt es von allen XML-Parser implementationen nur eine Handvoll, die genau das tun, was der Standard verlangt - und noch weniger die korrekt validieren.
Deswegen ist ja XML so ein beklopptes Format.
-
DrakoXP schrieb:
eine GUI wäre noch hübsch
Wirds kaum geben, da gibts wichtigere Dinge. Außerdem wirds schwer da was Plattformübergreifendes sauber zu definieren, die verschiedenen Systeme haben ja doch alle ihre Sonderlocken.
evtl. auch noch OpenGL Integration in den Standard, um mal DirectX etwas entgegen zu wirken :p
Dazu gibts zu viele anderweitige Interessenvertreter im Kommitee.
Die Themen sind beide zu wenig "general purpose", um in C++ aufgenommen zu werden.
Ich bin gerade auf der Parallel2012, nach dem allgemeinen Tenor hier sollte eher ein wenig mehr mid-level und high-level Parallelisierungsmöglichkeiten in den Standard kommen (Threadpools, lightweight Tasks,...)
-
otze schrieb:
Deswegen ist ja XML so ein beklopptes Format.
Hehe stimmt, der Standard scheint echt übel zu sein. Zumindest kann man sich in 20 Minuten einen Parser bauen, der alle "üblichen" xml Dateien problemlos parsen kann. Vor allem aber braucht man dafür nichts, was über Standard-C++ hinaus geht. Und das war der eigentliche Punkt. Ich finde es wesentlich unangenehmer, Systemzeug kapseln zu müssen. Also über Netzwerk, GUI, Maus, Tastatur, Gamepad, würde ich mich wesentlich mehr freuen, als über irgendwelche xml Parser oder Threadpools.
-
DrakoXP schrieb:
eine GUI wäre noch hübsch
evtl. auch noch OpenGL Integration in den Standard, um mal DirectX etwas entgegen zu wirken :pMein Autoradio kann aber mit beidem nichts anfangen.
asc schrieb:
Ethon schrieb:
Und C++ wohl auch nicht mehr.
Bei der typischen Lebensdauer von Anwendungen wirst du mit deiner Einschätzung wohl falsch liegen (es sei den die Menschheit schafft sich vorher ab).
COBOL ist genauso lebendig, wie ein Hirntoter an der Beatmungs- und Ernährungsmaschiene. Wenn C++ in 20 Jahren genauso genutzt wird wie jetzt COBOL, ist es auch tot, auch wenn noch Legacy-Code existiert.
-
Ethon schrieb:
Mein Autoradio kann aber mit beidem nichts anfangen.
Das kann auch mit Dateien nichts anfangen..
-
cooky451 schrieb:
Ethon schrieb:
Mein Autoradio kann aber mit beidem nichts anfangen.
Das kann auch mit Dateien nichts anfangen..
Wie denkst du, liest es Musik von der CD und vom USB-Stick?
