Lohnt es sich noch C++ zu lernen?
-
Warum so viel umstaende mit dem Testprogramm ....
Die Aufgabenstellung kann ganz einfach sein !
Irgendein DialogFeld mit nem Listview mit 3 SPalten (ReportView), oder was aehnlichem ... weiss ned wie es in Swing heisst ... oder ne QlistView ....
Dzu nen startbutton.
Wenn man den Startbutton drueckt, soll die Listbox mit 100000 Eementen Befuellt werden. Dabei sollen die SPallten nach volgenden Musster befuellt werden :
A00000 B00000 C00000
A00001 B00001 C00001
A00002 B00002 C00002
...die gebrauchte zeit zum einfuegen wird gemessen .... !!!
Koennen ja nen Wettbewerb machen.
Ich wuerde auf folgendes Ergebnis bei dem Vergleich der Programmiersprachen / Technicken tippen ...1. C und reiner WinAPI
2. VC++ mit MFC
3. C unter X mit ner Biblo ... also Motif oder ähnliches. (ham die Listviews ???)
4. Visual Basic
5. C++ mit QT
...
ne ganze weile nix
...
XXX. Java !!! Unter allen Plattformen ...Problem waere das plattformuebergreifend zu messen ...
wobei bei den ersten kanditaten die unterschiede bestimmt in den Rahmen der messungenauigkeit fallen wuerden ... aber nen signifikanter Unterschied zu Java wuerd ich schon erwarten ....Jemand andere Tipps ???
Ciao ...
-
wirklich sehr dummer Vorschlag....
-
100000 Elemente? Sehr realistisch
-
Mir viel nix besseres ein
ob realismus hin oder her ...
Gut, koennte ja auch ne listbox mit 10 eintraegen nehmen, und die 100000 mal leeren und wieder neu befuellen ???Zielt zumindest genau in die Richtig ab, wo ich die schwaechen von java sehe ....
Ciao ...
-
Um mal zur Ursprungsfrage zurückzukommen:
Natürlich lohnt es sich nicht mehr C++ lernen. Die Sprache ist veraltet.
-
So ein Quatasch. Latein spricht man seit hunderten von Jahren nicht mehr und trotzdem geistert es noch herum. So wird das auch mit Basic und C++ sein. Bei Java bin ich mir nicht sicher.
Ich stell mir nur die C64-Situation für den PC in 20 Jahren vor: ein PC-Emulator ist da, aber wer kann noch eine Java-Umgebung irgendwoher bekommen? Und wer will in 20 Jahren den Sinn begreifen?
-
Naja, ein bisschen Lebendiger als Latein ist C++ aber wohl doch!
-
..
-
Erhard Henkes schrieb:
C++ ist die Vorlage für Javascript
Sicher? Die Objektmodelle von C++ und Javascript unterscheiden sich drastisch, das eine ist klassenbasierend und das andere prototypbasierend. Oder machst du das an Oberflächlichkeiten wie der Syntax fest?
-
Erhard Henkes schrieb:
Ich halte nach wie vor folgenden Weg für sinnvoll:
(C ->) C++ -> C/C++/WinAPI -> C++/MFC -> Java (-> C#)
Um es mal genauer zu Formulieren: "Von hinten durch die Brust ins Auge."
-
Gregor schrieb:
Beispiele für Programme, die mit Java gemacht sind:
Spiele (100% Java):
Magicosm : www.magicosm.net
Arkanae : http://arkanae.tuxfamily.org/en/index.html
Law And Order : http://www.gamerankings.com/htmlpages2/531108.asp
Law And Order 2
Alien Flux : http://www.puppygames.net/info.php?game=Alien_FluxBist Du Dir sicher daß die 100% (!!) Java sind?!?!
Auf jeden Fall laß ich eben DAS hier:
The Chrome game uses Java language developed by Sun. the whole logics of the game
and the engine is based on Java language. It is a very convenient solution that enables easy to
extend the game itself (so called mods). Java language is fairly easy to learn and there is a
vast selection of documentation. If you are going to modify the Chrome game there’s no
better choice then using Java language.[EDIT] Naja, die Logik meines Schachspiels ist ja auch in Java, während die GUI in C++ & OpenGL gemacht wurde...
[/EDIT]
-
Sgt. Nukem schrieb:
Bist Du Dir sicher daß die 100% (!!) Java sind?!?!
Wenn man davon absieht, dass einige dieser Spiele Bibliotheken nutzen, mit denen man OpenGL oder Direct3D von Java aus nutzen kann (LWJGL, JOGL, Gl4Java, Java3D,...), dann sind diese Spiele nach meinen Informationen zu 100% aus Java.
Naja, ist Definitionssache, ob das 100% Java ist. Nach Sun kann ein Programm, welches Java3D nutzt durchaus als 100% Java gelten. Andere sehen das enger.
BTW: Was sagt ihr eigentlich zum aktuellen Benchmark von C#, C++, Java und Delphi in c't 21/2003 S.222? Da sieht C++ ja eigentlich garnicht so gut aus. Hat sich schon jemand die Mühe gemacht, sich den Quellcode der C++-Programme anzugucken und zu analysieren, welche "Performance-Fehler" gemacht wurden? ...oder wurden keine gemacht und C++ ist tatsächlich so unperformant?
-
welche "Performance-Fehler" gemacht wurden
Hehe, beim ersten mal grob ueberblaettern, dacht ich auch mich trifft der Schlag!
Meine Vermutung ist, die Performance Bremse ist das CObject, von dem alle Elemente abgeleitet sind. Strittig ist die Frage, ob das, wie im Text behauptet, uebliches Vorgehen ist !
Also ich leite meine Datenobjecte nie von CObject ab .... ! (arbeite auch kaum mit der MFC). Weiterhin fehlt auch die aussage, ob die MFC statisch oder dynamisch zugelinkt wurde ...Naja, kritik ueber den Artikel wird in der naechsten C't sicher ned lange auf sich warten lassen.
Ciao ...
-
BTW: Was sagt ihr eigentlich zum aktuellen Benchmark von C#, C++, Java und Delphi in c't 21/2003 S.222? Da sieht C++ ja eigentlich garnicht so gut aus. Hat sich schon jemand die Mühe gemacht, sich den Quellcode der C++-Programme anzugucken und zu analysieren, welche "Performance-Fehler" gemacht wurden? ...oder wurden keine gemacht und C++ ist tatsächlich so unperformant?
Soll das ein Witz sein. Ich kann mir kaum vorstellen, dass irgendjemand der auch nur ein Gramm Ahnung hat, diesen Artikel ernst nehmen kann. Ich habe beim Lesen gedacht, dass sei ein vorgezogener Aprilscherz.
1. Warum sind die Typen auf Delphi.Net gespannt, vergessen aber C++.Net zu testen (managedC++). Damit hätten sie wenigstens mal eine Aussage treffen können. Damit würde man wenigstens wissen, welchen Einfluss das .NET-Framework hat.
2. Warum verwenden die Typen die MFC statt der Standardbibliothek? Und warum dann noch diesen schwachsinnigen CObArray-Container?
3. Warum erbt SingleEntry und ListEntry von CObject? Warum verwenden sie überhaupt Vererbung, wenn SingleEntry nachher mit einem bool-Flag endet, das true liefert, falls es sich um eine Liste handelt?
4. Warum enthält der Originalquelltext unzählige Syntaxfehler, so dass er sich nicht mal übersetzen lässt.
5. Warum faseln die Typen irgendwas von "kompliziertes C++ Objektmodell", wenn sie offensichtlich keinen blassen Schimmer davon haben (a) es gibt kein standardisiertes C++ Objektmodell, b) die Komplexität hängt von der Situation ab, c) bei einfacher Vererbung ist es super simpel, d) die Typen sollten wenigstens mal "Inside the C++ Object Model" lesen)
6. Warum suchen die Typen nicht nach dem wirklichen Problem statt von dem "komplizierten C++ Objektmodell" zu faseln, von dem sie, wie in 5. bereits erwähnt, offensichtlich keinen blassen Schimmer haben.
7. Warum legen sie COBArray auf dem Heap an? (das macht drei new-Aufrufe pro add)
8. Warum übergeben sie ihre String-Objekte by value?
9. Warum verwenden sie CString, obwohl die Standardisierung von C++ nun seit mittlerweile 5 Jahren abgeschlossen ist und die Standardlib eine Stringklasse anbietet?
10. Warum liefert mein 800Mhz Athlon nach kleinen Code-Korrekturen mit den Standardeinstellungen des VC 6 Ergebnisse die näher am 2Ghz Pentium als am 1Ghz Athlon liegen?
10. Warum haben die so unglaubliche Destruktionszeiten, während ich hier ohne wilde Optimierungen auf 0.2Sek komme?
11. Warum verwenden die so einen seltsamen Algorithmus? Wo sich dieses Problem doch viel besser durch einen sorgsamen Algo statt einer anderen Sprache optimieren lässt?
12. Warum sagen die kein Wort über Dinge wie Programmgröße oder Prozessgröße?Ich glaube ich könnte hier noch stunden weiter schreiben. Das führt aber wohl zu nichts.
Mein Fazit zu diesem Artikel:
Wer kann sollte drüber lachen. Alle anderen sollten ihn ignorieren.
-
Gregor schrieb:
Sgt. Nukem schrieb:
Bist Du Dir sicher daß die 100% (!!) Java sind?!?!
Wenn man davon absieht, dass einige dieser Spiele Bibliotheken nutzen, mit denen man OpenGL oder Direct3D von Java aus nutzen kann (LWJGL, JOGL, Gl4Java, Java3D,...), dann sind diese Spiele nach meinen Informationen zu 100% aus Java.
Naja, ist Definitionssache, ob das 100% Java ist. Nach Sun kann ein Programm, welches Java3D nutzt durchaus als 100% Java gelten. Andere sehen das enger.
Nee, dann ist's okay, dann ist's für mich auch 100% Java...
Solang die da nix mit JNI oder so zusammenfuchteln (wie ich)...
-
HumeSikkins schrieb:
BTW: Was sagt ihr eigentlich zum aktuellen Benchmark von C#, C++, Java und Delphi in c't 21/2003 S.222? Da sieht C++ ja eigentlich garnicht so gut aus. Hat sich schon jemand die Mühe gemacht, sich den Quellcode der C++-Programme anzugucken und zu analysieren, welche "Performance-Fehler" gemacht wurden? ...oder wurden keine gemacht und C++ ist tatsächlich so unperformant?
Soll das ein Witz sein.
Ja, hast du den Smilie nicht gesehen?!
Mir ist schon klar, dass der Benchmark nicht ernstgenommen werden kann. Die Autoren haben weder Ahnung von C++ noch von Java, sondern kommen aus der .NET- und Delphi-Ecke. Die wollten wohl ihre Sprachen einmal sehr gut darstellen.Wenn der Benchmark überhaupt etwas zeigt, dann das, dass es in erster Linie vom Programmierer abhängt, wieviel Performance bei diesen Sprachen rausgeholt wird.
-
Mein Fazit zu diesem Artikel:
Wer kann sollte drüber lachen. Alle anderen sollten ihn ignorieren.Also mir fällt eher ein
oder ein 
ein, als ein :D.Ich fand aber schon immer, dass die c't in Sachen Software nicht sonderlich umwerfend ist, aber wenn es um Hardware geht ist sie IMHO unschlagbar.
PS: @HumeSikkins: Darf man deine Code-veränderungen mal sehen?
-
PS: @HumeSikkins: Darf man deine Code-veränderungen mal sehen?
Nach dem ich an dem Versuch die Java-Version zum Laufen zu bringen gescheitert bin, habe ich das komplette Verzeichnis wieder gelöscht.
Viel verändert habe ich nicht.
Hauptsächlich Syntaxfehler korrigiert.
Die meisten Sachen habe ich noch im Kopf:1. Ändere Syntaxfehler im Originalquellcode (Die definieren da dauernd Methoden von BSingleEntry und BListEntry. Das sollte aber CSingleEntry und CListEntry heißen. Ersetze im CListEntry-Ctor TList durch CListEntry.
Streiche das nach Änderung 4 ersatzlos.
Streiche letztes delete im Destruktor von CListEntry. Die Liste ist schließlich ein Stack-Objekt und kann deshalb nicht mit delete gelöscht werden).2. Ändere alle const CString Parameter in const CString&
Alternativ: Ersetze CString durch std::string3. Streiche CObject-Basisklasse von CSingleEntry und CListEntry
4. Ersetze CObArray durch vector<CSingleEntry*>
5. Korrige die build-List-Methode entsprechend.
Ich habe dann noch irgendwas in den Konstruktoren verändert, weiß aber nicht mehr genau was. Außerdem habe ich spassighalber mal die virtuellen Dtoren entfernt und stattdessen gecastet. Hat beides aber keinen signifikanten Geschwindigkeitsunterschied gebracht.
Die Zeiten habe ich hier aber noch:
1. Gesamtlaufzeit: 10.75 - 11.3 (by value Übergabe)
2. Konstruktion(?): 4.50 - 4.69
3. Destruktion: 0.2 (vector + iterator-Schleife) - 0.9 (CObArray +
Zählschleife + CObject-Basisklasse)
4. Suche(?): 5.7 - 5.9System: Win98 SE, Athlon TB 800Mhz, 256MB RAM (60% frei), VC 6.0 EE, Release-Modus.
-
Hi,
interessante Diskussion !
Was sagt den dieser Mikrobenchmark aber trotzdem aus ? Ich benutze recht oft for-Schleifen, wie macht man es denn besser ? Ausserdem ist dieses Programm so minimal, da kann man doch nichts mehr optimieren. Und dann schneidet da C++ noch schlechter ab, das überrascht mich und ein so überraschendes Ergebnis muss doch auch was aussagen.
Ansonsten wurde irgendwo am Anfang der Diskussion folgendes gesagt
Ok, ich habe jetzt nach längerem Suchen eine Seite gefunden, auf der ein Beta-Tester von IL-2 deine Aussage bestätigt. IL-2 nutzt Java, aber der Java-Anteil scheint nicht so groß zu sein, wie die 90%, die auf einigen Seiten behauptet werden. Ich nehme es aus der Liste. Geringe Java-Anteile sind übrigens auch in Spielen wie Vampire oder Star Wars Galaxies vorhanden.
Was heisst "zu geringen Teilen" ? Weniger als 10% ? Was macht das für einen Sinn, also man könnte z.B. die Engine in C++ proggen und dann per JNI ansprechen, aber dann würde ich nicht mehr von "geringen Teilen" sprechen.
Wo macht es Sinn ein Spiel in geringen Anteilen in Java zu entwickeln ?
Und Vampire hatte ich mal auf meinem Rechner und soweit ich weiss brauchte ich keine JRE dafür, wie ist das zu erklären ?
-
Real_PsychoDAD schrieb:
Wo macht es Sinn ein Spiel in geringen Anteilen in Java zu entwickeln ?
Und Vampire hatte ich mal auf meinem Rechner und soweit ich weiss brauchte ich keine JRE dafür, wie ist das zu erklären ?
Vampire hat Java zum Beispiel für das Skripting benutzt. Das wäre zum Beispiel etwas, was ich als "geringen Teil" bezeichnen würde. Spiele, die u.a. Java nutzen, werden normalerweise ihre eigene Laufzeitumgebung mitbringen oder es wird ein native-Compiler genutzt werden, so dass keine Laufzeitumgebung benötigt wird.
das überrascht mich und ein so überraschendes Ergebnis muss doch auch was aussagen.
Ja, da du ja schon gesehen hast, dass HumeSikkins Verbesserungsvorschläge hat, wodurch die C++-Version deutlich schneller laufen würde, sollte die Aussage für dich sein, dass Benchmark-Ergebnisse mit Vorsicht zu genießen sind. Egal, wie sie aussehen. Man sollte immer beachten, wer den Benchmark gemacht hat, wer den Benchmark finanziert hat, in welchem Zusammenhang der Benchmark veröffentlicht wurde etc.! Wenn sich jemand mit mehreren Sprachen auskennt, dann kann er allein schon durch die Wahl des Benchmark-Themas bestimmen, welche Sprache vorne liegt, weil einfach jede Sprache (und jeder Compiler) Schwachstellen hat.
Nun, ich will den Autoren des c't-Benchmarks nicht unterstellen, dass sie mit Absicht die anderen Sprachen haben schlecht aussehen lassen. Viel wahrscheinlicher finde ich, dass die Autoren von C++ (und auch Java) nicht so sehr viel Ahnung haben und deshalb unfähig sind, in der jeweiligen Sprache den performantesten Code zu schreiben. C++ schneidet wohl deshalb so schlecht ab, weil es so viele Ausdrucksmöglichkeiten bietet, dass man auch sehr viele Möglichkeiten hat, sich schlecht auszudrücken. Die Autoren wollten ihr Programm wohl 1:1 portieren, haben aber nicht bedacht, dass sich C++ doch recht deutlich von C# und Java unterscheidet. Das ist ein sehr gutes Beispiel dafür, dass man nicht versuchen sollte, die Denkweise, die man in einer Sprache hat, auf eine andere zu übertragen. Das nicht ganz so schlechte Abschneiden von Java ist nur dadurch zu erklären, dass sich C# und Java eben nicht so sehr unterscheiden.