Merkwürdiger Source Code? Kann mir das jemand erklären?

[mandoki]

Hallo,
der Titel ist leider nicht sehr aussagekräftig aber ich weiß nicht so recht wie ich das sonst benennen sollte... sorry dafür.

Zu meinem Problem:
Beim testen der Absolute Database Komponente ist mir ein Sourcecode aufgefallen der mich total verwirrt. Es geht hierbei um das Import/Export Tool welches auch im Source-Code beiliegt.

Hier mal einige kurze Ausschnitte (... steht für weiteren Code):

Delphi-Quellcode:

...
function HasVChk(Table: TTable; Field: TField; var VChk: TVChk): boolean;

function ValToStr(VCHK: DBIVCHK; FldType: word): string;
var
  L: longint;
  I: Integer;
  D: Double;
  MyDate: BDE.DBIDATE;
  ...
  ...

und:

Delphi-Quellcode:

...
procedure TImportExportForm.PerformImport;
var
  i, tableCount: Integer;
  tables: TListBox;
  tableName: String;
  PromptOverwrite: Boolean;
  mr: TModalResult;
  Log: String;

procedure AddDefaultMinMaxFieldValues;
var
  VChk: TVChk;
  i: Integer;
  DoRestructureTable: Boolean;
  s: String;
begin
  ABSTable.Open;
  ABSTable.Close;
  ...
  ...

  ...
       Log := Log+s;
     end;
end;

begin
  PromptOverwrite := True;
  IsStopped := False;
  AbsDB.Close;
  ...

  ...
    end;
  end;
end;

var
  Props: CURProps;
  V: VCHKDesc;
  hCur: hDBICur;
  ...

Der Compiler meldet keinen Fehler.
Ist dies einfach nur eine ungewöhnliche (aber erlaubte) Syntax?

(Habe das komplette File für interessierte mal drangehangen...)

[3_of_8]

Das ist weder ungewöhnlich noch merkwürdig. Das ist einfach eine Nested Function, also eine Funktion innerhalb einer anderen Funktion.

[mandoki]

ähm.. ok.. wäre dann das untere beispiel sowas wie nested procedures? :roll:

[Reinhard Kern]

Zitat:

Zitat von mandoki

Hallo,
der Titel ist leider nicht sehr aussagekräftig aber ich weiß nicht so recht wie ich das sonst benennen sollte... sorry dafür.

Zu meinem Problem:
Beim testen der Absolute Database Komponente ist mir ein Sourcecode aufgefallen der mich total verwirrt. Es geht hierbei um das Import/Export Tool welches auch im Source-Code beiliegt.

Hier mal einige kurze Ausschnitte (... steht für weiteren Code):

Delphi-Quellcode:

...
function HasVChk(Table: TTable; Field: TField; var VChk: TVChk): boolean;

function ValToStr(VCHK: DBIVCHK; FldType: word): string;
var
  L: longint;
  I: Integer;
  D: Double;
  MyDate: BDE.DBIDATE;
  ...
  ...

und:

Der Compiler meldet keinen Fehler.
Ist dies einfach nur eine ungewöhnliche (aber erlaubte) Syntax?

(Habe das komplette File für interessierte mal drangehangen...)

Warum sollte er auch, das sind einfach lokale Prozeduren/Funktionen, d.h. ValToStr gilt wie die Variablen nur innerhalb HasVChk (und stört daher nicht, wenn andere Prozeduren ihr eigenes ValToStr haben).

Muster:

Delphi-Quellcode:

procedure Myprocedure;
var dummy : integer;

  procedure MyLocalProcedure;
  var ldummy : integer;
  begin
  end;

begin
MyLocalProcedure;  { geht nur hier von begin bis end }
end;

Natürlich kann eine lokale Prozedur ihrerseits lokale Unterprozeduren haben. Das ist einer der grössten Vorteile von Pascal gegenüber anderen Sprachen und nimmt vieles der Vorteile von OO-Methoden vorweg. Ich benutze das seit 30 Jahren zur Strukturierung von Programmen, aber leider wird das heute aufgrund unverstandener OO-Ideologie abgelehnt oder ist auch überhaupt nicht mehr bekannt - hier im Forum kommen lokale Prozeduren praktisch nicht vor.

Gruss Reinhard

[mandoki]

Hallo Reinhard,

vielen Dank für deine ausführliche Erklärung.
Das mit den Unterprozeduren war mir bisher nicht bekannt.
Ich glaube ich sollte dahingehend noch mal einiges in der Fachliteratur nachlesen... :oops:

Gruß mandoki ;)

[himitsu]

Zu erwähnen sei, daß selbst die nested procedures/functions selber wiederum welche enthalten können.

Und was vorallem wichtig ist, es wird "immer" die letzte Daklaration verwendet ... ist bei Variablen/Typen/Kontanten... genauso.

Delphi-Quellcode:

procedure MyProcedure1;
  begin
    s := IntToStr(123);  // ruft IntToStr aus der Unit SysUtils auf
  end;

function IntToStr(i: integer): integer; // >>IntToStr[1]
  begin
    ...
  end;

procedure MyProcedure2;
  begin
    s := IntToStr(123);   // ruft die IntToStr[1]
  end;

procedure MyProcedure3;
  function IntToStr(i: integer): integer; // >>IntToStr[2]
    begin
      s := IntToStr(123);  // ruft sich selber auf, also IntToStr[2]
    end;

  begin
    s := IntToStr(123);            // ruft ebenfalls IntToStr[2] auf
    s := SysUtils.IntToStr(123);   // ruft IntToStr aus der Unit SysUtils auf
  end;

[mandoki]

Danke für das Beispiel, himitsu.

Da mir die Vorteile aber noch nicht so ganz einleuchteten, hab ich mal gesucht und dieses Thema gefunden. :gruebel:

Gruß mandoki

[negaH]

@Reinhard

Zitat:

aber leider wird das heute aufgrund unverstandener OO-Ideologie abgelehnt oder ist auch überhaupt nicht mehr bekannt - hier im Forum kommen lokale Prozeduren praktisch nicht vor.

Das stimmt so nicht ;) Gerade hier im Forum findet man viele Beispiele mit nested Functions, zumindestens meine Beispiele ;)
Denn, ich stimme absolut mit deiner Meinung überein, es ist ein in Vergessenheit und unterschätztes Feature, das durch masochistische OOP'ler dummerweise auch noch schlecht geredet wird (obwohl es ja das beste Beispiel für Strukturierung, Modularisierung und Sichtbarkeiskontrolle in der MP ist).

Musste ich mal loswerden ;)

Gruß Hagen

[himitsu]

*zustimm*

und außerdem ist es verständlicher überall (da wo es verwendet wird) 'ne eigene nested Function zu hinterlegen, als irgendwo tausende (vielleicht noch überladne) funktion zu deponieren, wo dann keiner mehr weiß wozu die eigentlich noch gehörten.

[Phoenix]

Just my 2 Cents: Ich verwende sowas immer nur sehr Sparsam, bzw. nur an den Stellen, an denen ich mir ziemlich sicher bin, dass ich die Funktion nicht später irgendwo anders doch noch gebrauchen könnte. Denn dann ist meistens Code-Umbauen angesagt und wo im Code umgebaut wird können sich leicht Fehler einschleichen.