Warning: file_get_contents(/data/phpspider/zhask/data//catemap/7/symfony/6.json): failed to open stream: No such file or directory in /data/phpspider/zhask/libs/function.php on line 167

Warning: Invalid argument supplied for foreach() in /data/phpspider/zhask/libs/tag.function.php on line 1116

Notice: Undefined index: in /data/phpspider/zhask/libs/function.php on line 180

Warning: array_chunk() expects parameter 1 to be array, null given in /data/phpspider/zhask/libs/function.php on line 181
Delphi 正在手动调用SetLength(数组,0);有缺点吗?_Delphi_Dynamic Arrays_Delphi Xe7_Finalization - Fatal编程技术网

Delphi 正在手动调用SetLength(数组,0);有缺点吗?

Delphi 正在手动调用SetLength(数组,0);有缺点吗?,delphi,dynamic-arrays,delphi-xe7,finalization,Delphi,Dynamic Arrays,Delphi Xe7,Finalization,我总是将动态数组的初始化与以下形式的终结器配对 finally SetLength(Array, 0); end; 确切地知道数组何时被“破坏”感觉更自然,如果需要的话,我可以通过已经有“最终”可用的数组来更平滑地从数组过渡到TList 然而,这种方法使源代码更加缩进。这种方法有什么缺点吗?可读性、可维护性、可扩展性、性能、出错率 我编写的示例代码: var A1: array of Integer; A2: array on Boolean; A3: array of s

我总是将动态数组的初始化与以下形式的终结器配对

finally 
  SetLength(Array, 0); 
end;
确切地知道数组何时被“破坏”感觉更自然,如果需要的话,我可以通过已经有“最终”可用的数组来更平滑地从数组过渡到TList

然而,这种方法使源代码更加缩进。这种方法有什么缺点吗?可读性、可维护性、可扩展性、性能、出错率

我编写的示例代码:

var
  A1: array of Integer;
  A2: array on Boolean;
  A3: array of string;
begin
  SetLength(A1, 10);
  try
    ...
    SetLength(A2, 20);
    try
      ...
      SetLength(A3, 30);
      try
        ...
      finally
        SetLength(A3, 0);
      end;
    finally
      SetLength(A2, 0);
    end;
  finnally
    SetLength(A1, 0);
  end;
end;
这种方法有什么缺点吗?可读性、可维护性、可扩展性、性能、易出错性

可读性:当然

可维护性、可扩展性:正如您所说,这将使向
TList
的转换更加简单。但您从数组开始,然后将其转换为
TList
的频率是多少

性能:编译器已经完全执行了您正在执行的操作。现在已经发生了两次了。无事可做时对
SetLength
的冗余调用具有最小的开销,但是(至少32位)那些
try finally
块具有一些明显的开销

错误倾向性:任何时候你手工做一些编译器可以为你处理的事情,你都有可能犯错误。这种情况实际发生的频率比我更清楚,但从统计上看,是的,这样做会增加错误倾向

这种方法有什么缺点吗?可读性、可维护性、可扩展性、性能、易出错性

可读性:当然

可维护性、可扩展性:正如您所说,这将使向
TList
的转换更加简单。但您从数组开始,然后将其转换为
TList
的频率是多少

性能:编译器已经完全执行了您正在执行的操作。现在已经发生了两次了。无事可做时对
SetLength
的冗余调用具有最小的开销,但是(至少32位)那些
try finally
块具有一些明显的开销


错误倾向性:任何时候你手工做一些编译器可以为你处理的事情,你都有可能犯错误。这种情况实际发生的频率比我更清楚,但从统计学上讲,是的,这样做会增加错误倾向。

SetLength
的调用都不是必需的,因为变量在最后
结束时超出了范围语句并自动释放。如果变量的范围更广(单元范围或全局范围),则可能会有所不同。您还可以删除所有的
try..finally
块(如果它们的目的是这样的话),这使得整个缩进问题变得毫无意义。缩进量完全取决于您。如果您愿意,您可以有一个包含100行代码的过程,或者100个包含每行代码的过程。代码缩进不一定会影响性能。但是,在这种情况下,您可以一起初始化/取消初始化这些数组,并且只有一个
try..finally
块,尽管不建议这样做。@Jerry:绝对不需要调用SetLength或try..finally块。@KenWhite如果不这样做,我在某些情况下会遇到奇怪的问题,例如,在终止应用程序时,我遇到了一个异常(不记得具体是什么),通过将数组的长度设置为0解决了这个问题。我同意Mason所说的一切。另外,对动态数组使用
TArray
,因为泛型的类型兼容性更宽松。对
SetLength
的调用都不是必需的,因为变量在最后的
末尾超出了范围语句并自动释放。如果变量的范围更广(单元范围或全局范围),则可能会有所不同。您还可以删除所有的
try..finally
块(如果它们的目的是这样的话),这使得整个缩进问题变得毫无意义。缩进量完全取决于您。如果您愿意,您可以有一个包含100行代码的过程,或者100个包含每行代码的过程。代码缩进不一定会影响性能。但是,在这种情况下,您可以一起初始化/取消初始化这些数组,并且只有一个
try..finally
块,尽管不建议这样做。@Jerry:绝对不需要调用SetLength或try..finally块。@KenWhite如果不这样做,我在某些情况下会遇到奇怪的问题,例如,在终止应用程序时,我遇到了一个异常(不记得具体是什么),通过将数组的长度设置为0解决了这个问题。我同意Mason所说的一切。另外,对动态数组使用
TArray
,因为泛型的类型兼容性更宽松。请注意,在使用dynarray的任何函数体周围都有隐式try finally块,因此实际上有6个(!!!)示例代码中嵌套了try-finally块。请注意,在使用dynarray的任何函数体周围都有隐式try-finally块,因此示例代码中实际上有6(!!!)个嵌套的try-finally块。