Delphi-PRAXiS
Seite 1 von 2  1 2      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Algorithmen, Datenstrukturen und Klassendesign (https://www.delphipraxis.net/78-algorithmen-datenstrukturen-und-klassendesign/)
-   -   Delphi Die Property Falle... (https://www.delphipraxis.net/182887-die-property-falle.html)

Mavarik 24. Nov 2014 10:52


Die Property Falle...
 
Hallo Zusammen!

Titel war:"Anonyme Proceduren mit und ohne Parameter Spass!"

Gegeben ist ein kleines Interface:
Delphi-Quellcode:
  TMyProc = TProc;
  TMyProc2 = TProc<byte>;

  IFOO = Interface
    ['{7DE4C519-DC13-438A-8FA9-F9A6C10EE9BB}']
    Procedure SetOne(AValue:TMyProc);
    Function GetOne:TMyProc;
    Procedure SetTwo(AValue:TMyProc2);
    Function GetTwo:TMyProc2;
    Procedure SetProgs(A : TMyProc;B:TMyProc2);
    Property One : TMyProc read GetOne write SetOne;
    Property Two : TMyProc2 read GetTwo write SetTwo;
  End;
Das Ganze wird initialisiert mit:
Delphi-Quellcode:
var
  Foo : IFoo;
begin
  Foo := TFoo.Create;

  Foo.SetProgs(Procedure
                 begin
                   Memo1.Lines.Add('Check OK One');
                 end,
               Procedure (B:byte)
                 begin
                   Memo1.Lines.Add('Check OK Two');
                 end);
  GFoo := Foo; // Simuliert eine TList
end;
GFoo ist eine globale Interfacevariable die im "eigentlichen" Programm aus einer TList<IFoo> besteht.

Jetzt wird es lustig. Wir machen mal 4 unterschiedliche Aufrufe:

Delphi-Quellcode:
GFoo.Two(43);
GFoo.Two;
GFoo.One;
GFoo.One();
Alle 4 Aufrufe lassen sich compilieren... Was auch logisch ist.
Kleines Ratespiel? Welcher Aufruf funktioniert und welcher nicht?

Logisch GFoo.Two(43) und GFoo.One() <- besonders geil
und warum GFoo.Two und GFoo.One nicht? Besonders da GFoo.One ja keinen Parameter hat!

...

Na weil GFoo.Two und GFoo.One eigentlich GFoo.GetOne und GFoo.GetTwo ist und somit nur ein
Funktionsaufruf ist, bei dem das Ergebniss "verpufft" {$X+}

Wie schnell kann man hier in diese Falle geraten! Ich habe 3h gesucht..

Grüsse Mavarik

Der schöne Günther 24. Nov 2014 11:04

AW: Anonyme Proceduren mit und ohne Parameter Spass!
 
Ich mache zwar immer viele dumme Fehler, aber darüber bin ich lustigerweise noch nie gestolpert. Wahrscheinlich weil ich, Java-geschädigt, nie Properties verwende. Mit Gettern (siehe Code unten) fällt einem das irgendwie leichter auf.

Hier einmal die Kurzfassung, ohne Interfaces, Properties und Listen:

Delphi-Quellcode:
program Project10;

{$APPTYPE CONSOLE}
{$R *.res}

uses System.SysUtils;

type TProcContainer = class
   strict protected var proc: TProc;
   public
      constructor Create(const proc: TProc);
      function getProc(): TProc;
end;

constructor TProcContainer.Create(const proc: TProc);
begin
   inherited Create();
   self.proc := proc;
end;

function TProcContainer.getProc(): TProc;
begin
   Result := proc;
end;

var
   myContainer: TProcContainer;
begin
   myContainer := TProcContainer.Create(
      procedure
      begin
         WriteLn('Hallo Welt');
      end
   );

   myContainer.getProc(); // Tut nichts
   myContainer.getProc()();
end.

Die Zeile
Delphi-Quellcode:
myContainer.getProc()();
sieht schon schräg aus, aber, wie du ja auch sagst, so ist es richtig :-)

Mavarik 24. Nov 2014 11:11

AW: Anonyme Proceduren mit und ohne Parameter Spass!
 
Zitat:

Zitat von Der schöne Günther (Beitrag 1280893)
Hier einmal die Kurzfassung, ohne Interfaces, Properties und Listen:
Die Zeile
Delphi-Quellcode:
myContainer.getProc()();
sieht schon schräg aus, aber, wie du ja auch sagst, so ist es richtig :-)

Ok, Dein Beispiel ist noch besser...

Ich hatte halt ein Testprogramm programmiert, welches die Bedingungen meines KNX-Interfaces so gut wie möglich nachstellen sollte.
Daher der Ansatz über das Interface.

Ehrlich gesagt bin ich erst darauf gekommen, als ich hier das Posting geschrieben habe... Die 1. Version "sollte" das noch als Fehler herausstellen.

