interpreter und compiler
-
eine dumme Frage, wie verstehe ich unter interpretierte Sprache wie java, und compilierte Sprache wie C++.
ich habe so verstanden, C++ muss kompiliert werden, d.h. es wird durch Compiler Binärcode erzeugt.
Interpretierte Sprache ist wie Script Sprache, es wird nicht kompiliert aber nur interpretiert. Aber was ist damit erzeute xxx.class? es ist doch auch in einer Binärform od. nicht?
-
Ja, das ist auch eine "Art Binärform". Genaugenommen ist es der Maschinencode der virtuellen Maschine, es gibt aber sogar reale Maschinen, die den Bytecode verstehen und ausführen können.
Java-Code (also der Quelltext) wird nicht direkt interpretiert, sondern in der Theorie nach Bytecode compiliert und dieser dann interpretiert. In der Praxis wird die VM auch große Teile des Bytecodes in Maschinencode übersetzen und diesen direkt ausführen, da direktes Interpretieren schon einigermaßen langsam ist.
Da der erste Schritt auf jeden Fall immer ein compilieren nach Bytecode ist, ist es eher fraglich, ob man Java überhaupt als interpretierte Sprache ansehen kann. Aber diese Einordnung ist grundsätzlich schwierig.
-
dann darf ich es so verstehen:
C++ (Quellcode) ->(Compiler)->Machinencode
Java(Quellcode) ->(Compiler)->ByteCode->(VM)->Machinencode
Bei Java existiert noch eine Zwischenschicht, d.h. zwar ByteCode ist systemunabhängig aber der durch VM erzeugt Machinencode muss systemabhängig sein,richtig? d.h. auch VM ist systemabhängig.
-
Sprachen wie Java, die erstmal in eine Art "Pseudo-Code" compilieren, der dann von einer virtuellen Maschine interpretiert wird oder durch einen Jitter zur Laufzeit in nativen Code übersetzt wird, nennt man auch oft "P-Code Language".
-
netrobot schrieb:
Bei Java existiert noch eine Zwischenschicht, d.h. zwar ByteCode ist systemunabhängig aber der durch VM erzeugt Machinencode muss systemabhängig sein,richtig? d.h. auch VM ist systemabhängig.
Yup, so ist es, deshalb gibt's ja auch für jedes OS ne VM zum runterladen. C++ Code ist übrigens nach dem Compilen immer noch "plattformunabhängig" (außer man verwendet OS-abhängige Funktionen, z.B. aus conio.h), erst beim linken wird ne plattformabhängige executable erstellt.
-
C++ Code ist übrigens nach dem Compilen immer noch "plattformunabhängig" (außer man verwendet OS-abhängige Funktionen, z.B. aus conio.h), erst beim linken wird ne plattformabhängige executable erstellt.
C++ Code ist nach dem Compilieren (.obj oder .o unter linux) schon plattformabhängig
-
Du knüpfst das jetzt aber nicht an die andere Dateieindung, oder? Na gut, vllt. hast ja recht und ich hab mich getäuscht.
-
nein, es ist nicht mit Dateien zu tun, bei Deklarationen od Definitionen von Funktionen und variablen sind die Adressen schon festgelegt,d.h. es bekommt auf jeden Fall schon den ersten Kontakt mit dem System. (Bei 16 Bit Prozessor hat ein integer 16 bits lang, bei 32bit integer hat 32 bits lang)Diese Informationen sind in der compiliert Form drin.
-
Im .o-File steckt prozessorspezifischer Maschinencode. Kannst ja mal versuchen, ein .o-File vom PC auf nem Mac zu linken und auszuführen ...
-
d.h. .o datei ist wohl systemabhängig, richtig?
-
Gut gut, ihr habt mich überzeugt, wieder mal ein Irrtum ausgeräumt.
-
man lernt immer was dazu. BTW conio.h ist zuerst compilerabhängig, das bin ich ziemlich sicher. Ob es noch systemabhängig ist, weiss ich nicht genau