C++ und C#
-
Professionelle Programmierer der Industrie und Forschung verwenden meines Wissens zu ueber 90% C++
Ich weiss nicht ob die MS VC++ verwenden, moeglich, aber fuer etwa 200 Euro kriegst du die Schuelerversion des CodeWarrior-Compilers. Ist sehr umfangreich und enthaelt Versionen fuer Windows und fuer Macintosh.
Die Vorteile von C++ wurden ja alle bereits genanntich empfehle dir C++, weil die meisten APIs dafuer konzipiert sind, das ermoeglicht dir eine groessere Flexibilitaet. Es gilt als nicht einfach zu lernen, aber wenn du dich dahinterklemmst, schaffst du es
MFG
-
kingruedi schrieb:
Da C# (und die anderen dotNet Sprachen) ebenfalls gejittet werden, sollte C# eine ähnliche Performance wie Java haben.
es gibt zwei Möglichkeiten bei C#:
Compilation bei der Installation(empfehlen bei Spielen)
Compilation bei der Ausführung
-
Compilation bei der Installation(empfehlen bei Spielen)
Warum sollte man das tun? Gibt man damit nicht alle Vorteile auf, die eine virtuelle Maschine nunmal bietet? Bist du dir sicher, dass das dann automatisch schneller läuft? Immerhin gibt es auch einige Dinge, die man nur mit einer VM zur Laufzeit optimieren kann. Wie sieht es zum Beispiel mit Inlining bei Laufzeitpolymorphie aus?
...und wie sieht es mit den Sicherheitskonzepten aus? Werden hier noch zu Laufzeit die Bereichsgrenzen von Arrays überprüft etc.? Wenn ja: Warum sollte es dann soviel schneller sein? Wenn nein: Das ist doch eigentlich eine Sache, die man sich wünscht. IMHO gehört soetwas zu den Vorteilen, die typische C#-Programme oder Java-Programme mit sich bringen.
-
Gregor schrieb:
Compilation bei der Installation(empfehlen bei Spielen)
Warum sollte man das tun? Gibt man damit nicht alle Vorteile auf, die eine virtuelle Maschine nunmal bietet? Bist du dir sicher, dass das dann automatisch schneller läuft? Immerhin gibt es auch einige Dinge, die man nur mit einer VM zur Laufzeit optimieren kann. Wie sieht es zum Beispiel mit Inlining bei Laufzeitpolymorphie aus?
du verstehst .net nicht
der C# Compiler wandelt den C# Source in .il um
Die VM von .net wandelt diesen Code beider Ausführung in Mascheienen code um
es wird also nie interpretiert, wie bei Java
-
hö?
Ich dachte der dotNET Code wird nicht während der Ausführung in Maschinencode umgewandelt, dass wär ja interpretieren des Bytecodes. Ich dachte der Code wird vor der Ausführung compiliert ("gejittet")
Java wird nicht interpretiert, sondern auch gejittet
-
Hauptmann schrieb:
du verstehst .net nicht
der C# Compiler wandelt den C# Source in .il um
Die VM von .net wandelt diesen Code beider Ausführung in Mascheienen code um
es wird also nie interpretiert, wie bei JavaIch glaube, wir haben ein kleines Kommunikationsproblem. Es ging hierbei doch um Performance. Kannst du dann nochmal den Unterschied zwischen den beiden Möglichkeiten erläutern, die du genannt hast? Beziehst du das nur auf die Zeit, die eine Applikation zum Starten benötigt?
-
also
Wenn man mit einem .net Compiler(etwa dem C# Compiler) etwas compiliert, kommt eine *.exe raus
diese exe liegt aber eigentlich nicht im eigentlichen exe format vor, sondern im MSIL Format
MSIL ist eine Zwischensprache die an Assembler erinnert
Bei der Ausführung wird dieser IL Code der Anwendung compiliert, nicht interprtiert
Also hat man, wenn die Anwendung läuft, eine richtige *.exe im RAM, was ja bei JAva nicht der Fall ist, hier wird ja die class Datei interpretiert und nicht compiliert
-
Hauptmann schrieb:
Also hat man, wenn die Anwendung läuft, eine richtige *.exe im RAM, was ja bei JAva nicht der Fall ist, hier wird ja die class Datei interpretiert und nicht compiliert
Etwa 99% (nach meiner Erfahrung) des Java-Bytecodes werden auch zur Laufzeit in Maschinencode kompiliert. Du solltest vielleicht mal dein Java-Wissen aktualisieren. Es ist wohl mindestens 5 Jahre her, dass der Bytecode einfach interpretiert wurde.
Aber ich verstehe immernoch nicht, auf welchen Performanceunterschied du bei deinen beiden genannten "Möglichkeiten" hinauswillst.
-
geb ich gregor recht
das mit java ist schon lange nicht mehr sodie IL ist sowas wie assembler?? - kenn mich da jetzt nicht so aus
, aber das klingt unvernünftig
assembler ist ja eine beschreibung von maschinencode und wesentlich grösser als die eigentliche .exe dadurch das man halt lesbare befehle hat
und genau das wird die MSIL wohl nicht sein - lesbaralso ich denke halt das die IL genau so etwas ist wie der binärstandard den java klassenfiles haben
etwas das man interpretieren kann auf jeder plattform sei es nun intel x86
oder das neueste handy (angenommen es gäbe eines auf dem .net läuft) das mit einer völlig anderen architektur daherkommtANNAHME: -- kann mir irgendwer sagen was davon alles stimmt!
das ganze wird halt bei MSIL glaub ich vor dem ersten ausführen auf einer plattform ganz übersetzt und ins file gespeichert während java das ganze in der JVM hält und sobald diese sich beendet muss es wieder neu übersetzt werden
dennoch interpretiert java nicht da es zuerst alles übersetzt und diesen maschinencode dann immer wieder verwendet
-
gomberl schrieb:
m .net läuft) das mit einer völlig anderen architektur daherkommt
ANNAHME: -- kann mir irgendwer sagen was davon alles stimmt!
das ganze wird halt bei MSIL glaub ich vor dem ersten ausführen auf einer plattform ganz übersetzt und ins file gespeichert während java das ganze in der JVM hält und sobald diese sich beendet muss es wieder neu übersetzt werden
dennoch interpretiert java nicht da es zuerst alles übersetzt und diesen maschinencode dann immer wieder verwendetdas ist imho richtig
zumindest das Grundprinzip(oder liege ich da bei Java wieder falsch, glaube es aber kaum)