Java nach C++

Reflections brauch man nicht.

Gregor

Java Profi schrieb:

Reflections brauch man nicht.

Ok, du Java Profi. Dann schreib mal folgende triviale generische Java 5.0er Methode ohne Reflection:

public static <T> T[] arrayTest(T testObject)
{
   return (T[]) Array.newInstance(testObject.getClass(),10);
}

Java Profi schrieb:

Reflections brauch man nicht.

<ironie>Genau! Schleifen braucht man auch nicht. Kann man schön über Rekursion lösen! </ironie>

Die Frage wurde doch vor einiger Zeit haargenau so in de.comp.lang.iso-c++ gepostet. Daher Troll oder Crossposter...

DrZoidberg

Reflection nachbauen ist nicht so schwierig, nur aufwendig, da du jede Methode der Reflection API neu schreiben musst.
Man muss halt für jede Klasse alle nötigen Informationen, die man für Reflections braucht, irgendwo speichern, damit man dann zur Laufzeit drauf zu greifen kann.

Es geht mit Sicherheit. Die Frage ist nur ob es Sinn macht, da man zum Nachbau der kompletten Funktionalität wahrscheinlich einige ineffiziente Verfahren verwenden muss, die die Performance senken. Ausserdem müsste man entweder den Bytecode oder den Quellcode der Java Runtime ebenfalls kompilieren, was eventuell gegen Suns Lizenzbedingungen verstösst.

Ich sehe da keine Vorteile, ausser dass man Reverse Engineering erschwert.

Gregor

DrZoidberg schrieb:

Reflection nachbauen ist nicht so schwierig, nur aufwendig, da du jede Methode der Reflection API neu schreiben musst.
Man muss halt für jede Klasse alle nötigen Informationen, die man für Reflections braucht, irgendwo speichern, damit man dann zur Laufzeit drauf zu greifen kann.

Es geht mit Sicherheit. Die Frage ist nur ob es Sinn macht, da man zum Nachbau der kompletten Funktionalität wahrscheinlich einige ineffiziente Verfahren verwenden muss, die die Performance senken. Ausserdem müsste man entweder den Bytecode oder den Quellcode der Java Runtime ebenfalls kompilieren, was eventuell gegen Suns Lizenzbedingungen verstösst.

Ich sehe da keine Vorteile, ausser dass man Reverse Engineering erschwert.

Schön und gut. Die Lösung, Java nach C++ umzusetzen ist, irgendwelche Eweiterungen zu C++ hinzuzufügen, so dass es am Schluss nicht mehr C++ ist und ein einfaches Kompilieren mit einem C++ Compiler nicht mehr ausreicht (du brauchst zum Beispiel mindestens irgendeine Vorstufe beim Kompilieren, um die Informationen über die Klassen usw. zu erzeugen, die du irgendwo abspeichern möchtest). Mit anderen Worten: Man erzeugt dann keinen C++ Code mehr, sondern baut sich eine neue Sprache, für die man dann Code erhält. Das ist ja auch nicht die einzige Erweiterung, die man braucht. Man muss irgendwelche Bibliotheken zum C++ Standard hinzufügen, die einem die Funktionalität der Java Standardbibliothek (z.B. Threads usw.) zur Verfügung stellen, man benötigt vermutlich einen GC, man benötigt einen Java-Bytecode-To-Native-Code-Compiler und ab Java 6.0 einen Java-Code-To-Native-Code-Compiler usw.! Mit den ganzen Dingen, die man nachbauen muss, wird am Schluss etwas wirklich grausames rauskommen. Etwas, was für keinen Menschen mehr nutzbar ist, was dafür aber extrem komplex ist und einen riesigen Overhead mitbringt.

...und wofür das alles?! Ehrlich gesagt habe ich keine Ahnung, was man sich davon verspricht. Performance vielleicht? Die kriegt man dadurch niemals.

@DrZoidberg: Bezüglich des ReverseEngineerings: Spielst du darauf an, dass Java-Bytecode relativ leicht in Java-Code zurücktransformiert werden kann? Wenn ja: Es gibt Obfuscator und Java-Native-Compiler.

DrZoidberg

Gregor schrieb:

