C++ zukunftssicher?
-
Wird C++ noch lange bestehen? Wird es bald eine neue, bessere, einfachere, weitreichendere Programmiersprache geben?
(Besonders im Bereich Grafik/Spieleprogrammierung)Würde mich sehr interessieren, ob es sich überhaupt auszahlt, noch C++ zu lernen?
Möchte dann nicht, dass in 10 Jahren eine revolutionäre Sprache entwickelt wird, und C++ veraltet ist
Hoffentlich nicht, ich finde C++ sehr nett und würde gern mein Leben lang damit arbeiten!
-
Zitat von irgendeinem Foriker hier:
Der Lernprozess im Bereich Programmierung hört _nie_ auf.Zu deinen Fragen:
Ja es lohnt sich noch C++ zu lernen.
-
Aedyn schrieb:
Hoffentlich nicht, ich finde C++ sehr nett und würde gern mein Leben lang damit arbeiten!
vergiss es. die einzige sprache, die sowas schaffen könnte ist lisp. viel spaß damit.
darüber, wie lange c++ hält, sollten vielleicht die experten hier spekulieren...
-
bin zwar kein experte aber ich würde nicht sagen dass c++ von einer anderen sprache abgelöst wird. höchstens gibt es bald einen neuen standard.
mfg.
-
Bisher haben sich alle neuen Sprachen an C++ orientiert, z.B. Java, C++/CLI, J# und C#. Ich denke das sagt schon mal sehr viel aus, wie ernst C++ als Sprache genommen wird. Da C++ von den genannten Sprachen auch die einzige Sprache ist, die ein ISO-, ANSI- und DIN-Standard ist, ist zumindest rein offiziell ein gewisser Status gegeben.
2009 kommt der nächste C++-ISO-Standard, somit "lebt" die Sprache zumindest was den Standard angeht weiter. MS, Intel und GNU basteln regelmäßig an Compilern weiter, somit stehen die wichtigsten Organisationen hinter C++.
Was will man mehr um C++ als erstmal zukunftssicher zu halten?
-
Aedyn schrieb:
Wird C++ noch lange bestehen? Wird es bald eine neue, bessere, einfachere, weitreichendere Programmiersprache geben?
(Besonders im Bereich Grafik/Spieleprogrammierung)Ob eine neue, bessere Programmiersprache in Zukunft das Licht der Welt erblickt und C++ ablöst, kann man nie wissen. Bisher sprechen aber keine Anzeichen dafür, obwohl es schon den einen oder anderen Versuch gab, zB mit D. Solche Sprachen fristen aber bisher ein Schattendasein. Und mit "moderneren" Sprachen, wie Java oder C# kannst du C++ sowieso nicht vergleichen. Dafür sind deren Grundstrukturen einfach zu verschieden.
Das schöne an C++ ist ja, neben dem Fakt, dass es eine Multiparadigmen-Sprache ist, dass nativer Code erzeugt wird. Jetzt könnte man meinen, dass damit keine Plattformunabhängigkeit gewährleistet ist, was für die Binaries sicherlich auch stimmt. Der Code selbst kann jedoch trotzdem plattformunabhängig sein. Insofern trifft der Spruch "Write Once, Run Anywhere" auch auf C++ zu. Du musst halt nur für die unterschiedlichen Plattformen neu übersetzen.
Wer also vorhat, ernsthaft zu programmieren, für den lohnt sich C++ auf jeden Fall. Natürlich hängt das auch davon ab, was du letztendlich programmieren willst. Du kannst zwar mit C++ alles machen, nur ob das immer effektiv ist, ist eine andere Frage. Und mit dem kommenden Standard werden hoffentlich die Sachen noch hinzukommen, die man bisher schmerzlich vermisst hat (omg ich will endlich template-alias ).
-
groovemaster schrieb:
Jetzt könnte man meinen, dass damit keine Plattformunabhängigkeit gewährleistet ist, was für die Binaries sicherlich auch stimmt. Der Code selbst kann jedoch trotzdem plattformunabhängig sein. Insofern trifft der Spruch "Write Once, Run Anywhere" auch auf C++ zu. Du musst halt nur für die unterschiedlichen Plattformen neu übersetzen.
Das sehe ich anders. In C++ hast du keine Garantien über die Größe und das Layout von Datentypen, oder die Implementierung der STL.
Beispiel 1: Prozessor A rechnet -1 / 10 == -1, Prozessor B rechnet -1 / 10 == 0
Gibt es beides. Und was rauskommt ist so toll "implementation defined"Beispiel 2: Prozessor A macht 1er Komplement (ein gammeliges Handy halt), Prozessor B macht 2er Komplement.
Beispiel 2: Ich kann Programm mit andern Compiler nicht übersetzen weil bei Compiler x <iostream> <string> mit inkludiert, beim andern nicht
... [endlose Liste fortsetzen] ...
In C++, habe ich das Gefühl, versteht man unter Plattformunabhängigkeit eher den Fakt, dass man auch für nen Toaster einen Compiler schreiben kann. Aber der geschriebene C++ Code, kann sich auf verschiedenen Plattformen/mit verschiedenen Compilern völlig anders verhalten. Daher vermute ich, scheint man in C++ unter "Plattformunabhängigkeit" nicht "Write Once, Run Anywhere", sondern "get a compiler everywhere" zu verstehen. Das deckt sich auch mit dem Design der stdlib. Es gibt nichts (z.B. filesystem), was auf nen Toaster nicht vorhanden sein könnte. Aber genau das erschwert es schon wieder, portablen Code zu schreiben.
-
Optimizer schrieb:
Das sehe ich anders. In C++ hast du keine Garantien über die Größe und das Layout von Datentypen
Was jedoch vollokmmen irrelevant ist. ZB bedeutet int nunmal, du hast eine vorzeichenbehaftete Ganzzahl. Punkt. Nicht mehr und nicht weniger. Und wenn du genaue Bitgrössen brauchst, dann baust du dir dafür einen entsprechenden Typ. Vielleicht gibts ja auch irgendwann eine <cstdint> Headerdatei.
Optimizer schrieb:
oder die Implementierung der STL.
In bestimmten Punkten ist die STL sicherlich abhängig vom System. Das wirft das plattformunabhängige Konzept der STL aber noch lange nicht über den Haufen.
Optimizer schrieb:
Beispiel 1: Prozessor A rechnet -1 / 10 == -1, Prozessor B rechnet -1 / 10 == 0
Gibt es beides. Und was rauskommt ist so toll "implementation defined"Meines Wissens darf laut Standard hier niemals -1 rauskommen, sondern nur 0. IIRC muss bei Ganzzahldivision der "Nachkommaanteil" (bzw. Rest) abgeschnitten werden.
Da kann ich mich aber auch täuschen. Wenn hier auf einem System also -1 rauskommt, würde ich dieses als nicht vom Standard abgedeckt sehen. Insofern ist mir dort Plattformunabhängigkeit relativ egal.Optimizer schrieb:
Beispiel 2: Prozessor A macht 1er Komplement (ein gammeliges Handy halt), Prozessor B macht 2er Komplement.
Was ebenfalls vollkommen irrelevant ist. Die C++ Operatoren sind ja eindeutig definiert. Wie letztendlich das Layout der CPU aussieht interessiert nur den Compiler, aber nicht uns. Sicherlich gibt es gewisse Aussnahmen, wie zB das Shiften von negativen Werten, die implementationsspezifisch sind. Und darüber muss man sich halt im Klaren sein.
Optimizer schrieb:
Beispiel 2: Ich kann Programm mit andern Compiler nicht übersetzen weil bei Compiler x <iostream> <string> mit inkludiert, beim andern nicht
Ich habe zwar nicht den kompletten Standard im Kopf
, aber afaik sind für alle Klassen und Funktionen die Header spezifiziert. Insofern sehe ich keine Probleme damit. Wenn überhaupt, dann ist eine STL Implementierung fehlerhaft. Aber wer garantiert dir denn, dass die JVM auf einem bestimmten System vollkommen fehlerfrei funktioniert?Optimizer schrieb:
In C++, habe ich das Gefühl, versteht man unter Plattformunabhängigkeit eher den Fakt, dass man auch für nen Toaster einen Compiler schreiben kann. Aber der geschriebene C++ Code, kann sich auf verschiedenen Plattformen/mit verschiedenen Compilern völlig anders verhalten. Daher vermute ich, scheint man in C++ unter "Plattformunabhängigkeit" nicht "Write Once, Run Anywhere", sondern "get a compiler everywhere" zu verstehen.
Dann verstehst du in Java unter Plattformunabhängigkeit "get a vm everywhere"?
Tja, dann frag ich mich, was Java oder C# wohl auf einem Toaster machen würden.
Optimizer schrieb:
Das deckt sich auch mit dem Design der stdlib. Es gibt nichts (z.B. filesystem), was auf nen Toaster nicht vorhanden sein könnte. Aber genau das erschwert es schon wieder, portablen Code zu schreiben.
Klar, es ist immer die Frage, wie man Plattformunabhängigkeit definiert. Für mich ist es wie gesagt das "Write Once, Run Anywhere" Prinzip. Und das kann man auch mit C++ relativ gut handeln. Der Aufwand ist zwar teilweise höher, aber du hast dafür letztendlich viele Freiheiten. Und ob du für die diversen Plattformen unterschiedliche Compiler oder VMs bereitstellst, ist ja letztendlich gehüpft wie gesprungen. Und wenn du ein Programm, welches mit Dateien arbeitet, auf ein System portieren willst, was kein Dateisystem kennt, dann stellt sich für mich die Frage nach dem Sinn des Ganzen. Das ist so, wie wenn du jemandem ein Auto kaufen willst, der überhaupt keinen Führerschein hat.
-
groovemaster schrieb:
Wenn hier auf einem System also -1 rauskommt, würde ich dieses als nicht vom Standard abgedeckt sehen. Insofern ist mir dort Plattformunabhängigkeit relativ egal.
Höh? Weil es nicht abgedeckt ist, ist es egal? Es ist gerade nicht egal. Es geht hier genau um den Standard. Es ging um "write once, run anywhere". Wenn es hier Unterschiede gibt, ist es "write once, debug anywhere".
groovemaster schrieb:
Was ebenfalls vollkommen irrelevant ist. Die C++ Operatoren sind ja eindeutig definiert.
Ja sind sind eindeutig implementation-defined definiert.
Warum behauptest du, das sei irrelevant? Es ist äußerst unglaubwürdig, "write once, run anywhere" zu postulieren und dann zu behaupten dass Unterschiede in der Arithmetik irrelevant sind. Unterschiede in der Arithmetik verändern das Verhalten deines Programms und sind für die Semantik eines Programm höchst relevant. Du musst es umschreiben, damit es sich auf der neuen Plattform wie gewohnt verhält. Mit bedingter Compilierung kann man da natürlich schon was rausholen, aber das macht die Sache nicht weniger kompliziert.Ich habe zwar nicht den kompletten Standard im Kopf
, aber afaik sind für alle Klassen und Funktionen die Header spezifiziert.Darauf wollte ich nicht hinaus. Die Header können unterschiedlich implementiert sein, z.B. könnte die Implementierung von <string> den Header <cstring> inkludieren, bei einem anderen Compiler aber nicht. In einem Programm, wo ich jetzt <string> inkludiere, steht mir dann strcpy() vielleicht zur Verfügung, vielleicht auch nicht. Wenn der eine Compiler es mir zur Verfügung stellt, merke ich nicht, dass ich eigentlich <cstring> noch inkludieren müsste und kann mein Programm woanders nicht übersetzen. Das ist nichts, was man nicht schnell beheben kann, klar. Aber es macht sich nicht gut bei Abgaben
und zeigt, dass zwei völlig standardkonforme Implementierungen der STL einen Unterschied machen können.Dann verstehst du in Java unter Plattformunabhängigkeit "get a vm everywhere"?
Nein. Der höchst entscheidende Unterschied ist, Java-Code verhält sich bei jeder standardkonformen Java-Implementierung "gleich", bzw. liegen die Unterschiede in sehr viel kleineren Details. Wenn ich auf einem Handy ein long habe, ist es eine 64Bit-Zahl im 2er-Komplement mit exakt definierter Divisions- und Modulorechnung. Das heißt, ich nehme meinen Code für mein Handy wie er ist und lasse ihn auf einem anderen Handy laufen. Dass ich ihn nicht neu kompilieren muss, ist nicht der große Vorteil. Der Vorteil ist, dass der Source semantisch identisch ist.
Tja, dann frag ich mich, was Java oder C# wohl auf einem Toaster machen würden.
Da gibt es dann eine Java Toaster Edition, so wie es eine Micro Edition für Handy-Programmierung gibt.
Die unterscheiden sich im wesentlichen in der Standardbibliothek, da fallen dann Dinge wie Dateisystem raus.
Das wichtige ist aber, dass die Sprache selber keine Freiheiten lässt, was bestimmte Konstrukte bewirken. Diese Garantie hast du in vielen Sprachen, aber nicht in C oder C++, denn möglicherweise gibt es eine Waschmaschine, auf der das nicht effizient umzusetzen wäre.groovemaster schrieb:
Klar, es ist immer die Frage, wie man Plattformunabhängigkeit definiert. Für mich ist es wie gesagt das "Write Once, Run Anywhere" Prinzip.
Genau, für mich auch.
Und ob du für die diversen Plattformen unterschiedliche Compiler oder VMs bereitstellst, ist ja letztendlich gehüpft wie gesprungen.
Klar, aber darum geht es mir nicht. Es geht mir darum, dass geschriebener Source-Code die selbe Semantik hat. Dass Berechnungen immer das selbe rauskriegen, egal auf welchem System. Es ist mir egal, wenn das 2er Komplement emuliert wird und langsam ist, von einem "falschen" Ergebnis habe ich gar nichts. Wie gesagt, in anderen Sprachen hat das auch seine Grenzen. Das fängt bei Java aber erst damit an, dass die Auflösung von System.nanotime() unterschiedlich ist, bei C++ geht es schon bei grundlegenden Dingen wie Ganzzahl-Arithmetik los.
Klar büßen andere Sprachen dafür ein, weil man sie nicht nach überallhin portieren kann. Deshalb wählt der gute Informatiker für alles das geeignete Werkzeug und weiß, dass es nichts gibt, was immer das beste ist. C++ versucht aber, überall gut implementierbar und benutzbar zu sein und scheitert dabei.
Und wenn du ein Programm, welches mit Dateien arbeitet, auf ein System portieren willst, was kein Dateisystem kennt, dann stellt sich für mich die Frage nach dem Sinn des Ganzen. Das ist so, wie wenn du jemandem ein Auto kaufen willst, der überhaupt keinen Führerschein hat.
Das ist ein guter Punkt, den kann man kaum leugnen. Diesem Punkt versucht man beispielsweise mit Java Micro Edition oder .Net Compact Framework zu begegnen, um die möglichen Zielplattformen zumindest etwas auszudehnen. Aber wenn es keine Straßen gibt, macht ein Auto irgendwann auch keinen Sinn mehr. :xmas1: Da ist es dann besser, man nimmt für die Großstadt die U-Bahn, für das Land ein Auto und für die Pampa ein gutes Paar Schuhe, anstatt einen Schuh mit eingebauter U-Bahn zusammenzufrickeln, den man überall irgendwie benutzen kann.
-
seit wann trollt man jetzt nicht mehr mit anonymen nicks?
-
Optimizer schrieb:
Beispiel 1: Prozessor A rechnet -1 / 10 == -1, Prozessor B rechnet -1 / 10 == 0
prozessor A ist eindeutig kaputt
Optimizer schrieb:
Tja, dann frag ich mich, was Java oder C# wohl auf einem Toaster machen würden.
Da gibt es dann eine Java Toaster Edition, so wie es eine Micro Edition für Handy-Programmierung gibt.
der unterschied ist nur: ein mit c++ programmierter toaster kostet im handel unter 100 euro, einer mit java oder c# weit über 500€
-
*gähn*
Man kann in C++ so programmieren dass es auf mehreren Plattformen übersetzt werden kann, oftmals macht mans nicht weils einfacher ist.Ob C++ zukunftssicher ist... JA!
Unabhängig davon wie toll die Sprache ist oder ob es eine besser Programmiersprache gibt/geben wird sind hierfür zu viele Programme die in C++ geschrieben.
Damit C++ aussterben könnte müsste man erst mal die vorhandenen C++-Programme umschreiben, was ein paar Jahrzehnte dauern, die Weiterentwicklung auf genau die selbe Zeit blockiert und ein schweine Geld kosten dürfte (ohne einen erkennbaren Nutzen für den Anwender).
Da dies niemand der bei Verstand ist macht, wird uns C++ wie auch noch ältere Programmiersprachen eine ganze Weile erhalten bleiben und auch bei Neuentwicklungen eingesetzt werden.
-
Mathias schrieb:
*gähn*
Man kann in C++ so programmieren dass es Plattform übergreifend ist, oftmals machtDu kannst auch zu Fuß nach Moskau gehen.
-
Soll Leute geben, die das gemacht haben.
-
net schrieb:
Optimizer schrieb:
Beispiel 1: Prozessor A rechnet -1 / 10 == -1, Prozessor B rechnet -1 / 10 == 0
prozessor A ist eindeutig kaputt
Nein, der Rest ist 9. Nur weil du das nicht kennst, heißt das nicht, dass es das nicht gibt. So ein System hat Vorteile beim arithmetischen Shiften.
-
Optimizer schrieb:
net schrieb:
Optimizer schrieb:
Beispiel 1: Prozessor A rechnet -1 / 10 == -1, Prozessor B rechnet -1 / 10 == 0
prozessor A ist eindeutig kaputt
Nein, der Rest ist 9. Nur weil du das nicht kennst, heißt das nicht, dass es das nicht gibt. So ein System hat Vorteile beim arithmetischen Shiften.
das hat vorteile? welche? wo gibt es das? hast du ein beispiel?
-
Ich bin darüber gestolpert als ich mit dem MMIX-Assembler gearbeitet habe. Ich weiß jetzt aber nicht mehr, ob der Rest wirklich 9 war. Müsste ich drüber nachdenken, wie dieses System funktioniert.
Die Vorteile beim shiften aber liegen doch auf der Hand. Der arithmetische Rechtsshift von -1 ist billig:1111 / 2 = 1111
Einfach den Wert vom MSB nachschieben, bei positiven Zahlen ergibt sich das gewohnte Verhalten und bei negativen ist hier -1/2 == -1
-
huch? komisch. schlieslich ist eine division was anderes als ein bitshift (bis auf ein paar wenige ausnahmen). wie so'n prozessor intern seine bits verwaltet ist ja eigentlich egal, aber eine integerdivision muss doch 0 ergeben, wenn der teiler zu gross ist, oder nicht? davon abgesehn: wenn man sich fehler einhandelt beim shiften von negativen zahlen hat man natürlich selber schuld...
-
huch? komisch. schlieslich ist eine division was anderes als ein bitshift (bis auf ein paar wenige ausnahmen). wie so'n prozessor intern seine bits verwaltet ist ja eigentlich egal, aber eine integerdivision muss doch 0 ergeben, wenn der teiler zu gross ist, oder nicht?
Nein. Die Division ist dort so definiert, damit man einen arithmetischen Shift leichter bauen kann. Außerdem ist es mathematisch korrekter, weil der Rest immer positiv ist. Man muss das System nicht besser finden, aber es gibt es halt.
davon abgesehn: wenn man sich fehler einhandelt beim shiften von negativen zahlen hat man natürlich selber schuld...
Was soll denn das jetzt? Ich habe dir gezeigt, dass es Prozessoren gibt, die anders dividieren. Was hat das mit "selber schuld" zu tun?
-
also ich finde das seltsam. seit wann kann jeder selber definieren was bei einer division herauskommt?. na gut, dann bastel ich eben einen prozessor der bei division durch grosse zahlen 0x81 berechnet, weil's sich so schön digital verarbeiten lässt. ist ja albern sowas (daumen runter!)
btw: man kann nicht alle / durch bitshifts ersetzen. malnehmen aber geht.