Ist C++ am Aussterben?

Mechanics

Wade1234 schrieb:

keine Ahnung, vielleicht war das mal anders, ist ja auch schon etwas her.

Nee, war schon immer Blödsinn.

Artchi schrieb:

Ob aber gerade Rust der C++-Nachfolger wird, bezweifel ich!

Wobei, wenn es jemand schafft irgendwann mal als C++-Nachfolger durchzugehen, dann wohl Rust.

Und ich finde schon, dass man C++ mal durch was modernes (z.B. mit import statt include) ersetzen sollte.

Ich hatte noch nicht das Vergnügen mit C++ > 2003(?) richtig zu arbeiten aber wenn ich mir mit 15 Jahren alter C++-Erfahrung so Sachen wie die "neuen" move-Operatoren angucke, kriege ich eher Schüttelfrost. Habe so schon oft genug das Problem "Uberladungshölle" zu meistern.

Ich will die neuen Features natürlich unbedingt haben und denke mal, dass die auch alle gut und sinnvoll sind, aber es wird halt immer komplizierter.
Rust scheint gut zu sein, wirkt von außen aber jetzt schon sehr kompliziert. Liegt wohl auch daran, dass sich da noch ständig was ändert.

Rostig schrieb:

Rust scheint gut zu sein, wirkt von außen aber jetzt schon sehr kompliziert. Liegt wohl auch daran, dass sich da noch ständig was ändert.

Und natürlich daran, dass es so gut wie C++ sein will. Das ist ja auch nicht ohne Grund so kompliziert.

Artchi

Wade1234 schrieb:

keine Ahnung, vielleicht war das mal anders, ist ja auch schon etwas her.

OO-Code war nie langsamer als proceduraler Code. Denn du musst ja beim Vergleich die gleichen Fähigkeiten implementieren, weil du ja ein bestimmtes Ziel/Vorteil erreichen willst. Im OO-Fall meistens die dynamische Polymorphie. Und in proceduralen Sprachen baust du dir halt Work-Arounds für Polymorphie, für das was ein OO-Compiler für dich autom. im Hintergrund generiert. In z.B. C programmierst du das per Hand nach (kommt technisch das selbe raus, hast aber mehr Arbeit und Komplexität rein gesteckt, als wenn du einfach eine OO-Sprache nimmst).

Der Mythos, das OOP langsamer sein soll, kommt vielleicht von Smalltalk. Bei Smalltalk war aber nicht die OO das Langsame, sondern das Message-System (der Smalltalk-Erfinder Alan Kay bezeichnet es deshalb auch als Message-Oriented-Programminglanguage). Und Messaging ist, wie wir wissen, in jedem System langsam. Weil das Ziel/Vorteil der Entkopplung (Late-Binding) nunmal diesen Nachteil mit sich bringt.

Alles was einen Vorteil hat, hat auch einen Nachteil. Wenn du procedural und statisch programmierst, dann hast du zwar einen Performance-Vorteil... aber den Nachteil der Unflexibilität, starken Kopplung und nicht-Erweiterbarkeit.

Wenn statischer proceduraler Code so geil wäre und keine Nachteile hätte, dann würde niemand einen Grund haben andere Paradigmen (Messaging, Polymorhie, Funktional usw.) einzusetzen. Oder? Am Ende ist ja alles Fallabhängig, welches Paradigma man einsetzt.

In unserer internationalen Firma setzen wir erfolgreich auf Haskell.

Denkt mal drüber nach!

Grüße aus Oslo/Norwegen

DocShoe

In unserer internationalen Firma setzen wir erfolgreich auf C++.

Denkt mal drüber nach!

Grüße aus Witten/Deutschland

5cript

Ich fange an bei meiner Firma alles mit C++ zu "durchseuchen"
Keine Lust alles in Delphi zu machen *würg*. Die interessiert das eh alles nicht.
Sollte sie meiner Ansicht nach aber. Wenn ich weg bin, haben die ein Problem, weil die jemand bräuchten, den sie doppelt so gut bezahlen müssten, nicht weil schlecht dokumentiert, sondern weil ich unterbezahlt bin -.-
Aber wenns die nicht interessiert was ich nutze, dann C++. (Für Embedded, Beagle Bones und Desktopanwendungen). Wenn schon scheiße bezahlt, dann will ich auch mit Freude zur Arbeit gehen.

