Herb Sutter - The Future of C++
-
0xdeadbeef schrieb:
Es gibt mit Sicherheit einige Dinge, die in einer Standardbibliothek ihren Platz hätten - Objektserialisierung ist ein gutes Beispiel, und Threads könnte man inzwischen wohl auch einbinden
Threads können nicht allein auf Bibliotheksebene integriert werden. Die Sprache muss schon ein Thread-Konzept kennen bzw. definieren.
Das wird für C++ aber hoffentlich auch bald der Fall sein, denn mit dieser "Threads-kenne-ich-nicht"-Einstellung wird C++ definitiv nicht ewig durchkommen.Ein anderes wichtiges Thema ist imo (optionale) GC. Und zwar mit sauberer Trennung zwischen Memory- und Ressourcemanagement, also ohne das auf Destruktoren verzichtet werden muss. GC ist ja auch im Zusammenhang mit Threads ein Bonus (siehe Lock-Free-Programming).
Die jetzige stdlib ist halt einfach affig und genau ein starker Grund, warum Standard C++ mich überhaupt nicht mehr reizt.
Den Punkt verstehe ich nicht. Es ist ja nicht so, dass ein C++ Programmierer als selbst programmieren muss, was nicht in der Standardlib enthalten ist. Es gibt einen riesigen Markt von C++ Bibliotheken. In allen Geschmacksrichtungen. Von akademisch über frei bis kommerziell bzw. professionell.
Dieser dezentrale Ansatz hat imo auch seine Vorteile.Es ist mir z.B. ein Rätsel wozu man eine Gui-Standardlib braucht. Nicht nur das so eine Lib imo ein Monsterding wäre, sie müsste auch am Besten noch vollständig konfigurierbar sein (z.B. brauch ich den Overhead von Portabilität ja/nein), denn es gibt ja leider nicht die "one size fits all"-Anforderungsliste für GUIs. Die Java-Leute haben sich mit Swing soviel Mühe gegeben und sind letztlich trotzdem gescheitert. Ich denke nicht, dass die C++ Leute hier besser wären.
-
HumeSikkins schrieb:
Ich denke nicht, dass die C++ Leute hier besser wären.
vorallem wenn man ewig auf aenderungen warten muss. gerade bei GUIs kann sich schnell viel tun.
mal abgesehen dass man immer das problem haben wird, dass die lib entweder zu high level ist und man nicht an das unterliegende OS kommt oder zu low level, so dass man sie sowieso wrappen muss.
-
HumeSikkins schrieb:
Threads können nicht allein auf Bibliotheksebene integriert werden. Die Sprache muss schon ein Thread-Konzept kennen bzw. definieren.
100% Zustimmung. Wenn das in C++0x nicht kommt... dann wird C++ auf Dauer für die Anwendungsentwicklung immer uninteressanter werden.
Den Punkt verstehe ich nicht. Es ist ja nicht so, dass ein C++ Programmierer als selbst programmieren muss, was nicht in der Standardlib enthalten ist. Es gibt einen riesigen Markt von C++ Bibliotheken. In allen Geschmacksrichtungen. Von akademisch über frei bis kommerziell bzw. professionell.
Dieser dezentrale Ansatz hat imo auch seine Vorteile.Hmmmm. Ich sehe keinen Vorteil darin, ein BigInteger nicht in der stdlib anzubieten. Es gibt Sachen, die will ich einfach haben, weil sie grundlegend sind, in puren C++ selber implementiert werden können und ich einfach froh bin, wenn ich nach sowas nicht erst suchen muss. Du könntest ja mal ein paar Vorteile aufzählen? Oder gilt das deiner Meinung nach nur für bestimmte libs, z.B. Networking?
Ein anderes wichtiges Thema ist imo (optionale) GC. Und zwar mit sauberer Trennung zwischen Memory- und Ressourcemanagement, also ohne das auf Destruktoren verzichtet werden muss. GC ist ja auch im Zusammenhang mit Threads ein Bonus (siehe Lock-Free-Programming).
Das Problem ist, dass z.B. in Java und C# alles so schön zusammen passt. Der GC ist cool bei Multithreading, Objektserialisierung ist bei jeglichem I/O cool, insbesondere über Sockets verschick ich oft Objekte. Die Fähigkeit, dynamisch Klassen hinzuzuladen rockt im Zusammenhang mit Reflection. Das Zeugs passt alles so gut ineinander und wenn jetzt C++ nur Reflection allein bekäme, wäre damit IMHO nicht so viel gewonnnen.
Was die Destruktoren angeht, finde ich, hast du Recht. Letztlich ist so ein finally-Block nicht so schön wie ein einfacher auto_ptr. Das ist etwas, was mich an C++/CLI sehr reizt. In C# gibts dafür ein komisches using, das muss ich mir mal ansehen.Es ist mir z.B. ein Rätsel wozu man eine Gui-Standardlib braucht. Nicht nur das so eine Lib imo ein Monsterding wäre, sie müsste auch am Besten noch vollständig konfigurierbar sein (z.B. brauch ich den Overhead von Portabilität ja/nein), denn es gibt ja leider nicht die "one size fits all"-Anforderungsliste für GUIs. Die Java-Leute haben sich mit Swing soviel Mühe gegeben und sind letztlich trotzdem gescheitert. Ich denke nicht, dass die C++ Leute hier besser wären.
Ich finde nicht, dass Swing gescheitert ist. Es ist de fakto die Standard GUI-Lib für Java und inzwischen IMHO vollkommen benutzbar. Auch das Windows Look & Feel sieht inzwischen total gut aus, hat lediglich noch ein paar kleinere Bugs, an denen man erkennen kann, dass es nicht native ist. Aber auf einen Blick sieht man das auf keinen Fall mehr. Sieh dir doch z.B. mal die NetBeans IDE für Windows an, da muss man schon nen sehr genauen Blick drauf werfen.
Wenn Swing demnächst noch OpenGL-beschleunigt wird, ist auch das Performance-Thema endgültig gegessen, obwohl es IMHO für heutige Rechner eh schon völlig passt.
Außerdem vermisse ich in der C++ lib viel elementarere Dinge als GUIs.
-
Optimizer schrieb:
Ich finde nicht, dass Swing gescheitert ist. Es ist de fakto die Standard GUI-Lib für Java und inzwischen IMHO vollkommen benutzbar. Auch das Windows Look & Feel sieht inzwischen total gut aus,
Das ist das fiese daran. es sieht fast native aus, verhaelt sich aber nicht so... das ist ein usability albtraum...
das problem mit einem standard ist: du bist fest gebunden fuer jahrezehnte daran. java kann einfach ein interface deprecaten und in 3 jahren ist es weg. passt. bei standards geht das nicht... deshalb sind viele kleinere sachen nicht sinnvoll in einer standardisierung.
biginteger hat den nachteil, dass es jeder vendor neu implementiert - wozu? da geht viel leistung verloren. da nimmt man gmp, dass ist ja quasi standard und gut ist.
natuerlich waere es super, wenn boost mehr als nur 'high end c++' waere, sondern eben auch gmp wrapper und die ganzen anderen sachen die man taeglich so braucht anbieten wuerde. das wuerde die bemuehungen zentralisieren und man haette eine extended c++ standard library die es mit jfc locker aufnehmen kann.
-
Shade Of Mine schrieb:
Optimizer schrieb:
Ich finde nicht, dass Swing gescheitert ist. Es ist de fakto die Standard GUI-Lib für Java und inzwischen IMHO vollkommen benutzbar. Auch das Windows Look & Feel sieht inzwischen total gut aus,
Das ist das fiese daran. es sieht fast native aus, verhaelt sich aber nicht so... das ist ein usability albtraum...
Ich sehe es mit jeder Version besser werden. Unter Java 5.0 fallen mir nur noch kleinere Bugs auf, der größte Teil ist IMHO voll ok.
das problem mit einem standard ist: du bist fest gebunden fuer jahrezehnte daran. java kann einfach ein interface deprecaten und in 3 jahren ist es weg. passt. bei standards geht das nicht...
Ich weiß bisher noch von keinem deprectatetem Interface/Klasse, was verschwunden ist. Java ist total abwärtskompatibel. Es ist doch eine Designfrage. Natürlich kann man ohne Probleme Swing standardisieren, weniger intelligent wäre es natürlich, dass Windows Look & Feel zu standardisieren, das muss man ja up to date halten.
Aber jetzt lass ma einfach mal die GUI.
Das ist ja gar nicht das, was ich in der C++ lib primär vermisse.biginteger hat den nachteil, dass es jeder vendor neu implementiert - wozu? da geht viel leistung verloren. da nimmt man gmp, dass ist ja quasi standard und gut ist.
Das überzeugt mich jetzt aber echt nicht. Das kann mir so egal sein, ob das Teil 50mal implementiert wird, so lange ich es nicht tun muss (oder suchen muss). Außerdem kann man wie bei Java eine Referenzimplementierung vorgeben, dann ist eine Neuimplementierung optional.
-
HumeSikkins schrieb:
Threads können nicht allein auf Bibliotheksebene integriert werden.
Genausowenig können Threads nur auf Sprachebene definiert werden. Das Betriebssystem muss die Funktionalität zur Verfügung stellen. Man kann wohl davon ausgehen, dass die meisten neueren Systeme das tun, und da Projekte wie ELKS wohl eher eine nette Spielerei als eine ernstzunehmende Anwendung sind, könnte man ein grundsätzliches Multithreading-Konzept wohl auch in die Sprache integrieren. Das heißt, man könnte es, wenn sich alle an die gegebenen Betriebssystemstandards hielten oder sich meinetwegen auch auf einen neuen einigten. Solange allerdings Microsoft an seinem eigenen Süppchen kocht und alle anderen sich an POSIX halten, dürfte ein komplexeres Konzept als in boost.thread nicht ohne eine weitere virtuelle Maschine portabel umsetzbar sein. Und so sehr ich boost.thread auch mag, es gibt eine ganze Reihe von Dingen, die es nicht kann. Es ist ein nettes Konzept und einfach anwendbar, aber für einen Sprachstandard imho nicht ausreichend.
Ein einheitliches Thread-Interface wäre eine gute Idee. Aber zuerst an der Sprache anzusetzen heißt, das Pferd von hinten aufzuzäumen. Ein Schritt nach dem anderen.
-
Optimizer schrieb:
Unter Java 5.0 fallen mir nur noch kleinere Bugs auf, der größte Teil ist IMHO voll ok.
Mir fallen genug auf. Aber man bedenke: wie lange gibt es Swing jetzt schon? Und jetzt wird es erst langsam benutzbar. denn bedenke: jeder noch so kleine bug ist eine katastrophe.
wenn es nicht native aussieht, muss es sich nicht native verhalten - aber wenn es behauptet native zu sein, ist jeder bug fatal (weil ich ja nichtmal drumherum arbeiten kann, weil ich als user ja vorher nicht weiß ob es java ist oder nicht).
Ich weiß bisher noch von keinem deprectatetem Interface/Klasse, was verschwunden ist. Java ist total abwärtskompatibel.
Und jetzt schau dir die Erweiterungen seit Java 1.0 an. stell dir mal vor, dass wäre nicht möglich gewesen und du würdest heute noch die Java 1.0 API verwenden...
Das überzeugt mich jetzt aber echt nicht. Das kann mir so egal sein, ob das Teil 50mal implementiert wird, so lange ich es nicht tun muss (oder suchen muss).
Passt doch, musst du jetzt ja auch nicht.
-
0xdeadbeef schrieb:
Das heißt, man könnte es, wenn sich alle an die gegebenen Betriebssystemstandards hielten oder sich meinetwegen auch auf einen neuen einigten. Solange allerdings Microsoft an seinem eigenen Süppchen kocht und alle anderen sich an POSIX halten, dürfte ein komplexeres Konzept als in boost.thread nicht ohne eine weitere virtuelle Maschine portabel umsetzbar sein.
es geht aber nicht nur um m$ und posix. eigentlich sämtliche multitasking-systeme (cmx, embos, ecos usw.) haben eigene proprietäre implementierungen von multitasking. zwar kennen alle gewisse mechanmismen (threadsynchronisation, datenaustausch etc. haben alle wohl die selben lehrbücher gelesen
) aber die unterschiede im einzelnen sind teilweise doch recht gross. alle haben eigene c-apis und warum sollte c++ multithreading können d.h den kleinsten gemeinsammen nenner beherrschen?
-
@0xdeadbeef
Soweit ich weiß wollen die C++ Leute im Punkte Threads einen Schritt weiterkommen. MT gibt es jetzt schon seit Jahrzenten, trotzdem hängt man bei den Abstraktionsmitteln immer noch bei low-level-Konzepten wie Mutexen oder hui Monitoren (zumindest in den aller Welt Sprachen wie Java und C#). Adas Rendevouz-Konzept ist nach wie vor noch das höchste der Gefühle.
Hier braucht's eine wirkliche Weiterentwicklung. Ob die C++ Leute da was schaffen, keine Ahnung. Cool wäre es aber.
-
Shade Of Mine schrieb:
wenn es nicht native aussieht, muss es sich nicht native verhalten - aber wenn es behauptet native zu sein, ist jeder bug fatal (weil ich ja nichtmal drumherum arbeiten kann, weil ich als user ja vorher nicht weiß ob es java ist oder nicht).
Swing muss ja auch nicht nativ aussehen, das kann man sich alles schön einstellen. Das kann sogar der Endanwender einstellen, das muss nicht mal hardgecodet sein. Du persönlich magst natürlich native GUIs. Ich auch.
Mit Swing sind Sachen möglich, die es sonst nicht gibt. Die rumzeichnerei hat seine Vorteile. Ich hab ne nativ aussehende GUI, aber mit Verbesserungen, so dass ich auch nen Button in ne Table Cell tun kann (als Beispiel). Dafür nehme ich auch erstmal minimale Bugs in Kauf, die aber wirklich schon gut gefixed sind. Mich stören sie ja auch, aber es ist nicht trivial, eine plattformübergreifende GUI-Lib zu schaffen. GTK schaut einfach nur schlecht aus, obwohl es die nativen Widgets benutzt, AWT auch. Ich kann es mir nicht ganz erklären, warum es so ist, aber scheinbar ist sowas auch nicht die Lösung.
-
Optimizer schrieb:
Ich hab ne nativ aussehende GUI, aber mit Verbesserungen
Was zwar hübsch aussieht, aber eine usability katastrophe ist.
-
Das muss IMHO der Programmierer selber wissen, was er dem Benutzer zumuten kann.
-
Ich finde auch das C++ von den grundsätzlichen Sprachmöglichkeiten schon sehr schick ist. Das einzige und leider auch das wichtigste für einen Anwendungsentwickler fehlt - Eine Standardlib die einfach nahezu alles ausser GUI's kann.
Das Problem jetzt ist, dass man für jeden Zweck eine Lib hat. Jedesmal muss man in einer anderen Doku nachschlagen, auf vielen Seiten nach Bugfixes suchen und und und.
Bei Java hab ich das nicht. Eine große Doku, die ich immer auf einem zweitem Desktop geöffnet hab und eine zentrale Stelle für Bugfixes.
Dennoch finde ich C++ von bestimmten Sprachfeature wie Templates und Adressprogrammierung einfach manchmal schöner.
Aber wenn C++ nicht einen vernünftigen neuen Standard rausbringt, wird es wirklich bald für Anwendungsentwickler immer nutzloser. Gerade zur Zeit wo Java von wirklich großen IT Firmen gefördert wird.
Früher war Java einfach viel zu langsam, da nahm man gerne den Mehraufwand von C++ in kauf. Heute ist Java durch JIT in vielen Bereichen ähnlich schnell. GUI's sind natürlich langsamer aber auch das ist in Zeiten von 2.8 GHz und mehr kein Problem mehr.
-
weiß denn schon jemand was alles in den neuen standard einfließen wird?
-
ich verstehe irgendwie nicht, warum man die lib nicht einfach staffelt?
dann gibt es halt eine grund-lib mit den features, die es jetzt gibt, dann kommt eine netzwerk-lib mit sockets, eine gui-lib, usw.
plattformen, die eins davon nicht unterstützen, haben es dann einfach nicht (z.b. netzwerk oder gui bei microcontrollern).dieses lib-wirrwar ist doch einfach nicht schön. für alle möglichen grundlegenden sachen muss man erst im internet suchen. dann haben die alle noch redundanzen. das fängt schon bei den unterschiedlichen string-klassen an...
-
mathik schrieb:
ich verstehe irgendwie nicht, warum man die lib nicht einfach staffelt?
dann gibt es halt eine grund-lib mit den features, die es jetzt gibt, dann kommt eine netzwerk-lib mit sockets, eine gui-lib, usw.
plattformen, die eins davon nicht unterstützen, haben es dann einfach nicht (z.b. netzwerk oder gui bei microcontrollern).dieses lib-wirrwar ist doch einfach nicht schön. für alle möglichen grundlegenden sachen muss man erst im internet suchen. dann haben die alle noch redundanzen. das fängt schon bei den unterschiedlichen string-klassen an...
100% ACK!
Genau deswegen haben Java und C# so einen Zulauf! Hätte C++ eine Standardlib wie Java, dann würde es in der Software-Welt ganz anders aussehen!
-
Dafür gäbe es dann für wesentlich weniger Maschinen überhaupt erst C++. Heute kann man es auf allen Maschinen einsetzen, vom kleinsten Microcontroller bist zum größten Mainframe. So eine umfassende Library lässt sich halt nicht auf jeden Microcontroller portieren, die haben ja nichtmal ein Betriebssystem. Deshalb läuft wohl auch Java nicht darauf.
-
Ringding schrieb:
Dafür gäbe es dann für wesentlich weniger Maschinen überhaupt erst C++. Heute kann man es auf allen Maschinen einsetzen, vom kleinsten Microcontroller bist zum größten Mainframe. So eine umfassende Library lässt sich halt nicht auf jeden Microcontroller portieren, die haben ja nichtmal ein Betriebssystem. Deshalb läuft wohl auch Java nicht darauf.
lies nochmal meinen beitrag und den vom "Entwickler" ...
-
mathik: Überleg doch mal bitte, was das Wort Standard bedeuten könnte.
-
Ringding schrieb:
Heute kann man es [c++] auf allen Maschinen einsetzen, vom kleinsten Microcontroller bist zum größten Mainframe.
auf kleinen µc's (8 und 16 bitter) ist c++ aber nicht so beliebt. da hat man oft noch nicht mal malloc/free, keine fliesskommarechnung, abgespecktes printf usw. also hat c++ mit seinen speicherhungrigen oo-features da auch nix verloren. ich kenne ein projekt auf 'nem 68hc12 da steckt unheimlich viel software in 128k flash und 8k ram. ca. 95% c-code, rest asm. mit c++ hätte man da keine chance gehabt
