Warum gibt es hier eine Acess Violation?

[jaenicke]

Zitat:

Zitat von Benmik (Beitrag 1420351)

Daher würde ich jaenickes Ratschlag auch nur äußerst ungern folgen, denn so kann ich den Weg einer Variablen durch die Unterprozeduren leicht verfolgen. Mit F8 gehe ich durch die 10 Zeilen mit den Namen der Unterprozeduren und sehe viel leichter, wo etwas geschieht, was ich nicht beabsichtigt habe.

Das verlierst du doch gar nicht. Du hast ja die gleichen Variablen, die in der Hauptprozedur deklariert sind. Der Unterschied ist, dass du genau siehst welche davon an welche Unterroutine übergeben werden (das sollten natürlich nur die sein, die dort auch gebraucht werden).
Und innerhalb der Unterroutine siehst du beim Debuggen dann auch nur die dort relevanten lokalen Variablen.
Wenn man dann noch konsequent mit const und var arbeitet, kann der Compiler einerseits gut optimieren und andererseits sieht man wo eine Variable beschrieben werden kann.

Insofern ändert sich bezüglich des Debuggens nicht viel, aber die Komplexität nimmt ab (welche Variable wird eigentlich wo initialisiert?) und es ist übersichtlicher (weil man genau sieht was wo benutzt wird).

[Benmik]

Da hast du recht. Ich hatte in letzter Zeit auch viel mit VBA zu tun, und da gilt die Überwachung einer Variable nur für eine Routine, oder sie muss global sein. Tatsächlich wertet der Debugger alles aus, was so heißt, wie man es mit F5 eingetragen hat. Wundert mich eigentlich, wo Pascal doch sonst so kleinlich ist.

Ich fürchte aber, ich bin nur schwer auf den Pfad der Tugend zu bringen. Zum einen sind das oft ziemlich viele prozedurweite Variablen, die kann ich ja nicht alle per Argument weitergeben. Ich weiß, das bedeutet schon mal, dass das Design nicht so dolle ist. Ich habe mich da auch schon gebessert. Aber mit diesen prozedurweiten Variablen habe ich eigentlich kaum je Probleme, also werde ich sie wohl heimlich weiterbenutzen und nicht darüber reden.8-)

[jaenicke]

Ich arbeite auch mit altem Quelltext, in dem immer wieder mal relativ viele lokale Variablen in diversen Unterroutinen benutzt wurde. Deshalb weiß ich eben auch aus eigener bitterer Erfahrung wie problematisch das sein kann, insbesondere bei der Fehlersuche. ;-)

[Uwe Raabe]

Zitat:

Zitat von Benmik (Beitrag 1420387)

Aber mit diesen prozedurweiten Variablen habe ich eigentlich kaum je Probleme

Das sieht man ja auch ganz deutlich an diesem Thread...

[Benmik]

Hier noch ein Codesplitter, der in den Bereich des ursprünglichen Themas fällt.

[Uwe Raabe]

Und da steht es ja auch schon genauso drin, daß es in dieser Situation crasht:

Zitat:

There is, however, a pitfall in the above example -
if the "inner" routine references any variable that was pushed onto
the stack before the "inner" procedure was called from testpass
(calltestpass parameters - if there were any, or local variables in
calltestpass - if there were any), your system most probably crashes:

Delphi-Quellcode:

{ This code compiles OK but generates runtime exception (could even be
  EMachineHangs :-) ) }
procedure testpass(p: pointer);
begin
  tProcedure(p);
end;
procedure calltestpass;
var msg: string;
 procedure inner;
 begin
   msg := 'hello';
   showmessage(msg);
 end;
begin
  testpass(@inner);
end;

[Benmik]

Sí, Señor! Es steht aber auch drin, wie man das mit Assembler austrickst. Ein Vorgehen, das David Heffernan immer mit hochrotem Kopf als "filthy hack" geißelt.

Für mich lehrreich, weil ich ja im Leben nicht auf solche Hintergründe gekommen wäre. Es gibt halt mehr zwischen Himmel und Erde, als sich unserer Schulweisheit träumen lässt. Tröstlicherweise gilt das aber auch für die Experten.

[Benmik]

Eine weitere Fundstelle ist AsyncCalls von Andreas Hausladen, und zwar die dortige Funktion LocalVclCall:

Delphi-Quellcode:

procedure TFormMain.MainProc; 

  procedure DoSomething; 

    procedure UpdateProgressBar(Percentage: Integer); 
    begin 
      ProgressBar.Position := Percentage; 
      Sleep(20); // This delay does not affect the time for the 0..100 loop 
                 // because UpdateProgressBar is non-blocking. 
    end; 

    procedure Finished; 
    begin 
      ShowMessage('Finished'); 
    end; 

  var 
    I: Integer; 
  begin 
    for I := 0 to 100 do 
    begin 
      // Do some time consuming stuff 
      Sleep(30); 
      LocalAsyncVclCall(@UpdateProgressBar, I); // non-blocking 
    end; 
    LocalVclCall(@Finished); // blocking 
  end; 

var 
  a: IAsyncCall; 
begin 
  a := LocalAsyncCall(@DoSomething); 
  a.ForceDifferentThread; // Do not execute in the main thread because this will 
                          // change LocalAyncVclCall into a blocking LocalVclCall 
  // do something 
  //a.Sync; The Compiler will call this for us in the Interface._Release method 
end;

Da frage ich mich, ob die auch darauf beruht, dass hier keine "innere" Variable zwischen den Aufrufen geändert wird.
Im Quelltext wird fleißig mit Inline-ASM gearbeitet, offenbar (auch) an den Stack-Adressen.

Warum ist diese Funktion übrigens als "Deprecated" gekennzeichnet? AsyncCalls wird seit 2016 nicht mehr weiterentwickelt, warum dann das "Deprecated" bei einzelnen Funktionen?