Unterschiede C++/C#
-
Ich bin im Gegensatz zu Moonlight ein fan der Programmiersprache Java, aber ich sehe das Problem eher das es zum Thema Spieleprogrammierung in Java keine Literatur auf deutsch gibt.
Zu Direct X/c++ gibt es einiges zu Spieleprogrammierung Java leider nur auf Englisch.Ich habe mir das in diesem Thread angesprochene Spiel Cube runtergeladen, weil ich mal ein 3D-Spiel in Java geschrieben sehen wollte.
Die Sources sind alle in C++
-
Annakin schrieb:
Ich bin im Gegensatz zu Moonlight ein fan der Programmiersprache Java, aber ich sehe das Problem eher das es zum Thema Spieleprogrammierung in Java keine Literatur auf deutsch gibt.
Zu Direct X/c++ gibt es einiges zu Spieleprogrammierung Java leider nur auf Englisch.Nimm mir das nicht boese, aber, wenn man Programmierung betreiben will, ist es
ein _muss_, sich frueher oder spaeter mit englischer Literatur zu beschaeftigen.Die englischen Fachbuecher, die ich habe, sind alle samt in sehr einfachem
Englisch geschrieben. Und das was man nicht weiss, erschliesst sich meist aus
dem Kontext oder man schaut es halt nach.mfg
v R
-
Ich weiß um Englisch führt über kurz oder lang kein Weg drumherum.
Ich versuche es nur so weit wie möglich vor mir herzuschieben
-
Naja, wenn es ein Buch in deutsch und englisch gibt, bevorzuge ich auch immer die deutsche Version. Hat nichts damit zutun ob ich englisch kann oder nicht. Aber ich denke und träume auch auf deutsch, also was soll ich mir mit einem englischen Buch einen Ast abbrechen?
Wenn es ein Buch nur auf englisch gibt und ich es unbedingt haben muß, dann wirds halt auf englisch gelesen.
-
Artchi schrieb:
Naja, wenn es ein Buch in deutsch und englisch gibt, bevorzuge ich auch immer die deutsche Version. Hat nichts damit zu tun ob ich englisch kann oder nicht. Aber ich denke und träume auch auf deutsch, also was soll ich mir mit einem englischen Buch einen Ast abbrechen?
Wenn es ein Buch nur auf englisch gibt und ich es unbedingt haben muß, dann wirds halt auf englisch gelesen.
So sehe ich das auch, wenn möglich auf deutsch.
Aber das Angebot an englischer Literatur ist bei weitem größer als das an deutscher.
Einige der "deutschen" Bücher sind auch Übersetzungen aus den Englischen, z.B. Lippmann "C++ Primer".
Da die Übersetzung einige Zeit dauert muß man wenn man aktuelle Literatur haben will auf englische Bücher ausweichen.Mehr Spass macht es aber die Bücher auf deutsch zu lesen.
-
Ja, Longhorn wird ja immer als der Punkt genannt, der .NET dann zum Durchbruch verhelfen soll. Soll wohl in etwa 1,5 Jahren herauskommen, wenn ich mich nicht irre und es wird wohl noch mindestens 2-3 weitere Jahre dauern, bis es das aktuelle Windows von der Verbreitung her übertrifft. Bis dahin kann also noch eine ganze Menge passieren. Ok, .NET soll in Longhorn deutlich besser integriert sein, was oft als Grund angeführt wird, warum .NET dadurch so einen Aufschwung erhalten soll. Ich frage mich jetzt allerdings gerade ganz naiv: "Warum eigentlich?". Warum ist das so ein Killerargument, auf das letztendlich der gesamten .NET-Hype setzt? Was hat man ganz konkret als Entwickler und als Nutzer davon? Wird die Entwicklung unter .NET plötzlich viel einfacher werden (Das müßte ja mit einer massiven Veränderung der Standardbibliothek einhergehen.)? Oder wird MS die Entwicklung mit anderen Sprachen erschweren?
Das ist so ein Punkt, über den ich mir noch gar nicht wirklich Gedanken gemacht habe und über den ich mich noch nicht wirklich informiert habe. Deshalb würde ich gerne wissen, was ihr so darüber denkt und wißt.
Mit Longhorn kommt WinFX, die Ablösung von Win32. Natürlich kann man weiterhin Win32 verwenden, aber eher aus Kompatibilitätsgründen.
Wenn das native API des Betriebsystems auf .Net basiert kann es durchaus sinnvoll sein auch auf .Net zu setzen.
-
Helium schrieb:
Mit Longhorn kommt WinFX, die Ablösung von Win32. Natürlich kann man weiterhin Win32 verwenden, aber eher aus Kompatibilitätsgründen.
Wenn das native API des Betriebsystems auf .Net basiert kann es durchaus sinnvoll sein auch auf .Net zu setzen.Folgender (gerade gefundener) Artikel steht zwar IMHO nicht im Widerspruch zu deiner Aussage hier, ist für einige hier aber sicherlich interessant, um mal etwas abzugrenzen, wofür .NET bei Longhorn überhaupt genutzt wird:
http://www.eweek.com/article2/0,1759,1820686,00.asp
Das scheint sich also auf einen sehr kleinen Kernbereich zu beschränken, der aber natürlich äußerst zentral liegt und wichtig ist.
-
...und noch ein Zitat:
http://www.microsoft-watch.com/article2/0,1995,1820607,00.asp schrieb:
As our sources noted, the decoupling of the .Net Framework from Longhorn isn't bad news disguised in sheep's clothing. There is an upside to the decision. One of our aforementioned folks explains: "A big benefit of the new plan is that developers don't have to move to .Net if they want to use new Longhorn features."
Da wird also doch nicht nur ein altes API aus Kompatibilitätsgründen erhalten, sondern es werden neue Features ohne .NET nutzbar sein.
-
Tja, ich war wohl nicht mehr auf dem laufenden. In einem deiner Artikel steht ja:
"The original plan for Longhorn was to build lots of components on top of the next version of the .Net Framework," according to one of our developer sources, who requested anonymity. "But given how late [.Net Framework 2.0] is, and how new it would be, [Microsoft chairman] Bill Gates realized it would be foolish to build important pieces of Longhorn on top of .Net."
-
Zu Direct X/c++ gibt es einiges zu Spieleprogrammierung Java leider nur auf Englisch.
den Satzt versteh ich jetzt nicht so ganz. Meint er nun Spieleprogrammierung unter Java mit DirectX oder C++ mit DirectX ?
Irgendwie macht DirectX mit Java ja keinen Sinn, weil man dann die Plattformunabhängigkeit ja vollkommen verliert.
-
Ich glaube, er meinte, dass es zu C++/DirectX viele Bücher auch auf deutsch gibt, zur Spieleprogrammierung mit Java jedoch kaum.
-
guyondrugs schrieb:
Ich glaube, er meinte, dass es zu C++/DirectX viele Bücher auch auf deutsch gibt, zur Spieleprogrammierung mit Java jedoch kaum.
Genau das meine ich, zu Direct X (und damit natürlich für C++) gibt es einige Bücher auf deutsch zu Java und Spieleprogrammierung kein einziges.
-
Annakin schrieb:
Genau das meine ich, zu Direct X (und damit natürlich für C++) gibt es einige Bücher auf deutsch zu Java und Spieleprogrammierung kein einziges.
Wenn du mit Java Spiele programmieren möchtest, dann wirst du dazu in erster Linie einen OpenGL-Wrapper wie JOGL oder die LWJGL nehmen. Hierzu mußt du wissen, dass OpenGL über diese Wrapper von Java aus praktisch genauso zu nutzen ist, wie von C++ aus. Du kannst also letztendlich ein OpenGL-Buch nehmen, welches auf C++ basiert und dieses für Java nutzen. Den Transfer von C++ zu Java mußt du da schon schaffen, das sollte aber auch nicht so schwer sein.
Explizite "Java für Spiele"-Bücher wirst du kaum finden, weil Java im Spielesektor einfach noch nicht so populär ist.
-
Oh du geheiligtes C++, du bist das schnellste auf Erden
Java ist eine Sprache, und eine Sprache ist weder "schnell" noch "langsam".
Wenn jetzt Intel einen Javacompiler rausbringen würde wären die damit generierten Executables wohl nur unwesentlich langsamer als von dem Intel C++ Compiler.
Wird denn nicht immer damit Argumentiert dass C++ "platformübergreifend" sei?
Und wer programmiert denn wirklcih damit komplett plattformübergreifend? Die Leute werden sicherlich bestätigen dass die ganzen "Wrapper" auch viel von der Perfomance nehmen. Ich bezweifele sehr dass ein durchschnittlicher C++ Programmierer ohne gute, optimierende Compiler (Intels, gcc usw) und (fast genauso wichtig) schnelle, optimierte Libs eine flotte Executable produziert. Ich hab nämlich schon genug VC++ 6.0 "Auswüchse" im Debugger gesehen und das ist nicht das schlimmste was es gibt. Nicht "C++" ist superschnell (nein, kein Flame ) sondern es ist so weit verbreitet dass sich viele die "Mühe" machen angepasste, bessere Compiler rauszubringen (Intel - macht Geld damit,direkt und indirekt)
oder Libs zu optimieren. Wenn jetzt sich jemand Java annehmen würde und dafür einen "richtigen" Compiler mti allem drumherum schreiben, eventuell die Libs verbessern und besser an die Plattformen anpassen würde dann würde da vieles von der "C+++ Schnelligkeit" schwinden. Und überhaupt, wenn man von schnelligkeit spricht: dann müsste man auch immer C oder Assembly nehmen. Und ja: wenn mans kann, dann schlägt man in Asm immer noch jeden Compiler Jedenfalls ist mir keine Mersenne-Twister Implementierung in C++ bekannt die nur 18 Ticks braucht.Halt ich auch für ein gerücht... es sind eben völlig andere ziele und zugänge.. c++ ist meiner mienung nach noch ne etage tiefer als java. Sieht man doch schon daran wie eingeschränkt es ist im gegensatz von c++. Ich kann mir nicht wirklich vorstellen das sie einen COmpiler entwickeln der java c++ bei richtiger anwendung überholen lässt. Ich hab schon codes gesehen wo mithilfe von templates und inline der compiler von c++ dazu gebracht wurde code zu erstellen der !besser! ist als die gleiche funktion in asm. Jetzt werden einige aufheulen und sagen das es das nicht gibt... tja doch da der compiler hier so optimiert hat das er alles zusammengefast hat und am ende inlined und es dann nurmehr sachen wie add register,value1 add register value2 usw. sind. Das kann man mit einer asm funktion so malnicht realisieren (es sei denn mann schreibt hier in dem beispiel jede vektoraddition von hand und keine funktion dafür...) Um aufs thema zurück zukommen: sowas ist in java absolut unmöglich, ist aber auch nicht wirklich das ziel.
Am schluss noch meine bescheidene meinung zu games und so... ich finde sie sollten nicht in java sein da das einfach verschwendung von resourcen ist... ich mein dann brauch ich ein 2.5 ghz system um pong zuspielen, wo fürht das hin (für die flamer: das war übertrieben, klar
) Spiele sollten verflucht gut optimiert sein und alles rausholen.. dass das nicht der fall ist (auch nicht bei c++ spielen) ist mir klar aber das muss sich einfach ändern. Und java ist einfach ungeeignet dafür... sry. aber es gibt viele andre anwendungsbereiche wo java durchaus sogar die bessere wahl ist.cu Manuelh87
-
Manuelh87 schrieb:
Um aufs thema zurück zukommen: sowas ist in java absolut unmöglich
Warum?
-
Gregor@Home schrieb:
Wenn du mit Java Spiele programmieren möchtest, dann wirst du dazu in erster Linie einen OpenGL-Wrapper wie JOGL oder die LWJGL nehmen. Hierzu mußt du wissen, dass OpenGL über diese Wrapper von Java aus praktisch genauso zu nutzen ist, wie von C++ aus. Du kannst also letztendlich ein OpenGL-Buch nehmen, welches auf C++ basiert und dieses für Java nutzen. Den Transfer von C++ zu Java mußt du da schon schaffen, das sollte aber auch nicht so schwer sein.
Na ja, da kann ich auch gleich in C++ programmieren.
Ich habe mir mittlerweile C++-Grundkenntnisse angeignet.
Mittlerweile freunde ich mich mit dieser Sprache immer mehr an.
Ich muß auch sagen das was ich an 3D in Java gesehen habe (z.B. Tribal Trouble, erstellt mit LWJGL ) hat mich nicht so überzeugt.
Wenn ich die Grafik als das zur Zeit machbare unter Java in 3D ansehe, so liegt die doch um ein paar Jahre hinter dem heute in C++ möglichen.
Ich habe zwar angenommen das Java etwas langsamer ist als C++, aber der Unterschied ist doch relativ groß.Gregor@Home schrieb:
Explizite "Java für Spiele"-Bücher wirst du kaum finden, weil Java im Spielesektor einfach noch nicht so populär ist.
In Deutschland leider nicht.
-
Annakin schrieb:
Gregor@Home schrieb:
Explizite "Java für Spiele"-Bücher wirst du kaum finden, weil Java im Spielesektor einfach noch nicht so populär ist.
In Deutschland leider nicht.
Wo denn?
-
Walli schrieb:
Annakin schrieb:
Gregor@Home schrieb:
Explizite "Java für Spiele"-Bücher wirst du kaum finden, weil Java im Spielesektor einfach noch nicht so populär ist.
In Deutschland leider nicht.
Wo denn?
Siehe andere Antwort von mir in diesem Thread
-
Gregor@Home schrieb:
Warum?
Sag mal hast du verstanden was ich dir da geschrieben hab?? Kannst du in java mit inline und templates arbeiten?? Ich glaube nicht und daher geht das nicht. Das ist nicht so einfach vorzustellen was dieser code macht den ich da erwähnt habe aber es ist so das es am ende alles (mit optimierung) meist in einem register ist und die serie von + operatoren alles zusammengefasst wird und am ende ersetzt der compiler alles mit add register, value1 add register, value2 usw. kein funktionsaufruf. kein register sichern alles völlig direkt und sowas geht in java nicht! Das ist unmöglich da die sprache meines wissens keine templates und kein inline anbietet (bei inline bin ich mir jetzt gar nicht so sicher aber verbessert mich falls es doch möglich ist). Du schaffst es nicht so einen code zu schreiben das geht nunmal nur in c++. aber wenn du kein asm kennst kannst du dir das auch nicht vorstellen. Es hat mich auch sehr verblüfft das es möglich ist so besseren code zu erreichen als bei der verwendung von asm... aber es ist nunmal so. Aber ich sag ja nicht java ist scheiße es ist halt nur für andere bereiche gedacht...
-
Manuelh87 schrieb:
Sag mal hast du verstanden was ich dir da geschrieben hab?? Kannst du in java mit inline und templates arbeiten?? Ich glaube nicht und daher geht das nicht.
Null Ahnung. Natürlich kann derJIT-Compiler inlinen, man muss deshalb nicht jeden Funktionsaufruf von Hand ausschreiben. Vielleicht solltest du dir mal bewusst machen, dass ein JIT-Compiler genau das auch kann, was ein statischer Compiler kann und sogar noch ein bisschen mehr, weil er zur Laufzeit Informationen kriegt, die ein statischer Compiler nicht kriegt.
Das einzige Problem, dass der JITer hat, ist, dass er sich nicht ewig Zeit lassen kann zum Compilieren. Er hat aber eh schon enormen Zeitgewinn dadurch, dass er den Code nicht mehr parsen muss, sondern nur noch optimieren.Ich hab schon codes gesehen wo mithilfe von templates und inline der compiler von c++ dazu gebracht wurde code zu erstellen der !besser! ist als die gleiche funktion in asm. Jetzt werden einige aufheulen und sagen das es das nicht gibt... tja doch da der compiler hier so optimiert hat das er alles zusammengefast hat und am ende inlined und es dann nurmehr sachen wie add register,value1 add register value2 usw. sind. Das kann man mit einer asm funktion so malnicht realisieren (es sei denn mann schreibt hier in dem beispiel jede vektoraddition von hand und keine funktion dafür...)
Du scheinst ja von inlining ziemlich begeistert zu sein. Das muss dich unglaublich vom Hocker hauen. Find ich gut, inlining ist manchmal ne feine Sache. Woher du allerdings die Erkenntnis nimmst, dass das nur ein C++-Compiler kann, ist mir ein Rätsel.
Und was ist bitte an Templates so toll? Was ist denn daran so wahnsinnig unmöglich? Es gibt gar nichts einfacheres als Templates. Das ist einfach nur ein unglaublich primitiver Makro-Prozessor. Es gibt gar nichts primitiveres als Textersetzungen. Wenn man die Generics gerade nicht brauchen kann, dann erstellt man sich halt notfalls über ein entsprechendes Plugin in seiner IDE Templates. Schön ist es nicht, weil es dafür keinen direkten Support auf Sprachebene gibt und man eben ein Tool braucht, was die Textersetzungen vornimmt. Aber "unmöglich" ist schon eine starke Bezeichnung dafür.