Delphi-Parser und Prettyprinter

[dmey]

Ich bin froh, dass sich Dein anfänglicher Ärger etwas gelegt hat. Aber für mich bzw. für andere Benutzer bleibt die Sache ein Katastrophe.

Zitat:

SharedMemory (die zugehörige DLL wurde mit gelöscht)

Damit meinst Du wahrscheinlich die borlndmm.dll, oder? Ich hab nochmal in meinem Inno-Setup-Script nachgeschaut. Dort sind die Attribute "sharedfile onlyifdoesntexist" gesetzt, d.h, sie wird nur installiert, wenn noch nicht vorhanden und:

Zitat:

Uses Windows' shared file counting feature (located in the registry at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Curr entVersion\SharedDLLs). This enables a file to be shared between applications, without worrying about it being inadvertently removed. Each time the file is installed, the reference count for the file is incremented. When an application using the file is uninstalled, the reference count is decremented. If the count reaches zero, the file is deleted (with the user's confirmation, unless the uninsnosharedfileprompt flag is also specified).

Wenn Du mir helfen könntest, den Grund für die Exception herauszufinden, würde ich Dir eine kostenlose Lizenz des Programms überlassen. Dein momentanes sich in den letzten Zügen befindliches System scheint die ideale Testumgebung zu sein. Auf sauberen VM's hab ich die Installation und den Programmstart schon bis zum Erbrechen getestet.
Am anfälligsten hat sich bisher die Verwaltung des Fensterlayouts gezeigt. Das Layout ist in der Datei "EditDefault_ge.ds" gespeichert und wird bei der Installation ins Settingsverzeichnis kopiert. Evtl. startet der TT fehlerlos, wenn man die datei umbenennt. (Dann sind alle Fenster nebeneinander angeordnet.) Ein weiterer Punkt der mich interessieren würde ist, ob eine Tetra.ini im Settings-Verzeichnis angelegt wurde.

[himitsu]

Zitat:

Zitat von dmey

Damit meinst Du wahrscheinlich die borlndmm.dll, oder?

jupp, und via D7 war sie ja schon vorhanden

Zitat:

Zitat von dmey

Wenn Du mir helfen könntest, den Grund für die Exception herauszufinden,

ich kann ja mal demnächst nachsehn, wenn ich etwas Zeit dafür hab.

das XP läuft ja eh auf einer unwichtigen und ich würd's mal "externen" Platte nennen.
ich kann es also noch eine Weile aufheben und auch später nochmal reingucken :stupid:

[dmey]

Nochmals zu dem Problem mit den Steuerzeichen und Zeigertypen. Als Nicht-Delphianer wundere ich mich dass zwar folgende Typdefinition möglich ist:

Delphi-Quellcode:

Type1 = 1..12;

nicht aber

Delphi-Quellcode:

Type2 = ^A..^F;

Das hab ich nur empirisch getestet. Es geht aus dem wenigen, was es an formalen Grammatiken für Delphi gibt nicht hervor. Ich habe daraus geschlossen, dass Typdefinition keine Steuerzeichen in besagter Schreibart enthalten dürfen und habe das TextTransformer-Projekt entsprechend verbessert.

[DP-Maintenance]

Dieses Thema wurde von "MrSpock" von "Object-Pascal / Delphi-Language" nach "Tools rund um Delphi" verschoben.
Ist eher ein Tool für Delphi.

[alzaimar]

Zitat:

Zitat von dmey

Als Nicht-Delphianer wundere ich mich dass zwar folgende Typdefinition möglich ist:

Delphi-Quellcode:

Type1 = 1..12;

nicht aber

Delphi-Quellcode:

Type2 = ^A..^F;

Das erste ist ein Untertyp für ganze Zahlen, das zweite wäre ein Untertyp für Zeichen. Ersteres ist eben möglich, Letzteres nicht. Is einfach so.

[Sailor]

Wieso soll das nicht gehen?

TYPE
TType1 = 1..12;
TType2 = 'A'..'F';
TType3 = #00..#31;

[dmey]

Wenn man einen Parser entwickelt ist die Fragestellung nicht die, nur die eine oder andere Möglichkeit zu finden, wie ich ein entsprechendes Array definiere, sondern alle zulässigen Möglichkeiten zu erfassen. Und "Type2 = ^A..^F;" ist eben nicht erlaubt. Das hat für die Entwicklung des Parsers den Vorteil, dass, wenn hinter dem Gleichheitszeichen einer Typdefinition ein Caret-Zeichen steht, sofort klar ist, dass es sich um einen Zeiger handeln muss.

In einem anderen Forum hatte mir jemand vorgeschlagen den Parser an der Testsuite von Free-Pascal zu testen. Das hab ich gemacht und der Delphi-Parser konnte dadurch in etlichen speziellen Fällen nochmals verbessert werden.

Die Testsuite und mehr Erläuterungen gibt es hier:

Delphi-Parser mit Testsuite

[dmey]

Aus dem Delphi Parser hab ich jetzt das Programm Delphi2Cpp gebaut, das Delphi Quellcode in C++ Code konvertiert.

Delphi2Cpp : Konverter von Delphi nach C++

Bisher ist die Übersetzung auf den CBuilder zugeschnitten und Delphi-Features, die nach Delphi 4/5 eingeführt wurden können noch nicht geparst werden. Die Konvertierung erspart alle einfachen Ersetzungen und Umstellungen des Codes, die den weitaus größten Teil der Übersetzungsarbeit ausmachen. Außerdem werden eine Reihe weiterer komplexerer Übersetzungsschritte ausgeführt. In den meisten Fällen wird allerdings eine manuelle Nachbearbeitung des erzeugten Codes erforderlich sein.
Die besten Ergebnisse erhält man, wenn in den Optionen die Pfade zur VCL gesetzt werden (das kann auch die aktuellen VCL sein, optimal ist aber die VCL 4/5). Delphi2Cpp wird dann bei der Übersetzung der ersten Dateien relativ langsam, merkt sich aber die Informationen derjenigen Dateien, die bereits einmal geparst wurden, so dass es zunehmend schneller wird.


Mehr Details zu den einzelnen Übersetzungsleistungen sind hier aufgelistet:

Delphi2Cpp Details


Das Programm ist Shareware und 30 Tage kostenlos zu testen. Über Feedback würde ich mich freuen.

[himitsu]

Andersrum (C > Delphi) würde mir besser gefallen :angel2:

[dmey]

So einen Kommentar hatte ich schon erwartet. Hier wendet sich die Qualität von Delphi gegen sich selbst. Die Sprache ist so aufgebaut, dass sie verhältnismäßig leicht und sehr schnell geparst werden kann. Einen Parser für C++ zu schreiben ist ungleich schwerer. Immerhin habe ich das einmal zur Konvertierung einer Firmensoftware von C++ nach Java gemacht. Für eine vorgegebene Menge an C++ Code könnte ich es auch für Delphi machen, aber leider nicht allgemein. :(