Quelltext-Parsen von Delphi-Methoden

[urs.liska]

Hallo,

ich habe eine Frage zum Parsen von Delphi-Quelltext. Ich bin an einem Programm, das Delphi-Dateien bearbeitet. --> http://www.delphipraxis.net/internal...970&highlight=
Beim Einlesen von Methoden, die lokale Prozeduren definieren, habe ich das Problem, dass ich nicht weiß, wie ich das Ende der gesamten Methode bestimmen soll.
Ich gehe so vor, dass ich die Methode Zeile für Zeile einlese. Bevor die 'begin'-Zeile kommt, kann eine Methode nicht beendet sein. Danach betrachte ich sie als beendet, wenn entweder ein Keyword für eine neue Methode (function, procedure, constructor, destructor) oder ein Keyword für einen anderen Abschnitt kommt (const, var, type, initialization, finalization, 'end.') oder eine Zeile mit { T...} eine neue Klasse anzeigt. Das ist meine Funktion:

Delphi-Quellcode:

function TPasSorter.lineEndsMethod: boolean;
begin
  if FFirstMethodLine then
  begin
    result := false;
    FFirstMethodLine := false;
    exit;
  end;
  if not FMethodHasBegun then
  begin
    if lineStartsWith(methodStarters)
       then raise Exception.Create('local methods are not yet supported');
    result := false;
    if lineStartsWith('begin')
       then FMethodHasBegun := true;
    exit;
  end;
  result := lineStartsWith(getClassHeaders) or
            lineStartsWith(methodStarters) or
            lineStartsWith(methodEnders);
end;

Wenn aber eine Methode eine lokale Prozedur definiert, also vor dem 'begin' bereits function oder procedure steht, z.B.

Delphi-Quellcode:

function TForm1.Button1Click(Sender: TObject);
  function getSomething(offset: integer): Date;
  begin
    result := now + offset;
  end;

  procedure showSomething(Msg: string);
  var dt: Date;
  begin
    dt := getSomething(i);
    ShowMessage(DateToStr(dt);
  end;
  
var i: integer;
begin
  for i := 0 to 10 do
  ShowSomething(i);
end;

komme ich so nicht weiter.
Ich habe keine Vorstellung, wie ich damit zu Rande kommen soll. Es können ja sowohl 'procedure' und 'function' als auch 'var' auftauchen.

Es wäre klasse, wenn mir jemand einen guten Tipp geben könnte.

MFG
Urs

[Luckie]

Ich würde es anderes machen. Ich würde die begin's zählen und zu jedem begin muß ein end existieren. Dann muß man nur noch die Ebene beachten. Stößt man nach einem function / procedure auf ein weiteres function / procedure ist man eine Ebene tiefer und man fängt mit dem Zählen von vorne an. Richtige Parser bauen dazu einen Binärbaum auf oder so.

Was hast du denn vor?

[urs.liska]

Das ging aber schnell, da hatte ich gar keine Zeit, den anderen Beitrag abzuschicken und meinen eigenen Beitrag zu bearbeiten.
Jetzt ist aber im obersten Beitrag ein Link auf den Thread, in dem ich beschreibe, was ich vorhabe.

Zu Deiner Antwort, Luckie. Das geht nicht so einfach, weil es ja auch andere Konstruktionen gibt, die ein 'end' haben, wie z.B. try..except..end.

Genau genommen möchte ich nur darum herumkommen, einen richtigen Pascal-Parser zu schreiben, der mir genau sagt, in welcher Ebene der Struktur ich bin. Und auch die Frage mit dem Auslassen von Kommentaren sieht mir momentan noch etwas zu undurchsichtig aus...

Grüße
Urs

[Luckie]

So was muß natürlich berücksichtig werden. Eventuell solltest du mal nach Compiler bau ggogeln.

[urs.liska]

:cry:

[Christian Seehase]

Moin Urs,

was Du auch nicht vergessen darfst, sind entsprechende Begriffe innhalb von Stringkonstanten oder Kommentaren.
Die dürfen ja auch nicht mitgezählt werden.

Damit Du nicht durch Sonderfälle vom Hundersten ins Tausendste gerätst (Erfahrungswert ;-)), wäre es vielleicht sinnvoll doch etwas grundlegender an die Sache heranzugehen.

Was auch noch wichtig zu bedenken wäre:
Soll der Sourcecode syntaktisch korrekt sein, oder muss das Programm das auch noch prüfen?