Ich bin aber so frei zu behaupten, dass sie mit mir und meiner Sprachenwahl sehr sauber strukturierte, performante, wartbare und fehlerfreie Software kriegen.
Aktuell brauchen die in manchen Projekten 3 Tage mindestens um einen Bug zu beheben, weil deren Software plain Scheiße ist. Ich kann den Mist auch nicht mehr lesen, wenn er 20 Einrückungen stellenweise hat, weil der Quelltext toxisch ist wie nichts. Dann doch lieber ein kleinen TMP Trick hier und da und alles wird wieder lesbar, weil es auf eine Zeile runterkocht, die für sich selbst spricht.

EDIT: Ich weiß dass es für das große Ganze irrelevant ist, was ich denke, aber ich bringe ein bisschen mehr C++ in die Wirtschaftswelt ^^.

EDIT 2:

Was wird bei uns eingesetzt?:

Delphi
C
Assembly
C++ (NEU)

Da ist IMHO C++ noch das beste aus der Liste. (Ich habe meine JavaScript, Python, Bash und Batch Scripte mal nicht mitgezählt)

Artchi schrieb:

Ach ja, und dieses Forum zeigt auch den Trend. Vor 10 oder 15 Jahren war hier die Hölle los... heute ist schon verhältnismäßig tote Hose.

Das kann aber auch am Forum liegen, da es
a) deutschsprachig ist und mittlerweile doch die meisten ohne Probleme Englisch schreiben und verstehen und das eben auch die wichtigste Sprache im IT-Bereich ist.
b) Das Forum ist schwer zu finden, ich kam gerade nur per Zufall und durch einen obskuren Suchbegriff her.
c) Stackoverflow und Co. sind die Orte, an denen mittlerweile am meisten diskutiert wird, egal über welche Sprache wir sprechen.

Artchi schrieb:

Ob aber gerade Rust der C++-Nachfolger wird, bezweifel ich! Ich sehe den Trend eher das C++ nur noch für die Implementierung von Engines und VMs benutzt wird. Die Anwendungen (egal ob Business, Games usw.) dann in einer Interpreter/Managed-Sprache entwickelt werden... also Java (Android und Enterprise-Edition), C#, JavaScript, Lua, Python usw.

Das sehe ich genauso, wir (internationaler Konzern) setzen z.B. sehr stark auf C# für die meisten Anwendungen und hardwarenahes wird meistens in C oder C++ gemacht.
Die Produktivität mit C# und Co. ist einfach enorm hoch und gewisse Fehler sind von vornherein ausgeschlossen.

Rust krankt IMO an zwei Dingen: zu komplex und zu wenig produktiv für klassische Desktopanwendungen und umgekehrt im Hardwarebereich (noch)kaum vertreten, obwohl ich gerade da große Vorteile durch die erzwungenen statischen Checks sehen würde.
Tooling ist gerade im professionellen Bereich oftmals einfach alles und was nicht offiziell vom Zulieferer unterstützt wird, wird auch nicht eingesetzt.
Wir sehen das häufig bei C++: da wären wir schon um C++11 support froh.
Wo es ggfls. jetzt schon sehr gut einsetzbar ist, wäre bei der Systemprogrammierung aber vermutlich werden weder die Linuxentwickler noch Microsoft Lust haben, ihre Kernels nach Rust zu portieren.

Zukünftige Betriebssysteme könnten es natürlich ohne Probleme einsetzen, da man dann von Anfang an damit plant.

Das muss natürlich nicht heißen, dass Rust niemals eine sehr wichtige Sprache werden wird aber ich könnte mir vorstellen, dass wir Rust in 10-15 Jahren rückblickend eher als wichtigen Zwischenschritt sehen werden.

Artchi schrieb:

Alles was einen Vorteil hat, hat auch einen Nachteil. Wenn du procedural und statisch programmierst, dann hast du zwar einen Performance-Vorteil... aber den Nachteil der Unflexibilität, starken Kopplung und nicht-Erweiterbarkeit.

also ist oo doch langsamer?

dass kunden meistens gar nicht wissen, was sie eigentlich haben wollen und es bei prozeduralen konzepten besser ist, alles noch einmal von vorne zu machen, wenn da plötzlich größere änderungen stattfinden sollen, ist ja eine ganz andere geschichte.

nachtfeuer

Wade1234 schrieb:

Artchi schrieb:

