Bytecode
-
Hallo zusammen,
in der Uni haben wir jetzt mit Java angefangen und ich beschäftige mich gerade mit virtuellen Maschinen und Bytecode, doch den Vorteil sehe ich nicht so ganz.
Virtuelle Maschinen verdecken ja die Spezifikationen eines Prozessors, sodass Architektur und Betriebssystem erst einmal keine Rolle mehr spielen. Das Tolle an Java ist ja jetzt wohl die Bestriebssystemunabhängigkeit (wie schreibt man dieses Wort :D?).
Dazu wird ein Programm erst in Byte-Code übersetzt, der von jedem System interpretiert werden kannm, sofern ein Byte-Code Interpreter installiert ist.
Aber was soll das ganze dann? Ich kann auch meinen C++ Quelltext nehmen und ihn auf jedem neuen System mit einem neuen Compiler übersetzen und es sollte auch funktionieren.
Ich sehe hier nicht so richtig den Vorteil. Könnt ihr mir ihn zeigen?
Vielen Dank
lg, freakC++
-
Du sparst schon mal die Compilezeit. Wenn du 30 min die 32 bit Version kompilierst, musst du nochmal 30 min kompilieren für die 64 bit Version.
Außerdem ist binärkompatibilität zwischen Programmen viel einfacher. Wenn du ein Programm schreibst und es dafür Plugins geben soll und diese Objekte austauschen, musst du in C++ ewig viel beachten, dass du ein Plugin verwenden kannst, dass mit einem anderen Compiler erstellt wurde. In Java funktioniert das ganz einfach.
-
Der Bytecode ist hübsch klein. Auf Geschwindigkeit kommt es nicht so an.
Stell Dir vor, Java sei für embedded machines wie Waschmaschinen und Toaster entworfen worden. Nur dann paßt alles zusammen.
:xmas2:
-
freakC++ schrieb:
Das Tolle an Java ist ja jetzt wohl die Bestriebssystemunabhängigkeit (wie schreibt man dieses Wort :D?).
Och, Java ist auch eine schön sauber designte Programmiersprache, die auch sehr angenehm beim Entwickeln von Software ist und ne große Standardlib für allen möglichen Kram mitliefert.
-
eine vm, die bytecode interpretiert, ist im Prinzip eine in Software realisierte CPU.
Es wird also hardware (reale CPU) durch software (vm) ersetzt, und wenn hardware durch software ersetzt wird, gewinnt man meistens an Flexibilität, verliert eventuell aber an Performance.
Weitere Vorteile von bytecodes ggü Maschinencode einer hardware-CPU:
i/ der bytecode kann frei definiert werden, d.h. auch so, daß eine bestimmte Hochsprache besonders leicht in den bytecode compiliert werden kann
ii/ Änderungen am bytecode oder Optimierungen an der vm erfordern keine Änderungen an einer Schaltung, sondern nur an einem Programm
iii/ Plattformunabhängigkeit wurde ja schon erwähnt
Eine elegante und performante Alternative (nämlich einen bytecode-Interpreter nicht im Maschinencode, sondern im Nanocode einer mikroprogrammierbaren CPU zu implementieren) ist inzwischen scheinbar ein wenig in Vergessenheit geraten.
-
freakC++ schrieb:
Ich kann auch meinen C++ Quelltext nehmen und ihn auf jedem neuen System mit einem neuen Compiler übersetzen und es sollte auch funktionieren.
Dann bist du aber immer mit den Eigenheiten des jeweiligen Systems konfrontiert. Das ist bei der VM nicht so, da sie das eigentliche System ersetzt. Diese Abstraktion kommt natürlich mit entsprechenden Kosten. Der Bytecode hat den Vorteil, dass er das kompilieren spart und deutlich schneller vom Interpreter oder (wie zB bei Java) vom JIT verarbeitet werden kann.
-
rüdiger schrieb:
Der Bytecode hat den Vorteil, dass er das kompilieren spart
compiliert werden muß nach wie vor - die wenigsten programmieren direkt in bytecode
-
!rr!rr_. schrieb:
rüdiger schrieb:
Der Bytecode hat den Vorteil, dass er das kompilieren spart
compiliert werden muß nach wie vor - die wenigsten programmieren direkt in bytecode
Ich übersetze:
"Ich hab rüdiger's Antwort zwar verstanden, tu aber absichtlich so als ob ich ein Vollidiot wäre, damit ich ein blödes Kommentar anbringen kann."
-
MultiIndexCoder schrieb:
Wenn du ein Programm schreibst und es dafür Plugins geben soll und diese Objekte austauschen, musst du in C++ ewig viel beachten, dass du ein Plugin verwenden kannst, dass mit einem anderen Compiler erstellt wurde.
So 'n Schwachsinn. Das einzige Problem mit Dynamischen Libs, die C++ enthalten, ist das Name Mangling. Und das ist ja wirklich überhaupt kein Problem.
-
314159265358979 schrieb:
MultiIndexCoder schrieb:
Wenn du ein Programm schreibst und es dafür Plugins geben soll und diese Objekte austauschen, musst du in C++ ewig viel beachten, dass du ein Plugin verwenden kannst, dass mit einem anderen Compiler erstellt wurde.
So 'n Schwachsinn. Das einzige Problem mit Dynamischen Libs, die C++ enthalten, ist das Name Mangling. Und das ist ja wirklich überhaupt kein Problem.
Den Schwachsinn kann ich dir zurückgeben.
Was bringen kompatible Namen, wenn die zwei Programmteile ganz unterschiedliche ABIs verwenden?
-
Ich verstehe nicht, worauf du hinauswillst. Ich kann problemlos GCC Libs mit anderen Compilern verwenden, da ich meinen eigenen Name Mangler geschrieben habe.
-
314159265358979 schrieb:
Ich verstehe nicht, worauf du hinauswillst. Ich kann problemlos GCC Libs mit anderen Compilern verwenden, da ich meinen eigenen Name Mangler geschrieben habe.
Auch wenn du nicht alles richtig verstehst, ist dir schon selber aufgefallen, dass es in C++ Sachen gibt die du machen musst. Wenn du jetzt noch in der Lage wärst zwei zusammenhängende Sätze zu lesen, wäre dir aufgefallen, dass ich noch geschrieben hab, dass es in Java einfacher geht, was du somit bestätigt hast. Ich weiß, für einen C++ Profi wie dich sind das keine Probleme und es ist in C++ auch total einfach, weil du ja alles kannst, auch wenn du noch nicht mal das ganze Problem verstehst.
-
hustbaer schrieb:
!rr!rr_. schrieb:
rüdiger schrieb:
Der Bytecode hat den Vorteil, dass er das kompilieren spart
compiliert werden muß nach wie vor - die wenigsten programmieren direkt in bytecode
Ich übersetze:
"Ich hab rüdiger's Antwort zwar verstanden, tu aber absichtlich so als ob ich ein Vollidiot wäre, damit ich ein blödes Kommentar anbringen kann."
"absichtlich" ? wie kommst du darauf ?
-
314159265358979 schrieb:
Ich verstehe nicht, worauf du hinauswillst. Ich kann problemlos GCC Libs mit anderen Compilern verwenden, da ich meinen eigenen Name Mangler geschrieben habe.
Das allein hilft dir nicht. Das Name Mangling is das geringste Problem. Das eigentliche Problem ist die Tatsache dass es kein C++ ABI gibt.
Und selbst mit potentiell kompatiblen Compilern, ja selbst wenn alle Module mit dem selben Compiler gebaut werden, muss man immer noch höllisch aufpassen...
-
Na gut. Aber woran _genau_ scheiterts denn? "C++-ABI" ist mir doch etwas zu unspezifisch.
-
Es scheitert schon, wenn du einfach nur irgendwo einen std::vector über Modulgrenzen übergeben willst...
-
...
Warum?
-
Weil es kein ABI für C++ gibt.
Du musst eben sicherstellen, dass beide Module die fragliche Instanz von std::vector auf Binärebene exakt gleich behandeln. Sogar wenn beide Module mit dem selben Compiler gebaut wurden bedeutet das, dass sie z.B. was gewisse Dinge (range checks, alignment/struct packing, ...) angeht mit exakt den selben Compilerflags kompiliert werden müssen und potentiell mehr (unter Windows muss z.B. die Version der Runtime-Library auch übereinstimmen und die Library darf nicht statisch gelinked werden, da beide Module sonst jeweils eine eigene Instanz des CRT Heap hätten).
Von verschiedenen Compilern wollen wir gar nicht erst reden, das kannst du im Allgemeinen von vornherein abschreiben...Und das alles jetzt nurmal für einen simplen std::vector irgendwo, da reden wir noch lange nicht von Klassen oder gar Vererbung oder Exceptions oder RTTI oder ...
-
Doofe Sache. Wie ist das denn mit dem Itanium ABI? Halten sich da alle Compiler-Hersteller brav dran? Zumindest mein GCC tut's nämlich.
-
314159265358979 schrieb:
Doofe Sache. Wie ist das denn mit dem Itanium ABI? Halten sich da alle Compiler-Hersteller brav dran? Zumindest mein GCC tut's nämlich.
Alle die von sich behaupten, dass sie es tun (und die ich ausprobiert habe), tun es auch richtig. Eigentlich gibt's nur einen großen Hersteller, der sich nicht an diesen Quasi-Standard hält (ratet mal wer :p ). Und dann klappt das auch mit dem Übergeben des Vectors, sofern man die gleiche STL-Implementierung benutzt hat (was man in der Regel auch so macht).
