Unterschiede C++/C#



  • Annakin schrieb:

    Halte ich für ein Vermutung deinerseits die du nicht beweisen kannst.

    Ein lange nicht mehr gebrachter Link:

    Evaluating Java for Game Development
    Das ist zwar kein Beweis, aber zumindest sind in der Arbeit einige Benchmarks enthalten, die meine Aussage doch stark untermauern. Lies dir mal Abschnitt 7.10 durch. Da wird zumindest kein großer Unterschied bei der Nutzung von OpenGL durch Java und C++ festgestellt.



  • Annakin schrieb:

    Das oft gebrachte Argument das interpretierter Code sich während der Laufzeit auf den Prozessor optimiert und damit evtl. sogar schneller als C++ ist, konnte bislang auch noch keiner beweisen.

    Das Argument halte ich bisher auch für relativ schwach. Man wird sehen, ob sich da in Zukunft etwas ändert. Dieses Argument hat aber gar nichts mit der 3D-Performance zu tun. Dafür wird kein Javacode genutzt. Man nutzt entsprechende Funktionen von OpenGL.



  • Annakin schrieb:

    Die Programmierung in Java ist einfacher als mit C++.

    Begründung?



  • Annakin schrieb:

    Das ein Java-Spiel den Vergleich mit Doom3 nicht standhalten kann war mir klar.
    Die Programmierung in Java ist einfacher als mit C++.
    Warum nutzen die Spiele-Entwickler Java nicht wenn keine Unterschiede vorhanden sind?

    Das hat viele Gründe.

    1. Ich glaube, ich habe das Playstation-Argument schon gebracht. Dies wird in vielen Fällen der Hauptgrund sein.
    2. Wenn schon viel Code in C++ vorhanden ist, fällt ein Umstieg auf Java natürlich schwer.
    3. Java ist noch nicht allzulange so schnell, wie es jetzt ist. In den ersten Jahren wurde Java zum Beispiel komplett interpretiert. Es gab da keinen Jitter. Java hat in den letzten Jahre allerdings stark aufgeholt und ist nun in viele Bereichen (nicht in allen) mit der Geschwindigkeit nativer Programme gleichauf. Allerdings haftet Java weiterhin das langsam-Image an, was i.A. nicht gerechtfertigt ist. Es ist auch oft eine unbegründete Angst vor dem GC vorhanden.
    4. usw.

    Aber guck mal in die Zukunft:

    Langsam kommen Mehrkernprozessoren. Hierzu muss man wissen, dass Multithreading bei der Spieleentwicklung bisher nicht allzu präsent ist. Wenn man in Zukunft allerdings die ganze Leistung eines Prozessors nutzen möchte, wird man daran nicht vorbeikommen. Da macht sich eine Sprache wie C++, die Multithreading selbst nicht unterstützt natürlich nicht mehr so gut. Sprachen wie C# oder Java bekommen hier einen Vorteil, der sie für die Spieleprogrammierung (und auch in anderen Bereichen) attraktiver machen wird.



  • Glaube ich nicht, da C++ binärer Code ist, während Java interpretierter Code ist.

    Mit Java Grafikprogramme schreiben .. ne nie im Leben, immerhin benutzt das einen JIT-Compiler. Völlig unmöglich mit einem
    JIT-Compiler Grafikprogramme halbwegs benutzbar zu machen, sagt einem doch schon der Hausverstand. Mehr Argumente
    braucht man auch schon nicht mehr gegen Java, den wer weitere sucht hat noch immer nicht verstanden, dass man in C++ native
    Programme schreibt. Hoffe ihr versteht jetzt warum Java C++ nie das Wasser reichen wird, der JIT-Compiler ist schuld.



  • Gregor@Home schrieb:

    Java ist noch nicht allzulange so schnell, wie es jetzt ist. In den ersten Jahren wurde Java zum Beispiel komplett interpretiert. Es gab da keinen Jitter. Java hat in den letzten Jahre allerdings stark aufgeholt und ist nun in viele Bereichen (nicht in allen) mit der Geschwindigkeit nativer Programme gleichauf. Allerdings haftet Java weiterhin das langsam-Image an, was i.A. nicht gerechtfertigt ist. Es ist auch oft eine unbegründete Angst vor dem GC vorhanden.

    Aber guck mal in die Zukunft:

    Langsam kommen Mehrkernprozessoren. Hierzu muss man wissen, dass Multithreading bei der Spieleentwicklung bisher nicht allzu präsent ist. Wenn man in Zukunft allerdings die ganze Leistung eines Prozessors nutzen möchte, wird man daran nicht vorbeikommen. Da macht sich eine Sprache wie C++, die Multithreading selbst nicht unterstützt natürlich nicht mehr so gut. Sprachen wie C# oder Java bekommen hier einen Vorteil, der sie für die Spieleprogrammierung (und auch in anderen Bereichen) attraktiver machen wird.

    Meinst du nicht das die C++-Compiler auch auf die neuen Multiprozesseren angespasst werden? Vielleicht löst C# dann auch C++ ab, kann sein.

    Ich bin jedenfalls gespannt wie die Situation in 3-5 Jahren ist.
    Alles andere ist Spekulation.



  • Annakin schrieb:

    Glaube ich nicht, da C++ binärer Code ist, während Java interpretierter Code ist.

    Annakin schrieb:

    Vielleicht löst C# dann auch C++ ab, kann sein.

    Jeder darf sich an dieser Stelle überlegen,
    warum folgender Smiley angebracht ist: 🙄



  • Annakin schrieb:

    Meinst du nicht das die C++-Compiler auch auf die neuen Multiprozesseren angespasst werden?

    Das hat nichts mit den Compilern zu tun, sondern mit der Sprache ansich. C++ stellt keine entsprechenden Sprachmittel zur Verfügung. Das wird sich frühestens mit dem nächsten C++ Standard ändern. Der wird aber noch einige Zeit auf sich warten lassen. Ich tippe fast darauf, dass es den erst geben wird, wenn Prozessoren mit 8 Kernen am Markt sind. Etwas spät.



  • Gregor@Home schrieb:

    Das hat nichts mit den Compilern zu tun, sondern mit der Sprache ansich. C++ stellt keine entsprechenden Sprachmittel zur Verfügung. Das wird sich frühestens mit dem nächsten C++ Standard ändern. Der wird aber noch einige Zeit auf sich warten lassen. Ich tippe fast darauf, dass es den erst geben wird, wenn Prozessoren mit 8 Kernen am Markt sind. Etwas spät.

    Ich gebe zu mit Multiprozessoren kenne ich mich nicht so aus.
    Ich weiß nicht ob es möglich ist einen Compiler auf den Markt zu bringen der mit Fähigkeit/Sprachererweiterung für Multiprozessoren erweitert wird.
    Der entspricht dann zwar nicht der Norm..
    Eventuell ist es auch möglich einen Compiler zur Verfügung zu stellen der ANSI-C kann und Spracherweiterungen für Multithreading hat, so das der Programmierer wählen kann.

    Aber das sind nur Vermutungen. Wie gesagt alles andere ist Spekulation. Evtl. sprechen wir uns in 5Jahren wieder und es gibt ein ganz neue Programmiersprache.



  • Annakin schrieb:

    Ich weiß nicht ob es möglich ist einen Compiler auf den Markt zu bringen der mit Fähigkeit/Sprachererweiterung für Multiprozessoren erweitert wird.
    Der entspricht dann zwar nicht der Norm..

    Das wäre eine Katastrophe für C++, wenn ich das mal so sagen darf.



  • Gregor@Home schrieb:

    Annakin schrieb:

    Ich weiß nicht ob es möglich ist einen Compiler auf den Markt zu bringen der mit Fähigkeit/Sprachererweiterung für Multiprozessoren erweitert wird.
    Der entspricht dann zwar nicht der Norm..

    Das wäre eine Katastrophe für C++, wenn ich das mal so sagen darf.

    Oder einfach ein Lib die Funktionen fürs Multithreading zur Verfügung stellt?

    Ist der Gedanke so abwegig?



  • Annakin schrieb:

    Oder einfach ein Lib die Funktionen fürs Multithreading zur Verfügung stellt?

    Ist der Gedanke so abwegig?

    Nein, ist er nicht. Gibt es ja auch. Boost und so. Allerdings ist das maximal eine Hilflösung mit dem Resultat, dass man in seinem Programm 5 Bibliotheken von anderen nutzt, die alle andere Ansätze diesbezüglich haben. Sowas führt dann natürlich zu Problemen.



  • Aber ist das heute denn anders?
    Der ein benutzt die MFC´s, der andere irgendwelche Linux eigene Libs.
    Wenn Microsoft sagen würde ich erweitere die MFC um Funktionen fürs Multithreading, würde das wahrscheinlich dazu führen das alle die Visual C++ benutzen, was sehr viele sind, die gleiche Lib fürs Multithreading nutzen würden.



  • Nur mal so... Die MFC haben schon Multithreading-Funktionalität und ich glaube nicht, dass sich an denen noch großartig was ändern wird.



  • Walli schrieb:

    Nur mal so... Die MFC haben schon Multithreading-Funktionalität und ich glaube nicht, dass sich an denen noch großartig was ändern wird.

    Ich kenne nicht alle Funktionen der MFC. Wenn die Funtionalität jetzt schon da ist, dann ist letztenendes die Mutlithreading Fähigkeit für C++ gegeben.



  • Die MFC stirbt aus. boost bietet aber mittlerweile recht schöne Klassen dafür, die auch auf verschiedenen Plattformen zum Einsatz kommen können.



  • Die Multicore-CPUs werden den Spielen keinen großen Performance-Zuwachs geben können. Was läuft denn parallel in einem Thread ab bzw. was ist denn prädestiniert dafür? Bisher ist das doch nur die Hintergrundmusik. Alles andere, wie 3D-Grafik, Logic, Player-Controlling usw. läuft in einem Thread ab. Die 3D-Grafik könnte man in einem separaten Thread auslagern, aber da muß man sich wirklich erstmal ein Synchronisationskonzept überlegen. Ich könnte da jetzt keines aus dem Stehgreif herzaubern. Denn immerhin ist die Grafik von der Game-Situation, und somit von den Aktionen des Spielers, der NPCs, Natur usw. abhängig. Das wird sehr schwierig alles in Threads auszulagern.

    Intel hat deshalb mit renomierten Spieleentwicklern gesprochen wegen ihrer Multicore-Strategie. Fazit: keiner der Entwickler würde in nächster Zeit die Multicores unterstützen/ausnutzen können. Die sind froh wenn se Lösungen für die Dualcores hinbekommen. Bzw. mit dem Hyperthreading vom P4 hat man schon mal anfangen können.



  • ein honk schrieb:

    Glaube ich nicht, da C++ binärer Code ist, während Java interpretierter Code ist.

    Mit Java Grafikprogramme schreiben .. ne nie im Leben, immerhin benutzt das einen JIT-Compiler. Völlig unmöglich mit einem
    JIT-Compiler Grafikprogramme halbwegs benutzbar zu machen, sagt einem doch schon der Hausverstand. Mehr Argumente
    braucht man auch schon nicht mehr gegen Java, den wer weitere sucht hat noch immer nicht verstanden, dass man in C++ native
    Programme schreibt. Hoffe ihr versteht jetzt warum Java C++ nie das Wasser reichen wird, der JIT-Compiler ist schuld.

    Hem, was hat der JIT mit grafik zu tun? Einfach sagen das JIT und Grafik nicht zusammen passen, kann ja jeder. Ich programmiere auf Arbeit viel mit Grafik wo auch der Benutzer mit dieser interagieren kann. Alles kein Problem.



  • ein honk schrieb:

    Hem, was hat der JIT mit grafik zu tun? Einfach sagen das JIT und Grafik nicht zusammen passen, kann ja jeder. Ich programmiere auf Arbeit viel mit Grafik wo auch der Benutzer mit dieser interagieren kann. Alles kein Problem.

    Und ich dachte, ich spar mir die [ironie] Tags ..



  • Annakin schrieb:

    Ich kenne nicht alle Funktionen der MFC. Wenn die Funtionalität jetzt schon da ist, dann ist letztenendes die Mutlithreading Fähigkeit für C++ gegeben.

    irgendeine beknackte windows-lib ist dafür sicher kein maßstab.
    aber wie schon gesagt gibt es ja boost...


Anmelden zum Antworten