Mavarik

Der schöne Günther 24. Nov 2014 11:24

AW: Anonyme Proceduren mit und ohne Parameter Spass!
 
Zitat:

Zitat von Mavarik (Beitrag 1280895)
Ehrlich gesagt bin ich erst darauf gekommen, als ich hier das Posting geschrieben habe... Die 1. Version "sollte" das noch als Fehler herausstellen

Das passiert mir auch sooo oft. :-D
Fange hier an zu tippen und merke dann ...
Wenn man das Problem nochmal isoliert betrachtet und es für andere formulieren will findet man meist den Fehler. 8-)

Mavarik 24. Nov 2014 11:37

AW: Anonyme Proceduren mit und ohne Parameter Spass!
 
Zitat:

Zitat von Der schöne Günther (Beitrag 1280896)
Wenn man das Problem nochmal isoliert betrachtet und es für andere formulieren will findet man meist den Fehler. 8-)

Klar... Manchmal ruf ich meinen Kollegen oder er mich und beim Erklären hat sich das Problem in 8/10 Fällen schon erledigt..
Oder es war gestern einfach zu spät...

Uwe Raabe 24. Nov 2014 11:55

AW: Die Property Falle...
 
Interessanterweise wirft der Compiler in den Fällen 2 und 3 einen Fehler aus, wenn du in den Compiler-Optionen die Erweiterte Syntax abschaltest. Alternativ kann man natürlich auch die entsprechenden Code-Bereiche in ein {$X-}..{$X+} klammern. Als Lösung ist das allerdings überhaupt nicht geeignet, da dann wohl der restliche Code kaum noch funktionieren dürfte.

Mavarik 24. Nov 2014 16:38

AW: Die Property Falle...
 
Zitat:

Zitat von Uwe Raabe (Beitrag 1280903)
Interessanterweise wirft der Compiler in den Fällen 2 und 3 einen Fehler aus, wenn du in den Compiler-Optionen die Erweiterte Syntax abschaltest. Alternativ kann man natürlich auch die entsprechenden Code-Bereiche in ein {$X-}..{$X+} klammern. Als Lösung ist das allerdings überhaupt nicht geeignet, da dann wohl der restliche Code kaum noch funktionieren dürfte.

{$X-} wäre sicherlich die bessere Voreinstellung. Aber der der ohne {$X+} arbeitet solle das 1. Byte werfen... oder so..

Ist einfach zu praktisch...

Mavarik

Uwe Raabe 24. Nov 2014 18:40

AW: Die Property Falle...
 
Zitat:

Zitat von Mavarik (Beitrag 1280933)
{$X-} wäre sicherlich die bessere Voreinstellung.

Es hängt einfach noch zuviel anderes dran und die Hilfe empfiehlt auch ausdrücklich, das zu lassen. Ist diese "nicht-erweiterte" Syntax nicht noch aus Turbo Pascal Zeiten?

Aber eine entsprechende Warnung á la "Rückgabewert wird nicht verwendet." wäre doch hilfreich, oder?

Mavarik 25. Nov 2014 08:53

AW: Die Property Falle...
 
Zitat:

Zitat von Uwe Raabe (Beitrag 1280938)
Zitat:

Zitat von Mavarik (Beitrag 1280933)
{$X-} wäre sicherlich die bessere Voreinstellung.

Es hängt einfach noch zuviel anderes dran und die Hilfe empfiehlt auch ausdrücklich, das zu lassen. Ist diese "nicht-erweiterte" Syntax nicht noch aus Turbo Pascal Zeiten?

Aber eine entsprechende Warnung á la "Rückgabewert wird nicht verwendet." wäre doch hilfreich, oder?

Ohh, kann mich gar nicht erinnern mit welcher Version X+ gekommen ist... war das nicht D7 erst?
Ne die Fehlermeldung wäre nur Nervig und man(n) würde wieder 100ter Dummy Variablen einführen um die Fehlermeldung weg zu bekommen.

himitsu 25. Nov 2014 09:45

AW: Die Property Falle...
 
Zitat:

Zitat von Mavarik (Beitrag 1280978)
Ne die Fehlermeldung wäre nur Nervig und man(n) würde wieder 100ter Dummy Variablen einführen um die Fehlermeldung weg zu bekommen.

Jupp, alternativ halt ein weiterer Compilerschalter, um diese Warnungen Hinweise zu aktivieren. (standardmäßig aus)

Gut, mit {$X-} würden weniger Meldungen als "
Delphi-Quellcode:
StringReplace(S, 'a', 'b', []);
funktioniert nicht" kommen, aber wie du schon sagestes, ist es gut und gewollt, daß man Results nicht zwanghaft auswerten muß.


Alle Zeitangaben in WEZ +1. Es ist jetzt 13:56 Uhr.
Seite 1 von 2  1 2      

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz