C++1y in GCC

[asc]

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

[Artchi]

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.

[cooky451]

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.

[pyhax]

Ich fände static_message, static_if und static_warning noch cool. Und wie wäre es mit Boost.Range ?

[DrakoXP]

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

[otze]

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.

[pumuckl]

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

[cooky451]

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.

[Ethon]

DrakoXP schrieb:

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.

[cooky451]

Ethon schrieb:

Mein Autoradio kann aber mit beidem nichts anfangen.

Das kann auch mit Dateien nichts anfangen..

[Ethon]

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?

[seldon]

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.

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.

[LordJaxom]

seldon schrieb:

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]

pumuckl schrieb:

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.

[cooky451]

pumuckl schrieb:

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.

[Artchi]

Ethon schrieb:

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.

[Artchi]

Eine GUI-API im C++ Standard würde doch heute schon veraltet sein.

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.

[Artchi]

Zum XML: der Standard und die API würden ja keine Regeln definieren. Es würde doch eher darum gehen, die Struktur parsen zu lassen. Wie und nach welchen Regeln geparst wird, wäre doch Sache der Implementerung.

Aber ehrlich gesagt, ich halte es auch nicht für wichtig, das eine XML-API im Standard wäre. Weil dann müsste man ja jedes andere Datenformat auch noch aufnehmen.

Vielleicht wäre es besser sowas wie Boost Spirit aufzunehmen? Also das man es so eher ermöglicht Parser zu bauen. Der C++ Standard sollte also eher nicht Formate unterstützen, sondern das erstellen von Regeln für ein Format ermöglichen.

So wie es ja mit Asio auch der Fall ist: es ermöglicht Protokolle zu implementieren. Aber liefert nicht direkt das http-Protokoll.

[rüdiger]

Bibliotheken gibt es doch genug externe. Weder Netzwerk, Dateisysteme, XML oder GUIs finde dich wirklich interessant für C++1y. Was mich interessieren würde, wären Concepts oder static-if und natürlich ein Modulsystem. Also wirklich Erweiterungen an der Sprache und nicht einfach etwas, dass ich selbst basteln bzw. durch eine externe Bibliothek ersetzen kann.

DrakoXP schrieb:

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

Du hast wohl nie mit einer Java GUI arbeiten müssen. Aber ernsthaft, eine GUI-Lib wäre für den Standard viel zu umfangreich und müsste viel intensiver gewartet werden. Und es gibt doch zahlreiche GUI-Libs für C++ die auch plattformübergreifend sind (Qt, wxWidgets, etc.)

Ethon schrieb:

Mein Autoradio kann aber mit beidem nichts anfangen.

Ach, ich weiß nicht, was man da aktuell verbaut. Aber in Zukunft wird das doch vermutlich eh Hardware sein, die einem Smartphone entspricht. Also irgend ein ARM-Ding. Aber ja OpenGL im C++ Standard wird es nicht geben.

[LordJaxom]

Artchi schrieb:

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.

Was nicht verwundert, wenn selbst Zulieferer wie IBM und Siemens immer wieder überrascht werden von den bei uns zu erwartenden Datenmengen.