Bytecode
-
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.
-
Meinst du echt, die denken so pervers?
-
Die erste MSVC ABI ist älter als der Itanium-Standard, und war damals (und ist es heute noch) "der Windows Standard".
Bzw. bestimmte Teile der ABI wie z.B. das VTable Layout oder Exception Handling.Die sind auch mehr oder weniger in Stein gemeisselt. Eine Änderung am VTable Layout würde bedeuten dass man in C++ nicht mehr "einfach so" COM Interfaces implementieren kann, und eine Änderung am Exception Handling würde bedeuten dass man keine Exceptions mehr "durch OS Code" werfen könnte (z.B. aus einem Callback, durch den OS Code, zum Aufrufer von SendMessage o.ä.).
Daran festzuhalten ist einfach nur praktisch. Bzw. andersrum: es zu ändern wäre reichlich plem, da es weitreichende, unerwünschte Konsequenzen hätte.
-
hustbaer schrieb:
, und eine Änderung am Exception Handling würde bedeuten dass man keine Exceptions mehr "durch OS Code" werfen könnte (z.B. aus einem Callback, durch den OS Code, zum Aufrufer von SendMessage o.ä.).
Sicher, daß man das kann?
-
volkard schrieb:
hustbaer schrieb:
, und eine Änderung am Exception Handling würde bedeuten dass man keine Exceptions mehr "durch OS Code" werfen könnte (z.B. aus einem Callback, durch den OS Code, zum Aufrufer von SendMessage o.ä.).
Sicher, daß man das kann?
Ziemlich sicher.
MSVC's Exception Handling baut auf das vom OS untersetützte "Structured Exception Handling" (SEH) auf.So lange die entsprechenden OS-Funktionen exception-safe geschrieben sind, sehe ich keinen Grund, warum es nicht funktionieren sollte.
Wobei ich dir jetzt keine Quelle nennen kann, wo explizit steht, dass man es darf.
