C++1y in GCC
-
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?
-
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.
-
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 verdorbenin 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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
rüdiger schrieb:
Bibliotheken gibt es doch genug externe. Weder Netzwerk, Dateisysteme, XML oder GUIs finde dich wirklich interessant für C++1y.
Prinzipiell gebe ich dir recht, es wäre aber wünschenswert, wenn es mehr Bibliotheken gäbe die sich möglichst nahtlos in Standard C++ integrieren würden. In sofern würde ich mich auch beispielsweise über eine neue UI-Bibliothek freuen.
Aber das hat nichts mit dem nächsten Standard zu tun (oder wenn überhaupt wäre es ein optionaler Zusatzstandard zu C++).
-
otze schrieb:
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.
Und welche XML-Parser wären das dann, die standardkonform sind und auch korrekt validieren?
-
Gugelmoser schrieb:
otze schrieb:
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.
Und welche XML-Parser wären das dann, die standardkonform sind und auch korrekt validieren?
Ich formuliere die Frage mal um: Welche XML-Parser benutzt ihr so für C++?
-
RapidXML, ultraschnell und mir gefällt API/Style + es ist ne Header-only Lib.
Standardkonformität bezüglich XML geht mir am Arsch vorbei, ist mir egal was da drin steht, mir reichen einfache XML-Dokumente und die parst jeder Parser korrekt.
-
XmlLite habe ich bisher benutzt. Ist aber nichts für Leute, die Hardcore-XML-Formate parsen wollen. Dafür hat ja MS ihr MSXML. Aber ansonst ist XmlLite sehr nett, da es schon auf jedem Windows vorhanden ist.
-
Ich hab mein eigenen Kram geschrieben.
Gibt's eigentlich Benchmarks dazu? Ich weiß noch dass ich ziemlich überrascht war, dass so eine 21 MB xml Datei quasi ohne Zeitverzögerung geparst wird. Bei den ganzen <> und = hätte ich erwartet, dass das länger dauert.
-
Noch ein Nachtrag: Michael Wong: Future C++1x proposals