Aufrufen einer Unterprozedur mit AsyncCalls

[Benmik]

Zitat:

Zitat von Sir Rufo (Beitrag 1337753)

Jetzt klar?

Leider nein...:(
Ich habe mal Folgendes probiert:

Delphi-Quellcode:

procedure TForm1.Haupt;
type 
  TTuWas = reference to function(i:integer):integer;
var TuWas:TTuWas ;
  //-------------------------------------------------------
  procedure RufeAuf;
  begin
    TAsyncCalls.Invoke(
      procedure
      var i:integer;
      begin
        For i := 0 to 10 do
          If i < 11
            then TAsyncCalls.Invoke<integer>(TuWas,i));
    end);
  end;
  //-------------------------------------------------------
begin
  RufeAuf;
end;

Der Compiler meint "Es gibt keine überladene Version usw....")
Abgesehen davon, dass TuWas ja noch fehlt, schreit er jetzt schon. Das ist es ja, wie geht sowas?

[Sir Rufo]

Weil der Typ nicht passt.

Delphi-Quellcode:

var
  TuWas: TAsyncCallArgGenericMethod<Integer>;

[Benmik]

Oh je, wenn mal Uwe nicht Recht behält...
Sir Rufos Vorschlag wird auch nicht gnädig behandelt, da die Deklaration private ist...
Ich hänge die Datei mal an.

[Sir Rufo]

Wenn man keine Rücksicht auf Abwärtskompatibilität legen muss, dann kann man alles in eine normale anonyme Methode packen:

Delphi-Quellcode:

TAnonWrapper = class
  class function Wrap<T>( AProc: TProc<T>; Arg: T ) : TProc;
  class function Wrap<T,TResult>( AFunc: TFunc<T,TResult>; Arg: T ) : TFunc<TResult>;
  // das kann man jetzt mit beliebig vielen Argumenten weiterspinnen
end;

class function TAnonWrapper.Wrap<T>( AProc: TProc<T>; Arg: T ) : TProc;
begin
  Result := 
    procedure ()
    begin
      AProc( Arg );
    end;
end;

class function TAnonWrapper.Wrap<T,TResult>( AFunc: TFunc<T,TResult>; Arg: T ) : TFunc<TResult>;
begin
  Result :=
    function(): TResult
    begin
      Result := AFunc( Arg );
    end;
end;

Man kann sich also das gesamte Interface-Implementierungs-Boilerplate-Geraffel komplett sparen und alles euf einen gemeinsamen Typen herunterbrechen.

Und wenn ich nur noch eins implementieren muss, dann ist das halt weniger.

[Benmik]

So leid es mir tut, beim Anblicken des Codes habe ich eine Ahnung, mehr aber auch nicht.
Wie gesagt, ich habe ja funktionierenden Code, ich möchte nur begreifen, wie man das geschilderte Problem löst.
Also ganz schlicht, der Teil

Delphi-Quellcode:

  //-------------------------------------------------------
  procedure RufeAuf;
  begin
    TAsyncCalls.Invoke(
      procedure
      var i:integer;
      begin
        For i := 0 to 10 do
          If i < 11
            then TAsyncCalls.Invoke<integer>(TuWas,i));
    end);
  end;
  //-------------------------------------------------------

sähe dann wie aus?

Da wir schon beim Lernen sind, den Vorschlag

Delphi-Quellcode:

var
  TuWas: TAsyncCallArgGenericMethod<Integer>;

konnte ich nicht umsetzen da es mir nicht gelang, TAsyncCallArgGenericMethod sichtbar zu machen. Ich habe die Deklaration in AsyncCalls public gemacht, das hat den Compiler leider nicht interessiert.
Und wie sähe denn dann die Lösung aus?
Vielen Dank.

[Benmik]

Wie vielleicht der eine oder andere mitbekommen hat, habe ich die Frage noch einmal auf stackoverflow gestellt, da ich einfach nicht weiterkam. Das Ganze verlief mehr als unbefriedigend und endete mit einem Downvote von David Heffernan. Der jetzige Stand dort ist, dass mein Vorhaben nicht möglich ist.

Von der Diskussion hier habe ich zwei Dinge mitgenommen:

