C++ zu Java
-
Hallo,
es gibt Tools, die dir aus C++ Code UML Diagramme erstellen, woraus du dann wiederum JAVA Code generieren kannst. Aber in wieweit die Qualität dabei ausreichend ist und besondere Sprachmerkmale berücksichtigt werden (können), weiss ich nicht.
-
Gregor: Die Reflection müsste relativ einfach zu realisieren sein, wenn man eien Codegenerator zur Verfügung hat. Der normale Compiler baut einem das nicht, das ist klar, aber ein Umwandlungstool sollte dazu in der Lage sein.
Was ich als großes Problem ansehen würde, ist, dass C++ keinen GC hat.
-
Bashar schrieb:
Was ich als großes Problem ansehen würde, ist, dass C++ keinen GC hat.
Das Tool kann ja für alle Speicherallokationen einen der verfügbaren C++ Garbage Collectoren benutzen.
-
Ich denke die Frage ist auch welche Qualität man vom übersetzen Code erwartet. Ein einfacher Übersetzer könnte z.B. die Übersetzung so erledigen:
Definiere einen String der das C++-Programm enthält, füge ein (immer gleiches) Java-Programm an, das einen C++-Interpreter implementiert.... natürlich kann man eine Übersetung von Java nach C++ genauso implementieren.
Aber natürlich wird sicher niemand meinen, dass das nun ein toller C++-zu-Java-Übersetzer wäre. Aber als Beispiel, dass es nicht unmöglich ist, kann es durchaus herhalten.
-
Ponto schrieb:
Bashar schrieb:
Was ich als großes Problem ansehen würde, ist, dass C++ keinen GC hat.
Das Tool kann ja für alle Speicherallokationen einen der verfügbaren C++ Garbage Collectoren benutzen.
Stelle nie in Frage, was Bashar sagt. Ich stimme ihm übrigens zu.
-
Gregor schrieb:
interpreter schrieb:
Ich behaupte einfach mal das der Hauptgrund, warum es da nahezu keine Tools gibt ,einfach die Tatsache ist, dass der Sprachumfang von Java kleiner ist als der von C++ und so eine Transformation nicht vollständig funktionieren kann. Von Java nach C++ ist das eher möglich.
Andersrum ist es genauso unmöglich, bzw. genauso aufwändig, weil man unglaublich viel aus Java nachbilden muss. Zum Beispiel Reflection und nen Java-Compiler. Das ist genausowenig trivial.
Ich habe nie bestritten, dass es schwer ist. Ich sagte lediglich, dass es anders herum einfacher ist. Ein Studienkollege schreibt in seiner Diplomarbeit übrigens gerade einen Java->C++ Compiler.
-
Ihr vergesst da was ganz wichtiges: die Bibliotheken
-
SirLant schrieb:
Ihr vergesst da was ganz wichtiges: die Bibliotheken
Wieso?
-
Optimizer schrieb:
Ponto schrieb:
Bashar schrieb:
Was ich als großes Problem ansehen würde, ist, dass C++ keinen GC hat.
Das Tool kann ja für alle Speicherallokationen einen der verfügbaren C++ Garbage Collectoren benutzen.
Stelle nie in Frage, was Bashar sagt. Ich stimme ihm übrigens zu.
Und was kann man mit den C++ Garbage Collectoren nicht machen. Das einzige Problem könnten finalize Methoden sein. Aber auch das ist eigentlich kein großes Problem.
-
Du scheinst nicht so wirklich Ahnung davon zu haben. Finalizer sind vermutlich das geringste Problem. Es ist in C++ nicht so ohne weiteres möglich, mit Sicherheit alle nicht referenzierten Objekte zu erkennen, außer du nimmst strengste Einschränkungen in Kauf wie z.B. dass du forderst, dass alle Klassen von deiner GC-Klasse ableiten ö.a.
Das ist auch nur die Spitze des Eisbergs.
Außerdem glaube ich sowieso nicht, dass Bashar technische Probleme gemeint hat, sondern einfach Probleme, die sich aus der unterschiedlichen Art der Programmierung ergeben, mit und ohne GC, C++ und Java.
-
Optimizer schrieb:
Stelle nie in Frage, was Bashar sagt.
Oh doch, ich bitte darum.
Ich stimme ihm übrigens zu.
Vielleicht muss ich über meine Aussage nochmal nachdenken ;->
-
Optimizer schrieb:
Du scheinst nicht so wirklich Ahnung davon zu haben. Finalizer sind vermutlich das geringste Problem. Es ist in C++ nicht so ohne weiteres möglich, mit Sicherheit alle nicht referenzierten Objekte zu erkennen, außer du nimmst strengste Einschränkungen in Kauf wie z.B. dass du forderst, dass alle Klassen von deiner GC-Klasse ableiten ö.a.
Das ist auch nur die Spitze des Eisbergs.
Außerdem glaube ich sowieso nicht, dass Bashar technische Probleme gemeint hat, sondern einfach Probleme, die sich aus der unterschiedlichen Art der Programmierung ergeben, mit und ohne GC, C++ und Java.Es geht darum, Java automatisch nach C++ zu konvertieren. Da kann man ganz leicht auf Situationen verzichten, die den Garbage Collector durcheinander bringen. Hast du dir mal den Boehm GC angeschaut. http://www.hpl.hp.com/personal/Hans_Boehm/gc/. Da muss auch nicht alles vom GC ableiten.
-
Der entdeckt auch nicht alle unreferenzierten Objekte. Steht sogar im ersten Satz schon drin.
Im übrigen wäre diese Ableitung noch das kleinste Problem. Der GC muss auch bei Funktionsaufrufen wissen, wo im Stack Frame Pointer zu finden sind.
Da ich diese Informationen auch von Bashar hab, zweifelst du sie besser nicht an.Bashar schrieb:
Vielleicht muss ich über meine Aussage nochmal nachdenken ;->
Wird dir nichts nützen, dann werde ich deine neue Aussage auch assimilieren.
-
Ich glaube hier entsteht so langsam eine neue Religion...oder ein Mythos? Oder gar ein Fetisch? Der Basharismus.....mmmh klingt sogar ganz gut. :p
-
CarstenJ schrieb:
Ich glaube hier entsteht so langsam eine neue Religion...oder ein Mythos? Oder gar ein Fetisch? Der Basharismus.....mmmh klingt sogar ganz gut. :p
Götzendienst?
-
Optimizer schrieb:
Der entdeckt auch nicht alle unreferenzierten Objekte. Steht sogar im ersten Satz schon drin.
Im übrigen wäre diese Ableitung noch das kleinste Problem. Der GC muss auch bei Funktionsaufrufen wissen, wo im Stack Frame Pointer zu finden sind.
Da ich diese Informationen auch von Bashar hab, zweifelst du sie besser nicht an.Und wo liegt das Problem genau im Stack?
-
Sag mir halt, wie du im Stack Pointer in den Heap erkennst, ohne irgendeine bestimmte Vorgabe über den Aufbau des Stack Frames zu machen.
Und sag mir bitte bei der Gelegenheit auch gleich noch, wie ein GC erkennt, dass es zwar keinen Zeiger auf dein Objekt gibt, aber du früher mal die Adresse genommen hast, mit 73 multipliziert, mit 0xfe548701 geXORt hast und die Adresse jederzeit wieder herstellen und damit auf das Objekt zugreifen kannst.
-
Optimizer schrieb:
Sag mir halt, wie du im Stack Pointer in den Heap erkennst, ohne irgendeine bestimmte Vorgabe über den Aufbau des Stack Frames zu machen.
Und sag mir bitte bei der Gelegenheit auch gleich noch, wie ein GC erkennt, dass es zwar keinen Zeiger auf dein Objekt gibt, aber du früher mal die Adresse genommen hast, mit 73 multipliziert, mit 0xfe548701 geXORt hast und die Adresse jederzeit wieder herstellen und damit auf das Objekt zugreifen kannst.
Das ist das normale Argument gegen GC in C++. Aber, wer das macht, hat es nicht anders verdient.
Anderseits haben wir hier immer noch den Fall, dass wir Java automatisch nach C++ umwandeln wollen. Da wird das nicht passieren. Der Code, der rauskommt wird ganz harmlos sein, genauso wie Javacode fuer C++ Verhaeltnisse immer harmlos ist.
A mark-sweep garbage collector traverses all reachable objects in the heap by following pointers beginning with the "roots", i.e. pointers stored in statically allocated or stack allocated program variables. All such reachable objects are marked. A sweep over the entire heap is the performed to restore unmarked objects to a free list, so they can be reallocated.
Also wird der wohl auf dem Stack anfangen.
-
Optimizer schrieb:
Sag mir halt, wie du im Stack Pointer in den Heap erkennst, ohne irgendeine bestimmte Vorgabe über den Aufbau des Stack Frames zu machen.
Genauso wie alle anderen Pointer. Ich weiß nicht worauf du hinaus willst, anscheinend weißt du ja, was ein konservativer GC ist. Oder?
Und sag mir bitte bei der Gelegenheit auch gleich noch, wie ein GC erkennt, dass es zwar keinen Zeiger auf dein Objekt gibt, aber du früher mal die Adresse genommen hast, mit 73 multipliziert, mit 0xfe548701 geXORt hast und die Adresse jederzeit wieder herstellen und damit auf das Objekt zugreifen kannst.
Gar nicht. Das ist eine Schwachstelle, die jeder GC hätte. BZW einer der Gründe, warum C++ im gegenwärtigen Zustand auf keinen Fall einen richtigen GC bekommen kann. Dazu müssten solche Aktionen zunächst vom Standard als illegal eingestuft werden.
Allerdings haben wir ja nicht mit beliebigen Programmen, sondern nur mit konvertierten Java-Programmen zu tun. Die werden ganz sicher keine über Array-indizierung hinausgehende Pointerarithmetik machen ...
-
Bashar schrieb:
Genauso wie alle anderen Pointer. Ich weiß nicht worauf du hinaus willst, anscheinend weißt du ja, was ein konservativer GC ist. Oder?
Ja. Darum geht es ja auch eigentlich gerade. In C++ ist es IMHO ein bisschen riskant, einfach zu vermuten, was ein Pointer ist, und was nicht. Entweder ich benutze einen Compiler, der diese Information einarbeitet und habe kein Standard C++ mehr oder ich kriege keinen "korrekten" GC hin, IMHO.
Gerade in Java ist ein GC oft aber auch als letzte Sicherheits-Instanz für andere Resourcen als RAM verantwortlich. Ich denke nicht, dass man mit einem konservativem Collector gut bedient ist.Allerdings haben wir ja nicht mit beliebigen Programmen, sondern nur mit konvertierten Java-Programmen zu tun. Die werden ganz sicher keine über Array-indizierung hinausgehende Pointerarithmetik machen ...
Da hast du nun auch wieder recht. Ich würde dir niemals widersprechen. *anbet* *räucherstäbchen anzünd*