[urs.liska]

Naja, Syntaxprüfung macht Delphi doch schon ganz ordentlich, nicht wahr?
Das muss ich sicher nicht auch noch machen.
Vielleicht sollte ein Programm den Benutzer darauf aufmerksam machen, dass das parsen von fehlerhaftem Code die Quelltext kaputtmachen könnte...

Grüße
urs

[Christian Seehase]

Moin Urs,

ich meinte das etwas anders.
Seit geraumer Zeit arbeite ich immer mal wieder an einen Tool weiter, dass die Übersetzung der C Header nach Delphi erleichtern soll, und um mir das Leben nicht unnötig schwerer zu machen, gehe ich halt davon aus, dass die Header syntaktisch korrekt sind.

[Dezipaitor]

Zitat:

Zitat von Christian Seehase

Moin Urs,

ich meinte das etwas anders.
Seit geraumer Zeit arbeite ich immer mal wieder an einen Tool weiter, dass die Übersetzung der C Header nach Delphi erleichtern soll, und um mir das Leben nicht unnötig schwerer zu machen, gehe ich halt davon aus, dass die Header syntaktisch korrekt sind.

ich glaube soetwas gibt es schon und wird für das JEDI projekt eingesetzt.


und für das aktuelle thema:
ich denke, dass man um den bau eines parsers nicht drumrumkommt.
ich habe einen gebaut, und muss sagen,
dass schon das einlesen einer Klasse sehr aufwendig ist.

deshalb werde ich das selbst anders machen, indem ich einen parser schreibe, der den quelltext mittels einer Baumvorlage einließt.

[Christian Seehase]

Moin Dezipaitor,

Zitat:

Zitat von Dezipaitor

ich glaube soetwas gibt es schon und wird für das JEDI projekt eingesetzt.

Ich denke mal, das kenne ich, und ich hab's auch schon mal ausprobiert... ;-)

[urs.liska]

@Christian Seehase:
Nee, so sehe ich das eigentlich auch. Der Programmierer muss schon selbst sehen, dass sein Quelltext zumindest korrekt ist.
Aber trotzdem wäre es wahrscheinlich korrekt (zumindest, wenn man ein Tool aus der Hand gibt), den Benutzer auf potenzielle Risiken hinzuweisen.

Was ich aber berücksichtigen müsste, ist die Möglichkeit, Sourcecode sehr eigenwillig zu formatieren. Z.B. ist das folgende ja wohl korrekt:

Delphi-Quellcode:

function TForm1.Create(AOwner:
TComponent);var
i, j; integer;{ Kommentar }begin doSomething;end;

.Oder eine Klassendeklaration wie:

Delphi-Quellcode:

TExStringList { = Meine tolle neue Klasse } = 
class(TStringList) private 
FEigenschaft: string; public property
    Eigenschaft: string
        read FEigenschaft
        write FEigenschaft; end;

Man würde zwar jedem, der so schreibt sagen, er soll erstmal selbst Hand anlegen, aber trotzedm: es ist korrekt, also sollte auch ein Tool nicht daran scheitern...

Aber, wenn es denn schon ein (teilweiser) Delphi-Parser sein muss: dazu müsste es doch Ansätze geben und Material, das verwendbar ist (Algorithmen oder sogar Klassen). Ich habe beim Googlen aber erstmal nichts gefunden...:neutral:

[Christian Seehase]

Moin Urs,

einige Stichworte die mir dazu einfallen:

• Lexikalische Analyse
• Syntaktische Analyse
• (Determinierender) Endlicher Automat

Ich denke mal, dass Du mit diesen Stichworten den Kern des Parsers abdecken können solltest.

[Dezipaitor]

Zitat:

Zitat von urs.liska

@Christian Seehase:
Nee, so sehe ich das eigentlich auch. Der Programmierer muss schon selbst sehen, dass sein Quelltext zumindest korrekt ist.
Aber trotzdem wäre es wahrscheinlich korrekt (zumindest, wenn man ein Tool aus der Hand gibt), den Benutzer auf potenzielle Risiken hinzuweisen.

Nope, wenn ein Fehler im Quelltext drin ist, dann sollte das Tool sowas erkennen und zumindest eine Warnung geben - es kann ja trotzdem weitermachen.

Zitat:

Zitat von urs.liska

Was ich aber berücksichtigen müsste, ist die Möglichkeit, Sourcecode sehr eigenwillig zu formatieren. Z.B. ist das folgende ja wohl korrekt:

Delphi-Quellcode:

function TForm1.Create(AOwner:
TComponent);var
i, j; integer;{ Kommentar }begin doSomething;end;

.Oder eine Klassendeklaration wie:

Delphi-Quellcode:

TExStringList { = Meine tolle neue Klasse } = 
class(TStringList) private 
FEigenschaft: string; public property
    Eigenschaft: string
        read FEigenschaft
        write FEigenschaft; end;

Man würde zwar jedem, der so schreibt sagen, er soll erstmal selbst Hand anlegen, aber trotzedm: es ist korrekt, also sollte auch ein Tool nicht daran scheitern...

Ich denke die Formatierung ist relativ einfach zu handhaben, es sind ja nur Leerzeichen und Zeilenumbrüche.
Viel schwieriger wird es sein, die vielen Möglichkeiten der Sprache Pascal/Delphi reinzubringen, weil jeder gerne auf seinen eigenwilligen Syntax besteht (ich meine damit speziellen Syntax wie default usw).
schau dir das mal an:

Delphi-Quellcode:

  PVariantManager = ^TVariantManager; 
  {$EXTERNALSYM PVariantManager}
  TVariantManager = record
    VarClear: procedure(var V : Variant);
    VarCopy: procedure(var Dest: Variant; const Source: Variant);
...

sowas schonmal gesehen?

oder

Delphi-Quellcode:

type
  IStringsDisp = dispinterface
    ['{EE05DFE2-5549-11D0-9EA9-0020AF3D82DA}']
    property ControlDefault[Index: Integer]: OleVariant dispid 0; default;
    function Count: Integer; dispid 1;
    property Item[Index: Integer]: OleVariant dispid 2;
    procedure Remove(Index: Integer); dispid 3;
    procedure Clear; dispid 4;
    function Add(Item: OleVariant): Integer; dispid 5;

    function _NewEnum: IUnknown; dispid -4;
  end;

und..

 type
  IAncestor = interface
  end;
  IDescendant = interface(IAncestor)
    procedure P1;
  end;
  TSomething = class(TInterfacedObject, IDescendant)
    procedure P1;
    procedure P2;
  end;
  ...

sowas schon benutzt?

TVarData = packed record
    case Integer of
      0: (VType: TVarType;
          case Integer of
            0: (Reserved1: Word;
                case Integer of
                  0: (Reserved2, Reserved3: Word;
                      case Integer of
                        varSmallInt: (VSmallInt: SmallInt);
                        varInteger:  (VInteger: Integer);
                        varSingle:   (VSingle: Single);
                        varDouble:   (VDouble: Double);
                        varCurrency: (VCurrency: Currency);
                        varDate:     (VDate: TDateTime);
                        varOleStr:   (VOleStr: PWideChar);
                        varDispatch: (VDispatch: Pointer);
                        varError:    (VError: HRESULT);
                        varBoolean:  (VBoolean: WordBool);
                        varUnknown:  (VUnknown: Pointer);
                        varShortInt: (VShortInt: ShortInt);
                        varByte:     (VByte: Byte);
                        varWord:     (VWord: Word);
                        varLongWord: (VLongWord: LongWord);
                        varInt64:    (VInt64: Int64);
                        varString:   (VString: Pointer);
                        varAny:      (VAny: Pointer);
                        varArray:    (VArray: PVarArray);
                        varByRef:    (VPointer: Pointer);
                     );
                  1: (VLongs: array[0..2] of LongInt);
               );
            2: (VWords: array [0..6] of Word);
            3: (VBytes: array [0..13] of Byte);
          );
      1: (RawData: array [0..3] of LongInt);
  end;

Zitat:

Zitat von urs.liska

Aber, wenn es denn schon ein (teilweiser) Delphi-Parser sein muss: dazu müsste es doch Ansätze geben und Material, das verwendbar ist (Algorithmen oder sogar Klassen). Ich habe beim Googlen aber erstmal nichts gefunden...:neutral:

ja gibt es :
hier ein Link:

The purpose of PasDoc is to document Object Pascal / Delphi source code from comments within the source code. :
http://pasdoc.sourceforge.net/phpwiki/

suche nach PasDoc und es gibt noch mehr!
außerdem suche vermehrt, nach Programmen die Quelltexte scannen und daraus Hilfedateien machen - d.h. die Kommentare zu den Funktionen und so in eine Hilfe schreiben.