Ist C++ am Aussterben?

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.

hustbaer

Artchi schrieb:

Make. Das ist wirklich überall verfügbar, sogar auf toten Plattformen wie dem Amiga OS.

Amiga OS ist nicht tot.

Artchi

Naja, ich kenne amiga-news.de und bin da fast täglich drauf. Und ich habe selber einen A1200 mit 030-Turbokarte und 16 MB RAM und HDD.

Nein, das was da noch passiert kann man nicht leben nennen. Mein Acorn Archimedes und RiscPC sind auch tot, auch wenn ich unter Windows noch VirtualRPC benutze.

Aber ich will dir nicht die Illusion nehmen... ja, die Amiga-Welt blüht!

hustbaer

Ich bin in der Amiga Szene nicht aktiv und beobachte sie auch nicht wirklich. Hab' zwar nen 3000er rumstehen aber den hatte ich seit Jahren nicht an.
Hab nur kürzlich das gelesen: http://www.osnews.com/comments/29948

Artchi schrieb:

Aber ich will dir nicht die Illusion nehmen... ja, die Amiga-Welt blüht!

Naja blühen kann man nicht sagen, aber nachdem sogar noch neue Hardware entwickelt wird...
So nen Standalone Vampir werd ich mir dann auch ziemlich sicher gönnen wenn sie fertig sind.

Artchi schrieb:

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

das kann man nicht so gut vergleichen.

Ein Vergleich wäre, wenn es zahlreiche Varianten dieses Auto-Typs gegeben hätte, und wenn ich, um nach Jena zu fahren, den Typ A und das Benzin der Sorte B hätte tanken müssen, wenn ich dagegen nach Rostock hätte fahren wollen, erst ein Auto des Typs B hätte kaufen oder ausleihen müssen, um dann Benzin der Sorte C zu tanken.

Ein einheitliches Build-System entspräche dann einem Auto, mit dem ich egalwohin fahren kann, und das als Treibstoff Benzin egal welcher Marke verträgt. Meine Entscheidung, was besser ist, wäre dann klar.

Artchi schrieb:

Bisher ist es ja so, das man sagen kann, dass das Make eigentlich überall funktioniert.

ich hätte nichts dagegen, POSIX make als Default zu nehmen (obwohl ich möglicherweise einige GNU-Erweiterungen vermissen würde), vorausgesetzt, es gäbe kompatible Versionen auf gängigen Plattformen. Die Existenz von autoconf und automake läßt mich aber ahnen, daß das nicht so einfach ist.

Artchi schrieb:

Ü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.

ich wundere mich etwas, daß du in diesem Zusammenhang Smalltalk erwähnst.

Denn der einzige Smalltalk-Standard, von dem ich weiß, ist ANSI Smalltalk (1998?), und dort ist, soweit ich mich erinnere, weder GUI, noch Desktop, IDE oder VM standardisiert, sondern ein Basis-System mit Syntax und einer Reihe grundlegender Klassen (Container, Datei-E/A). Erinnere ich mich falsch oder gibt es da was Neues in den letzten Jahren?

Im Vergleich dazu Java: Java hat definierte APIs für GUIs (JFC) und viele weitere Zwecke, und Java hat sich auf breiter Front durchgesetzt.

Ich beschäftige viel mit der Spieleentwicklung und den frei verfügaren Engines wie Unity3D, Unreal Engine 4 oder CryEngine.

Was die Entwicklung solcher Engines angeht wird auf C++ gesetzt. Nur für die Spielelogik gibt es interpretierte Scriptsprachen innerhalb der Engine.

Und solche Programme sind nicht gerade ein Beispiel für Altenpflege. Es sind hoch moderne Anwendungen mit Überwiegend sehr jungem Code. Die UE4 erschien 2014 und ist quasi eine Neuentwicklung und setzt nicht mehr auf die alte UDK.

Ehrlich gesagt habe ich noch nie von einer leistungsfähigen Engine gehört die nicht mit C++ entwickelt ist. Ich bin mir sicher auch die nicht frei zugänglichen Engines wie die extrem gute Frostbite Engine von EA oder Anvil von Ubisoft auf C++ basieren.

Eines muss man bedenken wenn man irgendeine Programmiersprache für Tot erklären möchte. Es gibt heute schlichtweg mehr Programmiersprachen als früher. Und ich glaube früher hat man C und C++ für fast alles benutzt. Heute gibt es mehr oder weniger spezialisierte Sprachen die in einigen Bereichen Vorteile gegenüber C++ haben, sei es auch vielleicht die einfachere Erlernbarkeit. Oder wenn nicht jeder Funken Performance gefragt ist.

Dann gibt es den Embedded Bereich wird vollständig durch C und C++ dominiert, vielleicht deutlich mehr von C als C++. Es gibt in den letzten Jahren zwar einige Entwicklungsboards für Anfänger wo man mit Python oder JavaScript (Nodejs) programmieren kann, aber so was setzt bisher kein Unternehmen ein.
Ein embedded Produkt hat nicht so viele Ressourcen wie ein PC und die verwendete Programmiersprache sollte kein unnötiges Overhead erzeugen, da man dann zu teureren Chips greifen muss und das macht das Endprodukt teurer und weniger Konkurenzfähig.
Deswegen werden C und C++ den Markt wohl weiterhin dominieren.

Und man sollte bedenken dass es bei der Vielzahl vieler neuer Sprachen auch viele Trends gibt. Trends die manchmal nur ein paar Jahre halten.
Ganz schlimm ist es in der Webentwicklung, dort gibt es praktisch jährlich ein neuen Trend dem viele Entwickler folgen. Neue Sprachen und vor allem neue Frameworks.

Vieles von dem was heute zu C++ als Alternative geboten wird wie Rust muss sich noch bewähren und zeigen ob es auch in 10 Jahren noch jemanden interessiert.

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 Design sieht leider auch ein bisschen wie von 2010 aus :p
Mir ist es zwar nicht wichtig und es geht hier um Informationen und nicht um Design. Aber ein schönes Forum wirkt einladender, vor allem für jüngere Leute.

Achja und nicht vergessen das Foren generell an Popularität eingebüßt haben.
Vor 10 oder 15 Jahren gab es Seiten wie stackoverflow und reddit nicht oder sie waren nicht so populär wie heute.
Vor allem stackoverflow ist echt allgegenwärtig, sobald ich irgendeine Fragestellung aus der Programmierung in Google eingebe wird man mit stackoverflow Inhalten sofort bedient und meistens auch geholfen.

Und Smaltalk findet fast nur noch auf Facebook und Twitter statt.

zeropage

Code1899 schrieb:

Aber ein schönes Forum wirkt einladender, vor allem für jüngere Leute.

Nichts gegen junge Leute, waren wir ja alle mal. Aber was heute hüh ist, ist morgen hott. Das einzig Garantierte ist eine kurze Lebensdauer. Langfristig wirken imo eher Zeitlosigkeit und Kontinuität.

Mechanics

Wegen der ganzen Aussagen, dass hier im Forum so wenig los wäre... Ich finde, hier ist immer noch etwas mehr los als im Mycsharp Forum, und C# ist ja seit Jahren ziemlich angesagt. Sagt also nicht wirklich was aus.

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.

Warum? Das kann man in Rust mit gleicher Performance, höherem Komfort und höherer Sicherheit ebenfalls implementieren.