Alles was einen Vorteil hat, hat auch einen Nachteil. Wenn du procedural und statisch programmierst, dann hast du zwar einen Performance-Vorteil... aber den Nachteil der Unflexibilität, starken Kopplung und nicht-Erweiterbarkeit.

also ist oo doch langsamer?

mit derselben argumentativen Tiefe könnte man auch sagen, Pseudocode ist am schnellsten (hat auch selten Probleme mit z.B. Skalierung o.ä.).

Erfahrungsgemäß ist der Code bzw. das Programm gut wenn der/die Programmierer/in gut ist/sind.

Problem mit guten Programmierern:
https://www.youtube.com/watch?v=LWTe0aW1OFs (10:48)

wann bekommen wir in C++ Standards für Object Files ähnlich extern "C" und wann ein einheitliches, portables Build-System?

Artchi

Wade1234 schrieb:

also ist oo doch langsamer?

Nein, du hast leider meinen Text nicht aufmerksam genug gelesen.

Wade1234 schrieb:

dass kunden meistens gar nicht wissen, was sie eigentlich haben wollen und es bei prozeduralen konzepten besser ist, alles noch einmal von vorne zu machen, wenn da plötzlich größere änderungen stattfinden sollen, ist ja eine ganz andere geschichte.

Nein, du hast bzgl. statischem Code leider absolut nicht verstanden, worum es geht. Ganz banales und naives Beispiel:

Wenn dir ein Kunde sagt "Ich will ein Programm, das mir einen eingegebenen Text auf dem Bildschirm ausgibt haben!". Würdest du das Programm wirklich aus Performance-Gründe so programmieren, das es den Text wirklich NUR auf auf dem Bildschirm ausgeben kann?

Am nächsten Tag sagt er dir, er möchte gerne den Text auch in eine Datei "ausgeben" (schreiben). Du würdest dich also wieder hinsetzen, neuen Code schreiben der aus Perfomance-Gründe wirklich so hart verdrahtet ist, das er entweder nur auf dem Bildschirm oder nur in eine Datei schreiben kann? (z.B. mit einem Switch-Case) Und du bist ganz sicher keine Polymorphie einsetzen zu wollen?

Bist du dir jetzt immer noch absolut sicher über deine Entscheidung?

Eine Woche später kommt der Kunde und sagt "Ich will den Text jetzt auch auf einem Drucker ausgeben!". Und du würdest dich wieder hinsetzen, den Code umbauen, Code hinzufügen, hart verdrahten um wieder Polymorphie zu vermeiden... usw. du weißt schon.

Nächsten Monat kommt der Kunde wieder zu dir, und sagt "Ich will den Text jetzt auch per RS232-Modem versenden." Und du wirst jetzt wirklich immer noch ganz sicher Polymorphie vermeiden wollen, den kompletten Code wieder anfassen, erweitern, testen usw.

Später kommt der Kunde wieder zu dir, und will... ich lasse es jetzt mal um uns allen dieses Elend zu ersparen. Ganz davon abgesehen, ob der Kunde das alles überhaupt bezahlen wollen würde.

Nun, wenn du Polymorphie anwenden würdest, hättest du die Ausgabe nur einmal programmiert, und er Kunde hätte im ersten Fall einfach das gemacht:

$ prgm "Hallo!"
Hallo

Im zweiten Fall hättest du keinen Code anfassen müssen, der Kunde hätte einfach das machen können:

$ prgm "Hallo!" 1>datei.txt

Für den Drucker (z.B. lpt) und Rs232 (z.B. tty) hätte er den Stream entsprechend in andere Geräte umleiten können.

Der Witzt ist, das es praktische keine Software gibt, die erfolgreich ist, die nicht flexibel ist. Statische programmierte Software ist Wegwerf-Software, die für einen bestimmten Fall programmiert wird. Mehr nicht. Das können gerne bestimmte Embedded-Programme sein, die vom Anwender keine flexiblen Wünsche erwarten dürfen (kaffemaschine macht wirklich nur Kaffee, und kann beim Kunden nicht um die Funktion "ein Ei braten" erweitert werden). Gibt noch andere Beispiele für Nicht-OO-Software.

Ich bezweifel mal, das du mit deiner Theorie sehr weit kommst, das OO nicht benutzt werden sollte. OO ist seit den 1960er Jahren Standard (Simula) und hat sich in den 1970 in so ziemlich jedes Betriebssystem eingenistet.

Webbrowser können durch Add-ons erweitert werden, Office-Programme sowieso... ach ja, und Smartphones können mit Apps erweitert werden. Was wäre das alles ohne OO/Polymorphie?

