Bjarne erzählt ein wenig über die Herkunft von C++, weshalb es keine Sprache für Alles gibt, weshalb manche Entscheidungen so getroffen wurden wie sie sind und was man heute wohl besser machen könnte.
Super, danke fürs teilen! Solche Videos sind Gold Wert (Und nicht nur weil er praktisch aus meiner Seele spricht :D)
Leider ist er ein bisschen schwer zu verstehen was er manchmal meint.
Hmja. Wenn man nach 15 Jahren Java <3 mal wieder mehr mit C++ zu tun hat, denkt man sich schon SEHR oft: FIAL. (Eigentlich „FAIL“, aber da wäre noch zu viel richtig dran). Interessant finde ich auch die Konvergenz mit anderen Sprachen, die er (am Beispiel Python) angesprochen hat, und die ich auch schon zu Java <3 bemerkt hatte: „Juhuuu, mit C++11 haben wir shared pointer, und Threads, und ein Memory Model, und mit C++17 vielleicht Concept Checks, und vielleicht sogar Klassen, mit denen man einfach Daten von irgendeiner URL runterladen kann“. Willkommen in den 90ern 
Das Gefühl hatte ich vor ein paar Monaten auch mal. Eigentlich dachte ich immer: ah, C++11, supermodern, da ham die bestimmt aufgeholt, das wird doch jetzt auch gut funktionieren etc.
Wenn man es dann sieht, ist es sogar noch schlimmer als früher: genau so unkomfortabel (im Vergleich zu Java) wie damals, nur halt noch komplexer und schräger: über den Unterschied zwischen const und constexpr nachdenken ist echt seltsam. Schon klar, man kann super optimieren - wenn man sich super auskennt - aber für ein Java-Weichei ist sowas einfach zu hart.
C++11 has introduced the concept of rvalue references (specified with &&) to differentiate a reference to an lvalue or an rvalue. An lvalue is an object that has a name, while an rvalue is an object that does not have a name (a temporary object). The move semantics allow modifying rvalues (previously considered immutable and indistinguishable from const T& types).
Aha.
Ja, diese rvalues haben’s nicht leichter gemacht. Und es sind noch etliche andere Kleinigekeiten bei 11 dazugekommen, die es deutlich komplizierter machen. Komplizierter - als es vorher schon war. Natürlich könnte man z.B. trefflich drüber streiten, ob der berühmt-berüchtigte Abschnitt Choosing the Most Specific Method aus der JLS nun schwieriger oder leichter ist als die Infos zur Overload resolution in C++ (wobei das nur ein winziges, vereinfachtes Fragment der tatsächlichen Spec ist). Aber bevor das wieder mal zu zuuuu vordergründigem Sprachbashing wird (ich meine, das lohnt sich nicht. Wir wissen alle, welche Sprache die bessere ist :D), nochmal zum Video: Er spricht ja recht deutlich einigen Punkte an, bei denen man sich fragt: “Was solln das fürn Sche!ß sein?!”, und begründet (oder rechtfertigt) sie mit Dingen wie C-Kompatibilität usw. Aber eins ist klar: Wenn man heute jemandem, der noch nie etwas von C/C++ gehört hat (wenn das ganze also nicht “historisch gewachsen” wäre, um mal die ISO-4711-Standard-IT-Formulierung für “Murxiger Kraut-und-Rüben-Mist” zu verwenden), das aktuelle C++ zeigen würde, dann würde er das für einen schlechten Witz halten.
Das würde ich so nicht sagen. Wenn man die historische Entstehungsgeschichte von C++ nimmt, dann war die Sprache schon immer als die Überabstraktion aller Konzepte, Sprachen und so weiter gedacht.
Wenn man dann noch bedenkt wie genau sich C++ mit einer riesigen Userbase und viele kleinen “Empires” wie er sagt entwickelt hat dann überrascht das zusätzlich nicht.
Denn C++ ist ein riesiges träges alles abtrahierende Monster geworden.
Das ist super aber wie er selber sagt auch komplett schlecht, denn C++ hat keine Struktur /keine Regeln.
OOP ohne feste regeln ist kein OOP, denn einfach nur die Features zu unterstützen macht kein OOP daraus und das zieht sich praktisch durch die ganze Sprache.
Eine Sprache die 5 verschiedene Möglichkeiten hat einen Datentyp zu initialisieren ist einfach nicht übersichtlich.
Ich würde seinen Vortrag nicht allzu (von ihm selbst) uneigenkritisch betrachten, er spricht wichtige Punkte an bewertet sie aber selten.
Einzig allein das GarbageCollector Thema fande ich merkwürdig. Konstruktor/Destroktur ist doof, GC ist nicht die Lösung denn wie funktionieren dann Thread-Locks und was weiß ich (? Äh ja genau), das lösen Destruktoren, C++ hat jetzt sharedptr (äh ja genau, low level GC?)
Natürlich sollte man vom Erfinder erwarten das er hinter seinem eigenen Konzept steht und das merkt man auch. Aber es ist mal etwas anderes als nur die Leute zu hören die ein Konzept als Ideologie adaptiert haben und nicht das Konzept selbst.
Naja sharedptr sind reference counter, ob das jetzt schon als GC gilt mag man streiten. Die D-Jungs sehen das auch so, ich würde es nicht GC nennen, zu mind nennen wir innerhalb von Hazelcast unsere reference countings nicht GC, klingt irgendwie peinlich gegen das was Java kann 
sharedptr gehen aber in die Richtung. Also wenn man einen GC in C++ schreiben möchte (was auch in einigen Projekten getan wird und trotzdem gibt es dafür keine Standardimplementierung) ist einer der Möglichkeiten sharedptr. Deshalb sprach ich von Lowlevel GC 
Aber ja klar, gegenüber Java oder C# oder vielen anderen Sprachen oder Scripts ist das erstmal garnichts.
Naja gut so gesehen schon
[QUOTE=TMII]Das würde ich so nicht sagen. Wenn man die historische Entstehungsgeschichte von C++ nimmt, dann war die Sprache schon immer als die Überabstraktion aller Konzepte, Sprachen und so weiter gedacht.
Wenn man dann noch bedenkt wie genau sich C++ mit einer riesigen Userbase und viele kleinen „Empires“ wie er sagt entwickelt hat dann überrascht das zusätzlich nicht.
Denn C++ ist ein riesiges träges alles abtrahierende Monster geworden.
Das ist super aber wie er selber sagt auch komplett schlecht, denn C++ hat keine Struktur /keine Regeln.
OOP ohne feste regeln ist kein OOP, denn einfach nur die Features zu unterstützen macht kein OOP daraus und das zieht sich praktisch durch die ganze Sprache.
Eine Sprache die 5 verschiedene Möglichkeiten hat einen Datentyp zu initialisieren ist einfach nicht übersichtlich.
[/QUOTE]
Hmja. Man könnte jetzt versuchen, um nicht zu polemisch zu werden, die Diskussion auf klassische Desktop/Server-Anwendungen beschränken und von den ganzen „Ja, aber…“-Spezialfällen abzusehen, und mal einen Schritt zurückzugehen, und ganz abstrakt zu fragen: „Was macht eine gute Programmiersprache aus?“ oder sogar „Wozu ist eine Programmiersprache überhaupt da?“.
Viele würden letzteres vermutlich beantworten mit etwas wie ~„Um dem Computer zu sagen, was er tun soll“. Das ist (auch wenn DAS jetzt polemisch wirkt) schlicht FALSCH. (Er deutet das in dem Video an, mit Fotran/Cobol usw, aber (auch wenn ich einige Abschnitte überprungen habe) scheint nicht die (nicht so rosigen) Schlüsse dessen auf C++ zu ziehen). Ein Progammiersprache dient zur Kommunikation zwischen Menschen. Und daraus lassen sich einige der Facetten der Antwort auf die erste Frage ableiten. Z.B. sollte eine Programmierprache leicht lesbar sein, und es sollte klar sein, was dort „passiert“ (bzw. was dort modelliert wurde). Und zu C/C++ kann man dazu nur sagen: DAS haben sie RICHTIG verbockt. Angefangen bei den Altlasten (die er auch erwähnt), wie Macros (ich wollte schonmal eine Sammlung der „schönsten“ Macros auf eine Webseite stellen, nur wegen der URL: http://www.marcos-macros.de/ :D), die jeglichen vernünftigen IDE-Support so derart von Grund auf und komplett systematisch torpedieren, dass es schon fast absurd wirkt. (Wenn man von C redet, redet man tatsächlich nie von EINER Programmiersprache, sondern immer von ZWEI: Von C - und dem Präprozessor!). Damit verwandt ist z.B. die anachronistische Trennung von Header- und Code (Das, was damit erreicht werden soll, ist super. Aber Programmierer werden nicht dazu gezwungen, dieses Mittel richtig zu verwenden. Jeder kann machen, was er will. Und das ist meistens Murx). Und die Liste der Punkte, die eine Gute Programmierprache (im oben angedeuteten Rahmen!) ausmachen, und die bei C++ nicht erfüllt sind, könnte man lange fortführen (das wäre aber dann noch mehr bashing, als es jetzt schon ist :o ). Und damit hat man schon eine Liste der Dinge, die man gelernt hat. Zumindest, wie man es NICHT machen sollte
Interessant ist ja auch, wenn sich jemand mit den Antworten der offiziellen FAQs kritisch auseinander setzt: C++ Frequently Questioned Answers
bye
TT
Seitdem ich von Stroustrup „The C++ Programming Language“ gelesen hatte (versucht, war in den 90ern, k.A. welche Ausgabe, aber das Ding ist für die Tonne), interessiert mich seine Meinung gar nicht mehr
Guter Gedanke. Für meine Traumprogrammiersprache würde ich jederzeit ein tolles Feature oder eine super-dupi-Meta-Möglichkeit wegwerfen und dafür einer IDE die Möglichkeit geben, den Code besser zu verstehen und attraktivere Refactorings anzubieten.
Es ist doch ziemlich egal, was eine Programmiersprache alles kann, wichtig sind
-
wieviel Konzepte kann ein erfahrener Programmierer im Kopf haben und richtig anwenden
-
wieviel Scheiß kann ein Compiler/die IDE rechtzeitig verhindern
Und in der Beziehung ist C++ immer schon ganz mies.