Ist C++ am Aussterben?
-
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?
-
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.
-
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.
-
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.
-
Artchi schrieb:
Make. Das ist wirklich überall verfügbar, sogar auf toten Plattformen wie dem Amiga OS.
Amiga OS ist nicht tot.
-
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!
-
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/29948Artchi 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.
-
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.
-
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.
-
Rust schrieb:
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.
Wie kommt es eigentlich dass ausgerechnet die meist verwendeten Sprachen so viel Kritik ernten?
C, C++, Java, PHP oder JavaScript. Oft angefeindet aber doch dominierende Sprachen.Neben C und C++ ist PHP auch ein gutes Beispiel. Was hat man über PHP nicht alles geschimpft. Und doch findet man kaum eine Webanwendung ohne PHP.
Lasst mich raten, eigentlich sind diese am meisten verwendeten Sprachen nicht besser als die neuen Alternativen, nur weil es sie länger gibt und viele sie beherrschen und es so viel Code davon gibt dominieren sie zumindest vorerst noch den Markt.
Aber langfristig werden sich natürlich die besseren Alternativen durchsetzen. Durch eine Art selektive Evolution in der IT.Zum Teil dürfte dass sogar stimmen. Aber zweifelhaft ob dass in den Dimensionen eintreten wird wie sich das manche vorstellen. Zum Teil dürfte diese Haltung daher resultieren dass jemand sich bewusst vom Mainstream abgrenzen will.
Subkulturen in der IT sozusagen, anders sein und cooler sein wollen. Mit neuen Sprachen die zum Teil wirklich Verbesserungen anbieten aber auch welche die keine nennenswerten echten Vorteile bieten und eher subjektive Einbildung ist im Sinne der Subkultur.
-
BlubberC++ schrieb:
Wie kommt es eigentlich dass ausgerechnet die meist verwendeten Sprachen so viel Kritik ernten?
je mehr Menschen eine Sprache benutzen, umso mehr Meinungen gibt es und umso mehr sind da, die auch die Nachteile kennen.
Oder grob vereinfacht gesagt: Eine Sprache, die niemand kennt, wird auch kaum kritisiert.
Außerdem sind praxisnahe Sprachen oft nicht Paradigmata-rein, sondern im Dienst der Praktikabilität oft Multi-Paradigmata-Sprachen, wobei es bei der Realisierung der Paradigmata Kompromisse gibt; wahrscheinlich geben muss.
-
BlubberC++ schrieb:
Warum? Das kann man in Rust mit gleicher Performance, höherem Komfort und höherer Sicherheit ebenfalls implementieren.
angeblich kann man alles mit allen sprachen implementieren.
aber ich habe mich bisher z.b. immer sehr stark auf c konzentriert, mich an die eigenheiten dieser sprache gewöhnt und werde mit anderen sprachen wahrscheinlich niemals so gut programmieren können wie mit c, bzw. nur mit unnötigem aufwand, weil ich sonst ja erst einmal 10 jahre erfahrung mit anderen sprachen sammeln müsste und da ich hoffentlich bald "der chef" bin und "das sagen" habe, werden sich auch weiterhin leute mit c abärgern müssen.Wie kommt es eigentlich dass ausgerechnet die meist verwendeten Sprachen so viel Kritik ernten?
C, C++, Java, PHP oder JavaScript. Oft angefeindet aber doch dominierende Sprachen.Neben C und C++ ist PHP auch ein gutes Beispiel. Was hat man über PHP nicht alles geschimpft. Und doch findet man kaum eine Webanwendung ohne PHP.
viele leute suchen sich auch einfach den falschen beruf aus. also ich finde es z.b. unglaublich toll mit arrays, offsets und funtionspointern herumzuspielen, andere werden das vielleicht nicht so toll finden und daher entsprechend schimpfen, wenn sie so etwas machen müssen.
Lasst mich raten, eigentlich sind diese am meisten verwendeten Sprachen nicht besser als die neuen Alternativen, nur weil es sie länger gibt und viele sie beherrschen und es so viel Code davon gibt dominieren sie zumindest vorerst noch den Markt.
Aber langfristig werden sich natürlich die besseren Alternativen durchsetzen. Durch eine Art selektive Evolution in der IT.eigentlich ist es egal, welche sprache du verwendest. wenn du spaß daran hast, kannst du soweit ich weiß auch mit lisp geräte über den parallelport ansteuern.
aber was heißt bessere alternativen? unter c nimmst du halt funktionszeiger, unter basic goto und unter java oder c++ die lambda-funktionen. das ergebnis ist aber faktisch das gleiche und damit sind diese angeblichen verbesserungen gar nicht wirklich verbesserungen, sondern einfach nur andere vorgehensweisen.Subkulturen in der IT sozusagen, anders sein und cooler sein wollen. Mit neuen Sprachen die zum Teil wirklich Verbesserungen anbieten aber auch welche die keine nennenswerten echten Vorteile bieten und eher subjektive Einbildung ist im Sinne der Subkultur.
ja genau das ist das. guck dir mal die profile der meisten it-spezialisten an: sie können dann angeblich 20 verschiedene programmiersprachen, aber wahrscheinlich nicht eine einzige annähernd vernünftig.
-
zufallswert schrieb:
Oder grob vereinfacht gesagt: Eine Sprache, die niemand kennt, wird auch kaum kritisiert.
Sehe ich auch so. Ich kenne und mag C++, aber es ist bei weitem nicht perfekt und ich muss das nicht super finden. Deswegen darf man auch ab und zu mal drüber schimpfen. Aber das heißt jetzt nicht, dass irgendeine Sprache xy so viel toller wäre und ich die unbedingt haben will.
