Lohnt es sich noch C++ zu lernen?
-
Ich schicke es dir morgen Abend. Bis zum 13.10. kann ich vielleicht noch ein paar mehr Funktionen einbauen; aber wenn man um 17:30 von der Schule heimkommt, hat man auch nicht so viel Zeit...
-
\aleph_0 schrieb:
Ich schicke es dir morgen Abend. Bis zum 13.10. kann ich vielleicht noch ein paar mehr Funktionen einbauen; aber wenn man um 17:30 von der Schule heimkommt, hat man auch nicht so viel Zeit...
Lass dir ruhig Zeit. Reicht auch, wenn du es erst am 13. schickst.
-
Ich möchte noch einmal auf die Ausgangsfrage zurück kommen. Wer sich auf C/C++ einlässt, hat ein weites Land vor sich und wird sich oft verheddern. C/C++ deckt die maschinennahe Programmierung (auch im Wechselspiel mit Assembler), die klassische Programmierung (Strukturen, Prozeduren), OOP und generische Programmierung ab. Gerade im Rahmen der OOP ist es extrem schwer, alles richtig zu machen. Da wimmelt es nur so von Stolperfallen und komplizierten Ratgebern. C++ ist daher insbesondere für diejenigen interessant, die auf den Gipfel wollen. Die Lernkurve kann man nur in Jahren beziffern, in wenigen Wochen ist da nichts möglich. Das muss man wissen, wenn man sich auf diese Sprache einlässt. Hier gilt wirklich: "Der Weg ist das Ziel."
-
Gregor schrieb:
Wenn du Java immernoch als reine Interpretesprache bezeichnest, dann hast du das Prinzip von Java offensichtlich nicht verstanden.
Lies doch bitte nochmal genau nach. Ich habe Java nirgendwo als reine Interpretersprache bezeichnet. Aber das Java kein richtiger Maschinencode ist, ist dir wohl hoffentlich klar...
-
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.