匿名プロシージャとネストされたプロシージャを組み合わせたときのコードが間違っています

Question

私は正しいと思われるDelphiコードに対して予期しないアクセス違反がありますが、誤ってコンパイルされているようです。私はそれを減らすことができます

procedure Run(Proc: TProc); 
begin 
    Proc; 
end; 

procedure Test; 
begin 
    Run(
    procedure 
    var 
     S: PChar; 

     procedure Nested; 
     begin 
     Run(
      procedure 
      begin 
      end); 
     S := 'Hello, world!'; 
     end; 

    begin 
     Run(
     procedure 
     begin 
      S := 'Hello'; 
     end); 
     Nested; 
     ShowMessage(S); 
    end); 
end; 

私には、S := 'Hello, world!'が間違った場所に格納されています。そのため、アクセス違反が発生するか、ShowMessage(S)が "Hello"を示します（また、匿名プロシージャの実装に使用されるオブジェクトを解放するときにアクセス違反が発生することもあります）。

私はすべてのアップデートがインストールされているDelphi XEを使用しています。

これがどこに問題を引き起こすかをどのように知ることができますか？私は匿名の手続きを避けるためにコードを書き直す方法を知っていますが、間違ったコードにつながる状況を正確に把握することができないので、どこを避けるべきかわかりません。

これがDelphiのそれ以降のバージョンで修正されているのは興味深いですが、興味深いだけではありません。この時点でアップグレードはオプションではありません。

QCの最新のレポートでは、同様の#91876が見つかりましたが、それはDelphi XEで解決されています。

更新：AlexSCのコメントに基づいて

、若干の変更で：

... 

     procedure Nested; 
     begin 
     Run(
      procedure 
      begin 
      S := S; 
      end); 
     S := 'Hello, world!'; 
     end; 

... 

が作業を行います。正しいバージョンが失敗したプログラムで生成されたコードを見ていない

ScratchForm.pas.45: S := 'Hello, world!'; 
004BD981 B8B0D94B00  mov eax,$004bd9b0 
004BD986 8B5508   mov edx,[ebp+$08] 
004BD989 8B52FC   mov edx,[edx-$04] 
004BD98C 89420C   mov [edx+$0c],eax 

ある一方

失敗プログラムで

S := 'Hello, world!'; 

用に生成されたマシンコードは

ScratchForm.pas.44: S := 'Hello, world!'; 
004BD971 B89CD94B00  mov eax,$004bd99c 
004BD976 894524   mov [ebp+$24],eax 

ありますSがコンパイラ生成クラスに移動されましたはです。ネストされたメソッドの外側ローカル変数へのアクセス方法ローカル変数のアクセス方法

Answer 1

これはどこで問題が発生するのでしょうか。

この時点では分かりにくいです。
Delphi XE2での修正の性質を知っていれば、より良い立場にいます。
匿名機能の使用を控えることができます。
デルファイには手続き型の変数があります。そのため、匿名関数を準備する必要はありません。
http://www.deltics.co.nz/blog/posts/48を参照してください。

これはXE2で修正されてい@Sertac Akyuzによると

デルファイのそれ以降のバージョンで固定されているかどうかを知ることが私には興味深いものになるだろう。

個人的に私は匿名メソッドを嫌い、私たちのコードベースのかなりの部分が匿名（イベントハンドラ）になっているため、Javaプロジェクトでそれらを使用することを禁止する必要がありました。
極端な節度で使用すると、私はユースケースを見ることができます。
しかし、私たちはプロシージャ変数と入れ子になったプロシージャを持っているデルファイで...それほど多くはありません。

Answer 2

あなたが投稿したスニペットを仮定しているだけで、全体のアセンブラコードを見ることなく（おそらく、失敗したスニペットでポインタが移動されたのは正しいバージョンでは、 。

S：= SまたはS：= ''は、コンパイラに自身の参照を作成させ、いくつかのメモリを割り当てることもできます。

また、S：= SまたはS：= ''なしでアクセス違反が発生する理由は、（文字列に割り当てられたメモリがない場合はS：PCharと宣言しただけなので）アクセス違反が発生する割り当てられていないメモリがアクセスされたためです。

単純にS：Stringを宣言すると、これは起こりません。コメント拡張後

追加：

A PChar型が存在しなければならないデータ構造へのポインタのみです。 PCharの別の共通の問題は、ローカル変数を宣言し、その変数に他のProcsにPCharを渡すことです。なぜなら、ルーチンが終了するとローカル変数は解放されますが、PCharはまだそれを指し示します一度アクセスされた違反にアクセスする。

ドキュメントごとに存在する唯一の可能性は、const S: PChar = 'Hello, world!'のように宣言しています。これは、コンパイラが相対アドレスを解決できるためです。しかし、これは上の例のような定数ではなく、変数でのみ機能します。上記の例のようにするには、PCharが指す文字列リテラルに割り当てられるストレージがS:String; P:PChar; S:='Hello, world!'; P:=PChar(S);またはそれに類するものである必要があります。

文字列または整数の宣言に失敗した場合、おそらく変数がどこかに消えたり、procで突然表示されなくなる可能性がありますが、これは既に説明した既存のPCharの問題とは関係のない別の問題です。

最終的な結論：

それはS:PChar; S:='Hello, world!'を行うことは可能ですが、コンパイラは、単に実行可能ファイルに保存されているんconst S: PChar = 'Hello, world!'などのローカルまたはグローバル定数、S := 'Hello'第二は、その後もに保存されている別のものを作成して、それを割り当てExecutableなど - しかし、Sは、割り当てられた最後のものだけを指し示します。Sは、割り当てられた最後のものを指しているため、正確な位置を知らなくても、実行可能ファイルに残りますが、

最後にSのいずれかに応じて、Hello, world!またはHelloのいずれかになります。上の例では、私は最後のものしか推測できませんでした。おそらく、コンパイラは推測しかできないでしょう。また、最適化やその他の予測不可能な要因によっては、Sが、最後のものではなく割り当てられていないMemを突然指すことがあります。Showmessage(S)アクセス違反が発生します。