delphi - 组合匿名过程和嵌套过程时出现错误代码

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;

...

确实有效。

生成的机器代码

S := 'Hello, world!';

失败的程序是

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

正确的版本是

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已被移动到编译器生成的类，[ebp+$24]是外部本地的方式访问嵌套方法的变量如何访问局部变量。

Answer 1

没有看到整个汇编器代码(程序测试)并且仅假设您发布的代码片段，很可能在失败的代码片段上仅移动了一个指针，而在正确的版本上也移动了一些数据。

所以看来 S:=S 或 S:='' 会导致编译器自己创建一个引用，甚至可以分配一些内存，这可以解释它的工作原理。

我还假设这就是为什么在没有 S:=S 或 S:='' 的情况下发生访问冲突的原因，因为如果没有为字符串分配内存(记住您只声明了 S: PChar)，则会引发访问冲突，因为访问了未分配的内存。

如果您只是声明 S: String，则可能不会发生这种情况。

扩展评论后的补充:

PChar 只是一个必须存在的数据结构指针。 PChar 的另一个常见问题是声明局部变量，然后将 PChar 传递给该变量到其他过程，因为发生的情况是，一旦例程结束，局部变量就会被释放，但 PChar 仍然会指向它，然后引发一旦访问就会发生访问冲突。

每个文档存在的唯一可能性是声明类似 const S: PChar = 'Hello, world!' 的内容，因为编译器可以解析到它的相对地址。但这仅适用于常量，不适用于上面示例中的变量。像上面的示例中那样执行需要为 PChar 然后指向的字符串文字分配存储空间，例如 S:String; P:PChar； S:='你好，世界!'; P:=PChar(S); 或类似的。

如果声明 String 或 Integer 仍然失败，那么变量可能会在某个地方消失或者突然在过程中不再可见，但这将是另一个问题，与已经解释的现有 PChar 问题无关。

最终结论:

可以执行S:PChar; S:='Hello, world!' 但编译器只需将其分配为本地或全局常量，就像 const S: PChar = 'Hello, world!' 那样，将其保存到可执行文件，第二个 S := 'Hello' 然后创建另一个也保存到可执行文件中的文件，依此类推 - 但 S 然后只指向最后分配的一个，所有其他的仍在可执行文件中，但在不知道确切位置的情况下无法再访问，因为 S 只指向最后分配的一个。

因此，根据最后一个 S 指向 Hello, world! 或 Hello。在上面的示例中，我只能猜测哪一个是最后一个，谁知道编译器也许也只能猜测，并且根据优化和其他不可预测的因素，S可能会突然指向未分配的 Mem 而不是最后一个当执行 Showmessage(S) 时，会引发访问冲突。