delphi - Delphi 2009-错误？将所谓的无效值添加到集合中

Question

首先，我不是一个非常有经验的程序员。我使用的是Delphi 2009，并且一直在使用集合，这些集合的行为似乎对我来说很奇怪，甚至不一致。我想可能是我，但以下内容看来似乎有问题:

unit test;

interface

uses
Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms,
Dialogs, StdCtrls;

type
TForm1 = class(TForm)
  Button1: TButton;
  Edit1: TEdit;
  procedure Button1Click(Sender: TObject);
private
    test: set of 1..2;
end;

var Form1: TForm1;

implementation

{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject);
begin
  test := [3];
  if 3 in test then
    Edit1.Text := '3';
end;

end.

如果您运行该程序并单击该按钮，那么毫无疑问，它将在文本字段中显示字符串“3”。但是，如果您尝试使用100这样的数字进行相同的操作，则不会显示任何内容(我认为应该如此)。我是否缺少某些东西，或者这是某种错误？意见将不胜感激!

编辑:到目前为止，似乎我并不孤单。如果有人对此有一些内在的了解，我会很高兴听到它。另外，如果有人使用Delphi 2010(或什至是Delphi XE)，如果您可以像这样或什至可以对常规设置行为(例如“test:set of 256..257”)进行一些测试，我将不胜感激。有趣的是，看看新版本中是否有任何更改。

Answer 1

我很好奇地查看了生成的编译代码，并弄清楚了以下有关set在Delphi 2010中的工作方式的信息。它解释了为什么可以在test := [8]时执行test: set of 1..2，以及为什么Assert(8 in test)在之后立即失败。

实际使用了多少空间？
set of byte的每个可能字节值都有一位，总共256位，共32个字节。 set of 1..2需要1个字节，但是令人惊讶的是set of 100..101也需要一个字节，因此Delphi的编译器在内存分配方面非常聪明。另一方面，set of 7..8需要2个字节，并基于仅包含值0和101的枚举进行设置(gasp)需要13个字节!

测试代码:

TTestEnumeration = (te0=0, te101=101);
TTestEnumeration2 = (tex58=58, tex101=101);

procedure Test;
var A: set of 1..2;
    B: set of 7..8;
    C: set of 100..101;
    D: set of TTestEnumeration;
    E: set of TTestEnumeration2;
begin
  ShowMessage(IntToStr(SizeOf(A))); // => 1
  ShowMessage(IntToStr(SizeOf(B))); // => 2
  ShowMessage(IntToStr(SizeOf(C))); // => 1
  ShowMessage(IntToStr(SizeOf(D))); // => 13
  ShowMessage(IntToStr(SizeOf(E))); // => 6
end;

结论:

集合背后的基本模型是set of byte，它具有256个可能的位，32个字节。

Delphi确定总32字节范围内所需的连续子范围，并使用该范围。对于set of 1..2来说，它可能仅使用第一个字节，因此SizeOf()返回1。对于set of 100.101，它可能仅使用第13个字节，因此SizeOf()返回1。对于set of 7..8，它可能使用前两个字节，因此我们得到SizeOf()=2。这是一个特别有趣的情况，因为它向我们展示了位不会向左或向右移动以优化存储。另一个有趣的情况是set of TTestEnumeration2:它使用6个字节，即使周围有很多不可用的位。

编译器生成什么样的代码？

测试1，两组，均使用“第一个字节”。

procedure Test;
var A: set of 1..2;
    B: set of 2..3;
begin
  A := [1];
  B := [1];
end;

对于那些了解汇编程序的人，请自己看一下生成的代码。对于那些不了解汇编器的人，生成的代码等效于:

begin
  A := CompilerGeneratedArray[1];
  B := CompilerGeneratedArray[1];
end;

那不是错字，编译器对两个分配使用相同的预编译值。 CompiledGeneratedArray[1] = 2。

这是另一个测试:

procedure Test2;
var A: set of 1..2;
    B: set of 100..101;
begin
  A := [1];
  B := [1];
end;

同样，在伪代码中，编译后的代码如下所示:

begin
  A := CompilerGeneratedArray1[1];
  B := CompilerGeneratedArray2[1];
end;

同样，没有错别字:这一次，编译器对两个分配使用不同的预编译值。 CompilerGeneratedArray1[1]=2而 CompilerGeneratedArray2[1]=0;编译器生成的代码足够聪明，不会用无效值覆盖“B”中的位(因为B保留了有关位96..103的信息)，但是对于这两种分配，它都使用了非常相似的代码。

结论

如果您使用基本集中的值进行测试，则所有设置操作都可以很好地工作。对于set of 1..2，请使用1和2进行测试。对于set of 7..8仅使用7和8进行测试。我不认为set坏了。它在整个VCL中都很好地达到了目的(并且在我自己的代码中也有位置)。

在我看来，编译器会为集合分配生成次优代码。我认为不需要表查询，编译器可以内联生成值，并且代码具有相同的大小但具有更好的局部性。

我的观点是，让set of 1..2的行为与set of 0..7相同，这是以前编译器缺乏优化的副作用。

在OP的情况下(var test: set of 1..2; test := [7])，编译器应生成一个错误。我不会将其归类为错误，因为我认为编译器的行为不应该根据“程序员对不良代码的处理方式”来定义，而应根据“程序员对不良代码的处理方式”来定义“;编译器应生成Constant expression violates subrange bounds，但尝试该代码时也应如此:

(代码示例)

procedure Test;
var t: 1..2;
begin
  t := 3;
end;

在运行时，如果代码是使用{$R+}编译的，则错误的赋值将引发错误，就像尝试此代码时一样:

(代码示例)

procedure Test;
var t: 1..2;
    i: Integer;
begin
  {$R+}
  for i:=1 to 3 do
    t := i;
  {$R-}
end;