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

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

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.

Naja, diesmal hat man ja, wenn man zu Hex aufrüstet, bis 2031 Zeit.

Dann ist Struppi vermutlich nicht mehr.

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.

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.

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

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.

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.

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,...)

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.

eine GUI wäre noch hübsch
evtl. auch noch OpenGL Integration in den Standard, um mal DirectX etwas entgegen zu wirken :p

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

Mein Autoradio kann aber mit beidem nichts anfangen.

Das kann auch mit Dateien nichts anfangen..

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?

Allerdings hat COBOL ein bisschen was von einem Sonderfall, weil es so eine Art Programmiersprache für Nicht-Programmierer ist (bzw. sein will). Wenn wir hier über Visual Basic sprächen, könnte man COBOL als Vergleich heranziehen, aber C++ befindet sich in einer ganz anderen Lage. Ich halte es für wahrscheinlicher, dass nach dem nächsten großen Wurf, der die objektorientierten und generischen Paradigmen überholt, C++ einen Stellenwert gewinnt wie heute C. Letztendlich ist das aber alles Kaffeesatzleserei -- wenn ich wüsste, wie der nächste große Wurf aussehen wird, wäre ich jetzt damit beschäftigt, berühmt zu werden.

Ich denke, dass du den Zustand von COBOL (leider) falsch einschätzt. Es ist ja nicht nur Legacy-Code, es sind auch Legacy-Coder, die ihre Betriebslogik seit Jahrzehnten darin umsetzen und nicht damit genervt werden wollen, sie müssten neue Sprachen lernen. Der neueste COBOL-Standard ist denn auch aus dem Jahr 2002.

Ich denke, dass Du den Zustand von COBOL auch noch nicht richtig einschätzt. Es sind ja nicht nur Legacy-Coder, in dem Betrieb, in dem ich arbeite, werden jedes Jahr neue Entwickler mit COBOL verdorben in COBOL ausgebildet, weil Berechnungen immernoch überwiegend in COBOL formuliert werden.

(Für Interessierte: Das Berechnungs- und Drucksystem für Steuerbescheide RPFEST, welches gerade bundesweit eingeführt wird, ist komplett in COBOL codiert und berechnet Steuern nach den Gesetzen und Gesetzesänderungen von 1970 bis heute. Sowas wird auch in den nächsten 20 Jahren nicht einfach in einer anderen Sprache neu entwickelt.)

Allerdings hat COBOL ein bisschen was von einem Sonderfall, weil es so eine Art Programmiersprache für Nicht-Programmierer ist (bzw. sein will). Wenn wir hier über Visual Basic sprächen, könnte man COBOL als Vergleich heranziehen, aber C++ befindet sich in einer ganz anderen Lage.

Würde ich so auch nicht (mehr) sagen, zumindest nicht seit Visual Basic zu einer alternativen Ausdrucksform von C# geworden ist.

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.

Darüber lässt sich streiten, Java (und ich verabscheue Java...) schafft es schließlich auch irgendwie.

Ethon schrieb:

Mein Autoradio kann aber mit beidem nichts anfangen.

Das ist ja auch nicht weiter schlimm.
Es ist ja nicht zwangsläufig erforderlich, dass ein Compiler für dein Autoradio diese Teile der Bibliothek mitbringt.

Mit dem avr-gcc hat man auf dem Microcontroller auch nicht die komplette C-Standardbibliothek zur Verfügung.

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.

Und es gibt Systeme, die haben gar keine GUI. Aber ich denke genau von dem Gedanken, das dann auszuschließen muss man sich verabschieden. Dafür ist es ja schließlich in der Standardbibliothek, und nicht in der Sprache selbst. Ansonsten wäre ja schon bei Dateien schluß gewesen. Oder bei Threads. Oder bei Sockets. Denn wir wollen ja beides: Die Sprache soll so maschinenunabhängig wie möglich sein, aber gleichzeitig viel Komfort bieten. Beides zusammen geht halt nur, wenn man sagt Feature XYZ ist nicht überall vorhanden.

Ethon schrieb:

Wie denkst du, liest es Musik von der CD und vom USB-Stick?

Dann ist es ja schon mehr als ein Radio.

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.

Nein, das stimmt nicht. Bei uns wird noch fröhlich neuer COBOL-Code geschrieben und neue Cobol-Projekte gestartet. Du arbeitest wahrscheinlich nicht in der entsprechenden Industrie, um zu wissen welche Anforderungen Cobol heute erfüllt, die andere Sprachen nicht tun.

Es werden hier bei uns auch händeringend Cobol-Programmierer gesucht, da viele aktuelle Kollegen vor der Rente stehen.

Das Problem ist, das Cobol echt ätzend ist. Aber es erfüllt seinen Zweck wohl am besten, wenn es um Massentransaktionen geht. Und ich wette, unter Massentransaktionen verstehst du wahrscheinlich was falsches. Die Transaktionen pro Tag, an die du vielleicht denkst, sind wahrscheinlich lächerlich ggü. der realen Zahl.

Nicht nur das die GUIs auf jedem System total andere Konzepte haben, sie ändern sich auch alle paar Jahre drastisch. Man muß nicht aufzählen, was KDE, WIndows, OSX, iOS, Android, S60, Metro usw. für Unterschiede haben?

Was ich aber begrüßen würde, wären Dinge um Businesscode und Daten an eine GUI anzuknüpfen:

Signal-Slot API: damit könnte man zumindest einfacher Ereignisse aller Art implementieren (Menüs-Aktionen, Button-Aktionen, HID-Inputs usw.). Aber auch Datenmodelle für das MVC Pattern wären einfacher und standardisierter umsetzbar.

Die eigentliche GUI-API wäre jedoch ein extremer Kompromiss, den wahrscheinlich fast niemand nutzen wollen würde.