Schön und gut. Die Lösung, Java nach C++ umzusetzen ist, irgendwelche Eweiterungen zu C++ hinzuzufügen, so dass es am Schluss nicht mehr C++ ist und ein einfaches Kompilieren mit einem C++ Compiler nicht mehr ausreicht (du brauchst zum Beispiel mindestens irgendeine Vorstufe beim Kompilieren, um die Informationen über die Klassen usw. zu erzeugen, die du irgendwo abspeichern möchtest). Mit anderen Worten: Man erzeugt dann keinen C++ Code mehr, sondern baut sich eine neue Sprache, für die man dann Code erhält.

Nein. Vom Erstellen einer neuen Sprache habe ich nicht geredet. Das Ergebnis sollte schon standardkonformer C++ Code sein.
Die Informationen über die Klassen erzeugt der Java nach C++ Übersetzer und fügt sie in den C++ Quellcode ein.

Das ist ja auch nicht die einzige Erweiterung, die man braucht. Man muss irgendwelche Bibliotheken zum C++ Standard hinzufügen,

Muss man doch bei fast allen C++ Programmen.
Im Ansi C++ Standard sind schliesslich nicht mal GUI Elemente enthalten.

, man benötigt vermutlich einen GC, man benötigt einen Java-Bytecode-To-Native-Code-Compiler und ab Java 6.0 einen Java-Code-To-Native-Code-Compiler usw.! Mit den ganzen Dingen, die man nachbauen muss, wird am Schluss etwas wirklich grausames rauskommen. Etwas, was für keinen Menschen mehr nutzbar ist, was dafür aber extrem komplex ist und einen riesigen Overhead mitbringt.

schon möglich. Ich muss das glücklicherweise nicht schreiben.

@DrZoidberg: Bezüglich des ReverseEngineerings: Spielst du darauf an, dass Java-Bytecode relativ leicht in Java-Code zurücktransformiert werden kann? Wenn ja: Es gibt Obfuscator und Java-Native-Compiler.

Mit nem Java-Native-Compiler hat man aber wieder ähnliche Probleme, wie mit einem Java-C++ Übersetzer. Aber immerhin muss ich das Teil dann nicht selbst schreiben.

Gregor

DrZoidberg schrieb:

Die Informationen über die Klassen erzeugt der Java nach C++ Übersetzer und fügt sie in den C++ Quellcode ein.

Ich habe so wenig Vorstellungskraft. Zeig mal an einem einfachen Beispiel, wie das aussehen soll.

kann der gjc reflections?

Soll das ne Diplom/Doktorarbeit werden?
Denn genau in diesem Schwierigkeitsbereich wäre das einzuordnen

DrZoidberg

Gregor schrieb:

DrZoidberg schrieb:

Die Informationen über die Klassen erzeugt der Java nach C++ Übersetzer und fügt sie in den C++ Quellcode ein.

Ich habe so wenig Vorstellungskraft. Zeig mal an einem einfachen Beispiel, wie das aussehen soll.

Also erstmal halte ich eine Umsetzung nach C für sinnvoller als nach C++. Da sich Klassen, Templates usw. in C++ sowieso anders verhalten als in Java, muss man es eh selbst implementieren.
Was ich im Sinn habe ist eher ein Java Compiler, der aber anstelle von ASM/Maschinencode C-Code produziert und dadurch den Vorteil hat, dass er leichter zu portieren ist und dass man die meisten Optimierungen, die eines der aufwendigsten Teile eines Compilers sind, nicht selbst schreiben muss.

Man könnte für jede Klasse und jedes Objekt jeweils ein Struct anlegen. Ein Objekt enthält unter anderem einen Zeiger auf ein Class Object, das ebenfalls als Struct gespeichert wird. Das Class Objekt enthält einen Zeiger auf ein Array, das alle Methodennamen enthält.

Gunnar

Soll der Compiler denn nur compilierbaren C++-Code erzeugen, oder C++-Code, der zur Weiterprogrammierung geeignet sein soll?
Willst Du das gesamte Java-Framework (API) neu implementieren, oder weiterhin dagegen linken?

Beutelratte schrieb:

Hi,
ich arbeite momentan an einer Arbeit über die Umsetzung von
Java-Quelltexten
nach C++-Quelltexten.
Mich würde mal interessieren ob und wie ihr dass benutzen würden wenn eine
Umsetzung fehlerfrei und ohne jeden Funktionalitätsverlust funktionieren
würde.

ACDK koennte genau das sein, was Du suchst:

http://acdk.sourceforge.net

Eine Liste der Features:
http://acdk.sourceforge.net/acdk/docs/hb/intro/acdk_about_features.html