Herb Sutter - The Future of C++
-
ne. die ist in ordnung.
-
zufriendener schrieb:
ne. die ist in ordnung.
Aber sicher nur mit dem Windows-Media-Player selbst wenn überhaupt.
-
nman: Geht bestimmt auch unter Linux, wenn Du Dir das Windows-Codec-Paket fuer XINE installierst.
Vielleicht guck ich mir das heute abend mal an.
Ich kann euch gleich sagen, dass Microsoft die CLR pushen wird; die wollen, dass man auf .NET-Programmierung umsteigt. (Egal ob mit Managed C++ fuer .NET oder C# oder sowas)
Ich finde den Trend zu Java und C# etwas beunruhigend, aber es hat auch Vorteile: weitestgehende Plattformunabhaengigkeit, leichtere Erlernbarkeit.
Nachteile sind ganz klar die Performance (weder Sun noch Microsoft kriegen es auf die Reihe eine vernuenftige Virtuelle Maschine zu entwickeln), sowie der Strom unerfahrener Entwickler, die noch schlechtere Anwendungen entwickeln werden, als die, die wir bisher gewoehnt sind. (da ja solche Probleme wie Abstuerze durch fehlerhafte Speicherwaltung, ungueltige Pointerzugriffe usw., unter den Tisch fallen, wodurch solche Produkte zur Marktreife gelangen koennen)
C++ wird weiterhin dort eingesetzt werden, wo volle Kontrolle ueber den Ablauf einer Anwendung erforderlich ist, und dort, wo Geschwindigkeit eine Rolle spielt.
Falls Microsoft tatsaechlich den Windows API aus der uebernaechsten Windows-Generation entfernt, muessen wohl viele Anwendungen auf .NET portiert werden -- oder aber es wird zu einem Boom von GNU/Linux kommen ...
-
Power Off schrieb:
Nachteile sind ganz klar die Performance (weder Sun noch Microsoft kriegen es auf die Reihe eine vernuenftige Virtuelle Maschine zu entwickeln), sowie der Strom unerfahrener Entwickler, die noch schlechtere Anwendungen entwickeln werden, als die, die wir bisher gewoehnt sind.
Dir ist natürlich schon klar, dass auch diese Aussagen einen Flamewar provoziert? Es gibt genügend Benchmarks, die das Gegenteil aussagen. Natürlich sind die meistens von Verfechtern der entsprechenden Sprache erstellt, aber so pauschal klingt deine Aussage schon sehr voreingenommen.
(da ja solche Probleme wie Abstuerze durch fehlerhafte Speicherwaltung, ungueltige Pointerzugriffe usw., unter den Tisch fallen, wodurch solche Produkte zur Marktreife gelangen koennen)
Das hört sich auch, als wäre genau das ein Nachteil?! Es ist ja nicht so, als wenn es keine "marktreifen" Produkte gäbe, die voll von Memory- Ressourcen Leaks wären. Nur weil einer Sprache einfacher zu lernen ist, müssen die darauf aufbauenden Produkte nicht schlechter sein. Oder verstehe ich dich falsch?
-
Bitte jetzt keine Java vs. C++ Diskussion!!!
Völlig UNINTERESSANT in diesem Topic!Also, wer kann hier was konstruktives Beitragen und vielleicht stichwortartig das Interview zusammenfassen. Ich selbst (und viele andere vielleicht auch) kann Englisch nicht hören verstehen, muß wenn dann lesen.
-
Power Off schrieb:
Nachteile sind ganz klar die Performance (weder Sun noch Microsoft kriegen es auf die Reihe eine vernuenftige Virtuelle Maschine zu entwickeln)
Also das halte ich für Schwachsinn.
Ich habe zwar noch nichts ernsthaftes mit .net Sprachen gemacht, aber es gibt zahlreiche Benchmarks, die besagen, das C# schneller ist als C++. Damit ist zwar nicht gesagt, dass das pauschal so ist, aber es sagt aus, das es möglich ist Anwendungen unter C# (oder jeder anderen .net sprache) zumindest gleich schnell als unter C++ zu kriegen. Wobei es vielleicht sogar mit .net leichter ist vernünftige Performance zu kriegen.
Das einzige was mich an .net stört, ist die Abhängigkeit von Microsoft. Ich glaube irgentwo aufgeschnappt zu haben, das MS sogar Mono unterbinden will. Weis dazu jemand was genaueres?
-
ChockoCookie schrieb:
Also das halte ich für Schwachsinn.
Offtopic!
ChockoCookie schrieb:
Das einzige was mich an .net stört, ist die Abhängigkeit von Microsoft. Ich glaube irgentwo aufgeschnappt zu haben, das MS sogar Mono unterbinden will. Weis dazu jemand was genaueres?
Offtopic! Aber MS kann mono nicht stoppen, da die CLI und das Basisframework in der ECMA ist. Also ein freier Standard den MS selbst reingebracht hat. Die wollen also, das andere die CLI und das Basisframework implementieren.
Aber egal, kann man hier vielleicht mal über das Interview diskutieren?
-
Hallo,
bitte führt die Diskussionen zum Thema C# vs. C++ vs. Java in einem Extrathread im RUDP-Forum. Dieser Thread hat bereits ein anderes Thema. Und wir Programmierer sollten wenn möglich immer nach "high cohesion" streben, also "ein Thread - ein Thema".
-
Power Off schrieb:
nman: Geht bestimmt auch unter Linux, wenn Du Dir das Windows-Codec-Paket fuer XINE installierst.
Von xine halte ich nix, und der mplayer gibt das natürlich wieder, aber die Qualität ist eben ziemlich bescheiden.
-
Es mag ja sein, dass .NET ein ECMA-Standard ist, aber das ist angesichts der vielen Patente, die Microsoft auf .NET hält bzw. erhalten will (manche sind noch im application-Stadium), recht egal. Was meint ihr wohl, warum MS sich nicht ans w3c gewendet hat? Die erlauben keine patentierte Software in ihren Standards.
Siehe dazu z.B. http://www.heise.de/newsticker/meldung/34434
Mit anderen Worten - das mit C# und Plattformunabhängigkeit halte ich für ein Gerücht.
Was das Video angeht, die Qualität ist wirklich grottig. Das man nichts sieht, ist ja OK, aber dass das Weißrauschen im Hintergrund bald lauter als die Sprache ist...ich hab jedenfalls nur so zwei Drittel verstanden. Jedenfalls hab ich ausgeschaltet, als er (wenn ich das richtig verstanden habe, es war, wie gesagt, nicht sonderlich gut zu hören) anfing, generics und templates über den selben Kamm zu scheren. Wenn ich das richtig verstanden habe, hat er das generische Programmierparadigma (das generics nicht umsetzen) nicht verstanden, was seine Meinung über die Zukunft von C++ für mich ziemlich unerheblich macht.
-
0xdeadbeef schrieb:
Jedenfalls hab ich ausgeschaltet, als er (wenn ich das richtig verstanden habe, es war, wie gesagt, nicht sonderlich gut zu hören) anfing, generics und templates über den selben Kamm zu scheren. Wenn ich das richtig verstanden habe, hat er das generische Programmierparadigma (das generics nicht umsetzen) nicht verstanden, was seine Meinung über die Zukunft von C++ für mich ziemlich unerheblich macht.
Du hast hier scheinbar nicht zwei Drittel nicht sondern absolut gar nichts
verstanden. Weder kehrt er Generics und Templates über den selben Kamm noch behauptet sie seien äquivalent. Und über generischer Programmierung redet er auch nicht.Er sagt an der Stelle, dass C++ die Systemsprache von .Net ist und das C++ die Sprache ist, die dem Programmierer die meisten Möglichkeiten zur Verfügung stellt (sie kommt am Nächsten an die virtuelle Maschine ran).
Dann bringt er ein Beispiel: nämlich Generics und zwar ganz speziell Generic-Types. Die sind ein neues Feature in .Net 2. In C++ hingegen sind Generic-Types aber in Form von Templates nichts neues. Allerdings sind Templates im Gegensatz zu Generics nicht "cross-language"-fähig. D.h. du konntest zwar in Managed-C++ Templates verwenden, diese aber nicht anderen .Net-Sprachen zur Verfügung stellen (was mit den runtime-Generics natürlich geht). Er sagt dann extra, dass er nicht weiter in die Richtung "Templates vs Generics" (oder deren Äquivalenz) bohren möchte sondern dass es vielmehr wichtig ist nicht eines der beiden Features als "besser" als das andere darzustellen. Keines ist inhärent besser. Templates und Generics sind verschieden aber komplementär.
Dann sagt er noch, und das ist jetzt der entscheidene Punkt, dass es cool ist beides zu haben und das man Generics zwar in allen .Net-Sprachen benutzen kann (C#, VB usw.), man in C++ aber diesbezüglich weitrechende Möglichkeiten hat, da C++ mehr der "underlying features" zur Verfügung stellt. Sprich: Generics aus Sicht der CLR bieten mehr Möglichkeiten als die Sprachen C# und VB zur Verfügung stellen. C++ hingegen gewährt vollen Zugriff.
Den Punkt den er macht ist der, dass C++ mit seiner Design-Philosophie "Trust the programmer" flexibler als andere Sprachen ist. Diese Flexibilität ist aber auch nicht immer ein Vorteil, wie er ja später auch noch erklärt.Wenn ich das richtig verstanden habe, hat er das generische Programmierparadigma (das generics nicht umsetzen) nicht verstanden, was seine Meinung über die Zukunft von C++ für mich ziemlich unerheblich macht
Also ich denke das du problemlos davon ausgehen kannst, dass Herb Sutter (einer der C++ Top-Experten, Autor von vier weltweit anerkannten C++ Standardwerken und unzähligen Artikeln sowie Vorsitzender des C++ Standardkomitees) generische Programmierung verstanden hat.
Da Herb Sutter die Entwicklung von C++ seit jahren intensiv verfolgt und
auch beeinflusst (mittlerweile gleich an zwei Fronten - einmal über CLI/C++ und einmal über das Standard-Komitee), denke ich, dass man seiner Meinung zum Thema "C++ in der Zukunft" schon gehör schenken sollte. Genauso wie der von solchen unbekannten Leuten wie Bjarne Stroustrup oder P.J. Plauger.
-
ich fand die qualität ganz in ordnung. und der ton war auch ok. kein großes rauschen oder unscharfe bilder...
muss sagen, ich fand den ersten teil recht interessant, die diskussion über das compiler framework war eher langweilig, da hätten es auch ein paar sätze getan
aber sutter hat ein paar gute punkte gebracht und mein vertrauen in c++/cli gestärkt
-
Die Qualität ist IMHO total mies. Der .wma Codec scheint wirklich geil zu sein, nach allem was ich so weiß, besser als mp3. Aber das .wmv haut mich jetzt wirklich nicht vom Hocker.
Mein Vertrauen in C++/CLI braucht insofern keine große Stärkung, weil C++ damit endlich ne vernünftige Standardbibliothek mit Objektserialisierung, Threads, Sockets und weiteren völlig elementaren Sachen bekommt und anständige Unterstützung für gewisse Features direkt auf Sprachebene. Die jetzige stdlib ist halt einfach affig und genau ein starker Grund, warum Standard C++ mich überhaupt nicht mehr reizt.
Das mit der Standardisierung ist aber IMHO nicht sehr viel mehr als eine PR-Geste. Die Klassenbibliothek vom .Net Framework ist nicht so wirklich high-level und abstrakt, man merkt an allen Ecken und Enden das WinAPI durch. Ich halte das in vielen Bereichen für schwierig zu portieren.
Und das irgendjemand anders demnächst noch einen C++/CLI Compiler entwickelt, halte ich auch eher für fraglich. Ich glaube also schon, dass sich das Ganze in der Praxis als starke Bindung an Windows erweisen wird.
-
HumeSikkins! Danke für die Zusammenfassung. Auch ich denke nicht, das Sutter nicht weiß wovon er spricht. Sonst hätte ich das hier auch nicht gepostet.
Optimizer! Yo, wenn C++0x nicht ordentlich nachlegt wird es für C++ sehr schwer werden. C++/CLI ist fast schon ein inoffizieller Nachfolger in meinen Augen. Vorallem mit der C++/CLI 2.0 Syntax ist es wirklich "schön" geworden.
-
Der Vollständigkeit halber hier der zweite Teil:
-
OK, Herb Sutter mal außen vorgelassen - da kann es wirklich gut sein, dass ich es einfach nicht richtig gehört habe; xine wollte den Ton überhaupt nicht abspielen und mplayer nur mit sehr starkem Rauschfaktor - in C++/CLI oder .NET allgemein kann ich kein großes Vertrauen setzen. Ich sehe keine Garantie für Plattformunabhängigkeit, die für einen Standard ein Muss ist, und auch, dass man das WinAPI an allen Ecken durchmerkt, ist imho nicht besonders vorteilhaft. Das sind allerdings implementierungsspezifische Fragen bezgl. .NET, deswegen will ich mich damit nicht länger aufhalten.
Man hört ziemlich häufig, dass die STL für eine Programmiersprache als Standardbibliothek nicht ausreichend sei. Es ist zwar richtig, dass die STL nicht den Featureumfang bietet wie z.B. die JFC, aber das ist ja auch per Design so. Der Grundansatz von C++ ist nicht monolithischer Struktur, deswegen hat man auch nicht alles in den Standard einbezogen. Das hat auch seinen Sinn, auch wenn der in Zeiten von Java & Co. wenig Beachtung findet.
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 - aber gerade eine Grafikbibliothek ist ein gutes Beispiel für etwas, das da einfach nicht reingehört. Das aus dem einfachen Grund, dass eine Standardbibliothek auf allen Systemen lauffähig sein muss (bzw. sollte), und es jede Menge Systeme gibt, auf denen kein grafisches Subsystem vorhanden ist. Es mag zwar sein, dass Windows das Grafiksystem in den Systemkern integriert hat (aus welchem Grund auch immer), aber nicht jeder Rechner braucht, und konsequenterweise hat nicht jeder Rechner ein Grafiksystem. Für die meisten Server ist Grafik völlig unerheblich und nur unnötiger Overhead.
Noch deutlicher ist das bei Sockets zu sehen. Ganz abgesehen davon, dass es schon seit den Siebzigern einen Standard gibt, der Sockets beinhaltet (POSIX), gibt es an der Stelle eine subtile Inkonsistenz im Denken derer, die alles in eine Standardbibliothek pressen wollen. Auf der einen Seite erwarten die Leute eine ultramoderne Klassenbibliothek, die ihnen so ziemlich alles abnimmt, auf der anderen Seite wollen sie auf ein derart archaisches Konzept wie Sockets zurückgreifen. Netzwerkkommunikation kennt viele Formen, und nur selten sind Sockets die beste Wahl. An der Stelle würde es noch deutlich mehr Sinn machen, CORBA zu integrieren, was angesichts des dadurch entstehenden Laufzeitoverheads natürlich auch so ziemlich keiner machen will.
Die grundsätzliche Frage, die dadurch aufgeworfen ist, ist, was eigentlich sinnvollerweise standardisiert werden sollte. Standardisierung ist ein zweischneidiges Schwert. Es hat den Vorteil, dass man sich als Coder auf etwas verlassen kann, hat aber den Nachteil, dass Flexibilität verloren geht und Wettbewerb unter verschiedenen Implementierungen stark eingeschränkt wird. Ein wunderbares Beispiel für die Nachteile der Standardisierung ist, wie lange X gebraucht hat, um transparente Fenster zu lernen, ein anderes, dass es neben AWT und Swing für Java nur ein nennenswertes Grafiktoolkit gibt, nämlich SWT - was auch nur sehr spärlich eingesetzt wird. Man sollte sich an der Stelle sehr gut überlegen, was man in Stein meißeln will.
-
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.
