Hallo,
bis jetzt kann ich nur gescheit in Java programmieren, möchte aber gern auch c++ lernen, weil die ja bekanntlich die leistungsfähigste sein soll.
Jetzt wärs ja blöd, wenn ich mich in c++ wieder von gaanz vorne durchquäl, da ich die OOP schon in nem üblen Kurs in der Uni gelernt hab, und mit leichten Kenntnissen HTML Caml Pascal Basic mich nichtmehr so blöd im verstehen von Quelltexten anstell. (Ich kenn sogar den Unterschied zwischen Syntax und Semantik)
Jetzt hab ich mir folgendes überlegt:
Ich hab ja schon einiges an Programmen in Java geschrieben, wenn ich die in C++ konvertiere, dann werd ich doch recht schnell sehen, wie da der Hase läuft.
Ich denk mal, die GUIs werden problematischer, aber die GUI Klassen sind ja eh nr der kleinste Teil eines Programms.
Außerdem hab ich dann noch den angenehmen Nebeneffekt, dass ich aus meinen Programmen Maschinencode machen kann. (als ich hier gefragt hab, wie man aus Java Dateien plattformspezifischen Maschienencode kriegt, wurde ich nur dumm beschimpft)
Würde das gehen, also nicht das mit dem Lernen, das werd ich hinkriegen, aber das mit dem Konvertieren, ein Prog also 1:1 von Java nach C++ übersetzten?
(@the mic: Wenn du keine gescheite Antwort weißt, dann lass mich in Ruhe)
Programmieren - alles kontrollieren 4.941 Themen, 20.708 Beiträge
Kann mir nicht vorstellen, wie ein solcher Konverter funktionieren soll. Wenn Du Java halbwegs verstehst, kannst Du auch C-Quellcode lesen. Lediglich die Sache mit den Zeigern ist von Java aus betrachtet schwer nachzuvollziehen.
C ist vielleicht die schnellste der Hochsprachen, ob's die leistungsfähigste ist, kommt wohl auf die Bewertungskriterien an.
Ja, ich habe einen geschrieben! Das Problem, dass es zu lösen galt, ist, dass in Java Software viel sauberer designbar und testbar ist. Das Zielsystem kennt für schnelle Echtzeitanwendungen aber nur C++. (Viele Zielsysteme kennen nur C, das wäre aber ein weiteres Thema).
Im Laufe der Arbeit habe ich gemerkt, dass viel mehr nötig ist als ich erst dachte:
- Parsen des Quelltextes, sauberes Trennen von Schlüsselworten, "Text in Gänsefüßchen" und /*Kommentaren*/ ist ja klar.
- Referenzen in Java sollten erst Zeiger in C++ werden, mit Konvertierung Objekt.fn() zu Objekt->fn(), aber dann hat sich rausgestellt, dass Referenzen in Java eine kleine Referenzklasse werden muss, die den Zeiger auf das Objekt enthält. Der Destruktur kann dann nämlich Speicher freigegen. new wurde auch etwas umgestrickt.
...
Im Laufe der Arbeit habe ich auch gemerkt, dass alles sich durchaus systematisch darstellt, wie beispielsweise die Strategie für Allokieren und Freigeben von Speicher. In einem Echtzeitsystem muss dem Sorgfalt gewidmet werden!
Was kann das Programm:
- Konvertieren Java nach C++ für schnelle Echtzeitarbeit. Nicht Konvertieren beliebiger Java-Programme nach C++ mit grafischer Bedienung und sonstwas. Da sollte man bei Java bleiben.
- Die Klassen LinkedList, ArrayList, String und ähnliches wurden voll in C++ programmiert, da dort Besonderheiten der Speicherverwaltung anders als in Java zu lösen sind.
- Für Arrays gibt es zu jeder Klasse aus Java in C++ eine extra Array-Klasse, die Zeiger, Länge und operator[]. Arrays lassen sich im Speicher verteilen, weil man in schnellen Echtzeitsystemen nicht beliebig große Speicherblöcke zu Unzeiten haben kann. Das geht dann mit mehreren gleichgroßen Speicherblöcken.
- Automatisch erzeugte Java-Quellen aus einem UML-Tool: Rhapsody von I-Logix wurden damit konvertiert, auch die gesamte Laufzeitumgebung im Rhapsody. Das Ziel ist es, in UML mit Java zu arbeiten und auf dem Zielsystem in C++ zu implementieren.
Wie ist der Stand:
Der Konverter kann das alles konvertieren, aber die Idee mit den Referenzklassen wegen der Speicherverwaltung hatte ich erst vorige Woche, zuerst dachte ich, Speicher anlegen und freigeben soll man gar nicht in Echtzeitsystemen, nur eine Spezialimplementierung für die Strings hatte gemacht, und die hat sich dann als verallgemeinerbar erwiesen. Die nächsten beiden Wochen habe ich Urlaub. Die java-Sources des Konverters müssen noch geschönt werden (Kommentiert für Javadoc usw.), im September soll das aber fertig sein. Ich muss bei meinem Arbeitgeber klären, dass das opensource sein darf, ich gehe davon aus, dass das so sein wird.
Kurze Rückantwort wäre schön: hartmut.schorrig@t-online.de. Keine Anlagen! wegen Postfachgröße und Urlaub, nur eine kurze Interessensbekundung mit Absender.
Bis dann, Hartmut.