Bytecode
-
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).
-
SeppJ schrieb:
Eigentlich gibt's nur einen großen Hersteller, der sich nicht an diesen Quasi-Standard hält (ratet mal wer :p ).
Habe ich mir irgendwie schon fast gedacht. Gibts einen plausiblen Grund dafür, warum MS es nicht für nötig hält, sich an jegliche Standards + Quasi-Standards zu halten?
-
Abhängigkeiten schaffen. Kram, der für Windows geschrieben wurde, kann nur möglichst schmerzhaft für andere Plattformen portiert werden damit es möglichst keiner macht.