Heute versuchen leider immer noch viele die OOP in z.B. C nachzubauen (eigene vtable), anstatt dieses vom Compiler (z.B. mittels C++) im Hintergrund bauen zu lassen. Mit GObject von GTK+ kann man sich zumindest Arbeit abnehmen lassen. In Unix, Windows u.a. Betriebssystem wird das meistens durch einen gemeinsamen Basis-Datentyp (Character-Streams o.ä.) und einer OO/polymorphen Schnittstelle wie Block-Device-Drivers gelöst.

Aber du bist der einzige, der OO und Polymorphie für unwichtig hält.

Artchi

zufallswert schrieb:

wann bekommen wir in C++ Standards für Object Files ähnlich extern "C" und wann ein einheitliches, portables Build-System?

Wird nicht passieren und ist auch nicht angedacht.

was portable ABIs angeht, schon: N4028.

Was den Wunsch nach einem einheitlichen, portablen Build-System angeht: Was steht dem eigentlich grundsätzlich im Wege, außer natürlich, daß es eine umfangreiche und sehr anspruchsvolle Aufgabe wäre?

Artchi

zufallswert schrieb:

Was den Wunsch nach einem einheitlichen, portablen Build-System angeht: Was steht dem eigentlich grundsätzlich im Wege, außer natürlich, daß es eine umfangreiche und sehr anspruchsvolle Aufgabe wäre?

Es gibt viele Build-Systeme, die alle ihre Stärke und Schwäche haben. Suche dir eine aus. Und das ist doch gut, das man es sich aussuchen kann. Wenn ISO-C++ ein Build-System vorgeben würde, würden wohl viele dann doch ein anderes benutzen.

Die Stärke von C++ ist, das man sich selbst einen Werkzeugkasten zusammen stellen kann. Von den Basis-Libs, über Compiler, Build-System bis IDE.

Und welches Build-System sollte denn Standard werden? Wenn du die Frage hier stellst, wirst du zu keinem Ergebnis kommen.

Aktuell scheint ja CMake hip zu sein (wobei CMake selbst nicht bauen kann, es ist ja mehr ein Meta-Build-System). Ich habe es ausprobiert, und es ist der Horror! Die Syntax ist mal wieder exotisch und die Tutorials nicht ausgereift.

Ich selber benutze gerade SCons. Das hat zwar den Nachteil, das es eine Python-Installation voraussetzt, aber das Handbuch ist soweit ganz gut. Dummerweise unterstützt SCons aktuell noch kein MS VS2017.

Ich muss nach den vielen Build-Systemen, die ich ausprobiert habe, eines feststellen: eigene Syntax/Sprache ist inakzeptabel. Die Build-Scripte sollten eine bekannte Sprache benutzen, wie z.B. Python, Lua. Das macht die Einarbeitung und Informationssuche um vieles leichter. XML (wie z.B. Ant oder Maven in der Java-Welt) sind noch schlimmer.

Ein Build-System müsste viel zu viele Sonderfälle beachten.

am besten würde ein C++ Buildsystem einfach C++ nutzen - meinentwegen mit Cling als Interpreter oder sowas, oder kompiliert - dann kann ich wenigstens meine Standard-Tools (Libs, IDE, ...) verwenden

Artchi schrieb:

Es gibt viele Build-Systeme, die alle ihre Stärke und Schwäche haben. Suche dir eine aus. Und das ist doch gut, das man es sich aussuchen kann.

Mit dem gleichen Argument könnte man auch sagen "wozu Sprachstandards? wäre doch gut, wenn es verschiedene Sorten von C++ gäbe, aus denen man sich eine passende aussuchen könnte."

Wahlfreiheit des Buildsystems habe ich als Hersteller von Code, aber nicht unbedingt als Anwender von Code - wenn ich z.B. eine open source 3rd-Party-Library mit C++ API in einem Projekt verwenden möchte, das ich mit einem ganz anderen Build-System baue.

Es wäre gut, wenn es einen Standard gäbe, mit dem garantiert wäre, daß man open source 3rd Party-Code ohne Nachinstallation von Build-Systemen kompilieren könnte. Dann könnten IDEs dieses eine Build-System unterstützen, und wer ein anderes benutzen will, wird davon ja nicht abgehalten.

Artchi schrieb:

[...] Ich habe es ausprobiert, und es ist der Horror! Die Syntax ist mal wieder exotisch und die Tutorials nicht ausgereift. Ich selber benutze gerade SCons. Das hat zwar den Nachteil, das es eine Python-Installation voraussetzt, aber das Handbuch ist soweit ganz gut. Dummerweise unterstützt SCons aktuell noch kein MS VS2017.

Das sind schon 3 Gründe für die Notwendigkeit eines einheitlichen Build-Systems.

So, wie ich dank des Sprach-Standards nur 1 Compiler brauche, um Standard-konformen Code zu übersetzen, würde ich es auch gut finden, nur 1 Build-System zu brauchen.

scrontch

Artchi schrieb:

Aktuell scheint ja CMake hip zu sein (wobei CMake selbst nicht bauen kann, es ist ja mehr ein Meta-Build-System). Ich habe es ausprobiert, und es ist der Horror! Die Syntax ist mal wieder exotisch [...]

Ja, dazu fällt mir wieder immer ein Kommentar auf dieser CMake review ein:

Please, people, stop inventing your own application-specific scripting languages! Especially if you are going to invent one that sucks.

Artchi

zufallswert schrieb:

Es wäre gut, wenn es einen Standard gäbe, mit dem garantiert wäre, daß man open source 3rd Party-Code ohne Nachinstallation von Build-Systemen kompilieren könnte. Dann könnten IDEs dieses eine Build-System unterstützen, und wer ein anderes benutzen will, wird davon ja nicht abgehalten.

Das wird deshalb nicht funktionieren, weil es unterschiedliche Plattformen und Betriebssysteme gibt. Schon alleine die zwei verbreitetsten Systeme (NT und Posix) haben unterschiedliche Dateisystem-Syntax. Es gibt da noch andere Systeme, die komplett andere Syntax benutzen. Das wäre der Standard mal wieder "vage" und es würde bestimmt viel "undefined" vorkommen.

C und C++ definieren aber keine Plattform. Das ist bei z.B. Java, Python anders, da ist nicht nur die Sprache, sondern auch gleich eine virtuelle Plattform mit definiert.

zufallswert schrieb:

So, wie ich dank des Sprach-Standards nur 1 Compiler brauche, um Standard-konformen Code zu übersetzen, würde ich es auch gut finden, nur 1 Build-System zu brauchen.

Nein, das ist nicht gut! Das hat schon das 1-Automobil-System Trabant bewiesen, das ein Modell ohne Konkurrenz keinen Fortschritt bringt.

Wenn wir so viele Compiler und Build-Systeme haben, müssen wir uns das bessere oder für uns persönlich bessere Modell entscheiden. Und das schlechtere, von wenigen Menschen genutzte Modell, wird irgendwann aussterben.

Bisher ist es ja so, das man sagen kann, dass das Make eigentlich überall funktioniert. Sogar in MSVS gibt es seit 20 Jahren ein kompatibles nmake.exe. Wer also ein Quasi-Standard-Build-Tool nutzen wollen würde, kann sich die Make-Syntax aneignen und würde damit auf so ziemlich jeder Plattform und Compiler-Toolkit gut fahren:

https://en.wikipedia.org/wiki/Make_(software)#Derivatives

Übrigens ist Smalltalk unter anderem wegen seiner nicht vorhandenen Wahlfreiheit gestorben (war sicher nicht der einzige Grund, aber dieser gehört dazu). Denn Smalltalk hat ALLES standardisiert und vorgegeben, die VM, das Dateisystem, die IDE, die GUI, der Desktop, der Compiler, der Debugger und natürlich Build-Tool ist in einem definierten System. Du kannst mit Smalltalk (und auch dem modernen Pharo) super schnell los legen zu entwickeln, ein Tutorial, egal auf welchem System. Weil alles mitgeliefert wird, was man benötigt. Das ist erstmal super geil! Aber wehe du willst etwas anders haben/machen, weil es dir doch nicht so gefällt...

Ich kann deine Gedanken sehr gut nachvollziehen, weil auch ich mich immer wieder ärger, wenn irgendwo ein neues Tool auftaucht. Aber wenn man nüchtern darüber nachdenkt, ist das gut.

Wenn du wirklich ein Standard-Build-Tool haben willst, würde ich dir empfehlen, dich auf ein Quasi-Standard-Buildtool zu fixieren: Make. Das ist wirklich überall verfügbar, sogar auf toten Plattformen wie dem Amiga OS.