1. Es ist möglich
2. Aus pädagogischen Gründen liefern wir dir aber nicht die fertige Lösung

Und da bitte ich doch unsere Lords und Dukes hier, ihrem Herzen einen Stoß zu geben und zu zeigen, wie es geht. Weltweiter Dank wäre euch sicher.

[Benmik]

Nachdem ich mich ziemlich in das Problem verbissen habe, möchte ich hier eine Lösung präsentieren. Nochmal zu Erinnerung, hier geht es nicht um die Lösung eines konkreten Problems, da eine solche bereits vorliegt. Hier geht es um das Verstehen von Strukturen.
Ausgangspunkt war der apodiktische Verweis von David Heffernan auf die Dokumentation, die klar aussagt: "Nested procedures and functions (routines declared within other routines) cannot be used as procedural values." Demgegenüber steht die Erfahrung, dass viele Dinge möglich sind, auch wenn die Dokumentation (und David Heffernan) etwas anderes sagen.
Ich hatte einfach folgende (laienhafte) Vorstellung:

1. Jede Prozedur/Funktion hat eine Adresse
2. Der Compiler kennt diese Adresse und hat sie irgendwo gespeichert
3. Findet man diese Adresse, kann man die Prozedur/Funktion ausführen

Wie also kriegt man einen Pointer auf diese Adresse?
Erhellend (und zunächst enttäuschend) war diese Diskussion auf Stackoverflow vor 4 Jahren, wieder mit Beteiligung von DH. Nach dem Verweis auf die Dokumentation führte er aus:"If I recall correctly, an extra, hidden, parameter is passed to nested functions with the pointer to the enclosing stack frame. This is omitted in 32 bit code if no reference is made to the enclosing environment." Der Threadersteller schaute augenscheinlich im Assemblercode nach und fand: "It's an implicit parameter alright! The compiler assumes it has its thing in 'rcx' and the parameters to the function are at 'rdx' and 'r8', while in fact there's no 'its thing' and the parameters are at 'rcx' and 'rdx'." Alles ein klein wenig außerhalb meiner Reichweite.
Aber dann gibt es noch diesen Text mit dem Titel: "How to pass nested routine as a procedural parameter (32 bit )". Verblüffend, wenn man die Aussage der Dokumentation bedenkt. Dieser Text führt zu folgendem Code (Voraussetzung: Die Änderung von Sir Rufo mit

Delphi-Quellcode:

reference to

):

Delphi-Quellcode:

procedure TForm1.Haupt;
var i:integer;
  //-------------------------------------------------------
  function TuWas(i:integer):integer;
  begin
  end;
  //-------------------------------------------------------
  procedure RufeAuf;
  var p:Pointer;
  begin
    p := @TuWas;
    TAsyncCalls.Invoke(
      procedure
      var i:integer;
      begin
        For i := 0 to 10 do
          If i < 11
            then AsyncHelper.AddTask(TAsyncCalls.Invoke<integer>(p,i));
    end);
  end;
  //-------------------------------------------------------
begin
  RufeAuf;
end;

Dieser Code funktioniert, sogar mit der Helper-Klasse von Garco Zajik. Jetzt ist p nicht direkt eine prozedurale Variable, ist aber eigentlich wurscht, die Frage war ja, ob die Klassenmethode in eine Unterprozedur verlagert werden kann. Wie es aussieht, geht das doch. Was sagen die Experten?

[dummzeuch]

Zitat:

Zitat von Benmik (Beitrag 1339938)

die Frage war ja, ob die Klassenmethode in eine Unterprozedur verlagert werden kann. Wie es aussieht, geht das doch. Was sagen die Experten?

Das Problem ist, dass diese Lösung auf Compiler-Interna aufbaut, die nicht dokumentiert sind und ggf. bei der nächsten Version geändert werden können.

[Benmik]

Ja, das ist richtig, auch funktioniert es nicht unter 64 Bit. Zudem gibt es noch weitere Einschränkungen, in bestimmten Fällen muss man globale Variablen benutzen (wegen der Stack-Problematik?).
Fazit also: Lohnt sich nicht. Trotzdem gut, dass die liebe Seele jetzt Ruh hat. Und interessant war's auch.