Ist es sinnvoll heute noch C++ anzufangen?
-
C++ ist eine aussterbende Sprache, mit jeder neuen Prozessor generation ein Stück mehr.
-
C++ ftw!
-
wtf c++?
-
Ich habe Herrn Prof. Dankert vor einiger Zeit um eine erneute Aktualisierung seines wahrhaft großartigen Statements für C++ gebeten. Er hat es bisher nicht ergänzt, komplett verändert oder zurückgezogen. Offensichtlich hat er keine aktualisierte Empfehlung zu diesem Thema:
http://www.rzbt.haw-hamburg.de/dankert/ccppjava.html/Hieran erkennt man, dass die Landschaft komplex geworden ist und sich so geändert hat, dass C++ inzwischen ernsthafte Konkurrenz erhalten hat, nicht zuletzt durch C# (Java-Clon von MS).
Im Lowlevel-Bereich beherrscht die geniale Sprache C noch das Feld, was die Mächtigkeit und Klarheit dieser einfachen Sprache unterstreicht.
-
Tja - immer noch kaum Lästereien
Ich habe mal mit eingetippten Hexdumps auf einem 6510/6502 angefangen, dann
Assembler und dann, über dBASE und (gezwungenermaßen) etwas Basic bei C gelandet.
Bis jetzt habe ich da keine Einschränkungen bemerkt die es notwendig machen
würden auf etwas anderes umzusteigen.Als Ergänzung würde mich das interessieren. Für einen Kunden habe ich mal ein
kleines ava-Programm gebaut (er hatte es nicht hinbekommen), etwas PHP und C++
auch mal herumgespielt. Überzeugt hat mich eigentlich keins so weit, darauf
umzusteigen.Mal sehen was sich da noch so tut.
-
tntnet schrieb:
Java hat auch schönere Features. Beispielsweise wird der Destruktor einer Java-Klasse möglicherweise irgendwann aufgerufen.
welcher destruktor? sowas gibts nicht in Java.
-
+fricky schrieb:
tntnet schrieb:
Java hat auch schönere Features. Beispielsweise wird der Destruktor einer Java-Klasse möglicherweise irgendwann aufgerufen.
welcher destruktor? sowas gibts nicht in Java.
Und wie willst du dann wissen, ob er mal aufgerufen werden könnte?
-
...dass der minimale Overhead von Java...
haha
rofl. made my day.unser schulrechner ( = langsam) packt ein 3D spiel (unreal 2001) mit 30 FPS,
aber den roboter in der javavm kann er mit nur 10-fps von A nach B bewegen (2D)nein im erst. im vergleich performance ist C und C++ sehr weit oben.
C++ hat den vorteil dass es objektorientiert ist und damit strukturierter
als C ist (C ist auch schön).guckt euch ein modernes spiel an. kein minispiel auf einer webseite, sondern
eins im laden. ich wette mich euch zu 99% sind die in C++ geschrieben, bei
allen spielen auf meinem pc ist das so. kann jeder mit dem CFF explorer
nachprüfen.
-
einfach irgentwer schrieb:
ich wette mich euch zu 99% sind die in C++ geschrieben, bei
allen spielen auf meinem pc ist das so.wie ging doch gleich der spruch mit den millionen fliegen, die sich nicht irren können? ne, im ernst, performancekritische teile so'nes spiels (grafikengine, usw.) kann man doch in C machen und alles andere in Java oder C# z.b.
und dass rein interpretierende skriptsprachen wie z.b. LUA und Tcl in spielen eingesetzt werden, ist auch nix neues.
-
tntnet schrieb:
Auch hat C++ den Nachteil, dass es Standardisiert ist. Wenn Du heute professionell Programme in C++ entwickelst, läufst Du Gefahr, dass die Programme in 5 Jahren immer noch ohne deprecated-Warnungen übersetzbar sind
die gefahr läuft man garantiert nicht
-
+fricky schrieb:
wie ging doch gleich der spruch mit den millionen fliegen, die sich nicht irren können? ne, im ernst, performancekritische teile so'nes spiels (grafikengine, usw.) kann man doch in C machen und alles andere in Java oder C# z.b.
und dass rein interpretierende skriptsprachen wie z.b. LUA und Tcl in spielen eingesetzt werden, ist auch nix neues.
natürlich. immer zwischen den sprachen wechseln. main kann in jedes programm
noch eine sprache oder script einfügen. das heißt nicht das ich sie benötige.
lua fungiert als eben dieses script. man kann auch ein OS auf C-basis und mit
java entwickeln.natürlich hat auch java seine daseinsberechtigung, aber die frage war ob es
sinnvoll ist C++ zu lernen. das ist es definitiv.
-
damit etwas ersetzt werden kann muss erst einmal etwas besseres vorhanden sein.
-
einfach irgentwer schrieb:
aber die frage war ob es
sinnvoll ist C++ zu lernen. das ist es definitiv.das muss jeder für sich selbst entscheiden. für mich isses z.b. nicht sinnvoll, mehr als die einfachsten grundlagen von C++ zu kennen.
-
Klar ist es sinnvoll noch C/C++ anzufangen, was positiv usw. an dieser Sprache ist wurde ja schon erwähnt, jedoch hat wie gesagt jede Sprache ihren eigenen anwedungsbereich und es ist auch jedem geschmack sache z.b würde ich nie Java oder C# lernen aus folgenden grund:
1.) C# geht nur für Windows, Linux, Mac OS und Solaris sind komplett vernachläsigt.
2.) Zu Java: Schon mal was von exen gehört? Ich finde diese Jar Archive und die schlechte performance einfach gräsllig.
und was mich am meisten stört ist das bei beiden sprache 2 feste organisationen im spiel sind, bei C++ wird der standart per ISO-Norm vorgeschrieben und ich weiß echt nit warum ihr da einen nachteil drin sieht, denn so kann keine firma sagn das das dennen gehört.
Mfg Wikinger75!
-
Lennard_ schrieb:
In den low-level Anwendungsgebieten wird beinahe ausschließlich auf C gesetzt und nicht auf C++. Der Linux Kernel ist ja komplett in C geschrieben, der Großteil des Windows Kernels ebenfalls und die allermeisten Treiber werden auch in C programmiert. Es scheint mir auch so, daß viele Systemprogrammierer eine Abneigung gegen C++ haben und die Sprache keinen sinnvollen Mehrwert auf diesem Gebiet bringt.
Das stimmt so nicht. Man findet zwar noch häufig C in diesem Bereich, aber auch hier zeichnet sich eindeutig ein Trend in Richtung C++ ab. In schätzungsweise 10 Jahren wird all das, was du auflistet, auch in C++ programmiert werden. Das Problem ist, dass es gerade in diesem Bereich viele Entwickler gibt, die nicht bereit sind neue Dinge zu lernen und deshalb an ihrem veralteten C festhalten. Mit einer neuen Generation von Entwicklern wird sich das ändern.
Der Linux Kernel ist ein Monstrum von monolithischem Kernel, der verdammt schlecht designed wurde, nur leider kann man dies nicht so ohne weitere revidieren. Auch sind die Linux Entwickler sofort in ihrem Stolz verletzt, wenn man ihnen das vorhält und faseln dann gerne irgendwas von wegen C++ sei ungeeignet, wobei das wohl eher auf ihre eigene Inkompetenz zurückzuführen ist.
Lennard_ schrieb:
- In den high-level Anwendungsgebieten gibt es bequemere Alternativen mit Sprachen wie C# und Java. Gibt es da Gebiete wo man C++ meinetwegen C# (unter Windows natürlich) vorziehen sollte? Vor allen Dingen unter dem Gesichtspunkt, daß Microsoft ja mit C++/CLI langfristig auch auf die .NET Plattform umsteigen will und unmanaged code im Userspace vielleicht eines Tages gänzlich abgeschafft sein wird.
Das würde ich so nicht sagen. Mit dem neuen C++0x Standard bzw. Boost wird C++ in vielen Bereichen ordentlich aufgepeppt, so dass es locker mit Java, C# usw. mithalten kann. Und viele Dinge, die C++ gerne als Nachteil ausgelegt werden, haben auch eine Kehrseite. Sprachen wie Java oder C# bieten nicht die gleiche Flexibilität wie C++ an. Einiges ist in C++ vielleicht nicht out-of-the-box enthalten, aber man kann alles nachrüsten durch Bibliotheken, wenn man es braucht, man MUSS es aber nicht. Das ist ein großer Vorteil von C++.
-
+fricky schrieb:
welcher destruktor? sowas gibts nicht in Java.
So etwas gibt es Java schon, nennt sich bloß finalize() und wird halt probabilistisch aufgerufen, womit die Methode nutzlos ist. Irgend wie ist das auch so eine Designleiche, die irgend wann mal in der Frühphase des Sprachdesign reingeruscht ist und nun überflüssig ist.
-
Metalag00 schrieb:
Das würde ich so nicht sagen. Mit dem neuen C++0x Standard bzw. Boost wird C++ in vielen Bereichen ordentlich aufgepeppt, so dass es locker mit Java, C# usw. mithalten kann.
Wenige der Neuerungen im neuen Standard zielen auf Konkurrenzfähigkeit mit Java und C# ab.
~john schrieb:
finalize() [...] wird halt probabilistisch aufgerufen, womit die Methode nutzlos ist. Irgend wie ist das auch so eine Designleiche, die irgend wann mal in der Frühphase des Sprachdesign reingeruscht ist und nun überflüssig ist.
Das sehe ich ebenso - aber genau deshalb ist die Gleichsetzung von Destruktoren und finalize() Unfug. Den üblichen Aufgaben eines Destruktors in C++ - der Freigabe von Ressourcen, davon eine der Speicher ist, dessen Verwaltung in GC-Umgebungen eben nicht mehr dem Programmierer aufgebürdet ist - kommt die dispose()-Methode am nächsten.
(Es sei natürlich denn, man stößt auf eine der Lücken in der Abstraktion - dann darf man sich mit manueller Referenzzählung oder mit Weak und Phantom References herumschlagen :p).
-
Wikinger75 schrieb:
bei C++ wird der stan**** per ISO-Norm vorgeschrieben und ich weiß echt nit warum ihr da einen nachteil drin sieht...
vieles ist darin garnicht erwähnt, den compiler-herstellern überlassen, oder endet in undefiniertem verhalten. nimm nur mal so grundlegende dinge wie einfachsten datentypen. ein popeliger 'int' kann hier 16 bit breits sein, wo anders isser 32 bit breit und wieder wo anders 73 bits, usw. wer dass nicht weiss und annimmt, ints wären immer 32 bits breit, kann schon mal pech haben.
-
~john schrieb:
+fricky schrieb:
welcher destruktor? sowas gibts nicht in Java.
So etwas gibt es Java schon, nennt sich bloß finalize() und wird halt probabilistisch aufgerufen, womit die Methode nutzlos ist.
sie wird immer aufgerufen, wenn der GC das objekt löscht (ausser bei JVM-implementationen ohne GC), nicht mit 'ner wahrscheinlichkeit von 70...80% oder so, sondern immer. du kannst nur den zeitpunkt nicht vorhersehen, d.h. solange es nicht passiert, ist das objekt noch am leben. deswegen sollte man 'finalize()' auch nicht als destruktor missbrauchen. aber in Java so wie in C++ zu programmieren, ist generell eine schlechte idee.
-
+fricky schrieb:
sie wird immer aufgerufen, wenn der GC das objekt löscht (ausser bei JVM-implementationen ohne GC), nicht mit 'ner wahrscheinlichkeit von 70...80% oder so, sondern immer.
Es sei natürlich denn, das System verfügt über hinreichend viel Speicher, daß der GC gar nicht in Aktion tritt, sondern sämtlicher Speicher bei der Terminierung der Anwendung freigegeben wird - denn gerade in dieser Situation ist Speicherverwaltung mit GC deutlich effizienter als die manuelle Variante. Da dieser Fall nicht ganz ungewöhnlich ist, dürfte das Phänomen keineswegs auf "JVM-Implementationen ohne GC" beschränkt sein.