Delphi 2009 - 有错误吗?将假定无效的值添加到集合中
首先,我不是一个非常有经验的程序员。我正在使用 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),如果您可以对此甚至一般设置行为(例如“测试:设置 256..257”)进行一些测试,我将不胜感激。看看新版本中是否有任何变化很有趣。
First of all, I'm not a very experienced programmer. I'm using Delphi 2009 and have been working with sets, which seem to behave very strangely and even inconsistently to me. I guess it might be me, but the following looks like there's clearly something wrong:
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.
If you run the program and click the button, then, sure enough, it will display the string "3" in the text field. However, if you try the same thing with a number like 100, nothing will be displayed (as it should, in my opinion). Am I missing something or is this some kind of bug? Advice would be appreciated!
EDIT: So far, it seems that I'm not alone with my observation. If someone has some inside knowledge of this, I'd be very glad to hear about it. Also, if there are people with Delphi 2010 (or even Delphi XE), I would appreciate it if you could do some tests on this or even general set behavior (such as "test: set of 256..257") as it would be interesting to see if anything has changed in newer versions.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(6)
我很好奇,想看看生成的编译代码,并且我弄清楚了以下有关集合在 Delphi 2010 中如何工作的内容。它解释了为什么您可以在以下情况下执行
test := [8]
测试:1..2 组
,以及为什么Assert(8 in test)
之后立即失败。实际使用了多少空间?
一组
字节
对于每个可能的字节值都有一位,总共 256 位,即 32 个字节。一组 1..2
需要 1 个字节,但令人惊讶的是,一组 100..101
也需要一个字节,因此 Delphi 的编译器在内存分配方面非常智能。另一方面,7..8 的集合
需要 2 个字节,并且基于仅包含值0
和101
的枚举进行设置需要(喘气)13 个字节!测试代码:
结论:
字节集合
,有256个可能的位,32个字节。set of 1..2
的情况,它可能只使用第一个字节,因此SizeOf()
返回 1。对于set of 100.101
它可能只使用第 13 个字节,因此SizeOf()
返回 1。对于set of 7..8
它可能使用前两个字节,因此我们得到SizeOf()=2
。这是一个特别有趣的案例,因为它向我们展示了位不会向左或向右移动来优化存储。另一个有趣的例子是 TTestEnumeration2 集合:它使用 6 个字节,即使周围有很多不可用的位。编译器生成什么样的代码?
测试1,两组,均使用“第一个字节”。
对于那些了解汇编器的人,可以自己看看生成的代码。对于那些不懂汇编程序的人来说,生成的代码相当于:
这不是拼写错误,编译器对两个赋值使用相同的预编译值。
CompiledGenerateArray[1] = 2
。这是另一个测试:
同样,在伪代码中,编译后的代码如下所示:
同样,没有拼写错误:这次编译器对两个赋值使用不同的预编译值。
CompilerGenerateArray1[1]=2
而CompilerGenerateArray2[1]=0
;编译器生成的代码足够聪明,不会用无效值覆盖“B”中的位(因为 B 保存有关位 96..103 的信息),但它对这两个赋值使用非常相似的代码。结论
1..2 组
,使用1
和2
进行测试。对于7..8 组
仅使用7
和8
进行测试。我不认为set
被破坏了。它在整个 VCL 中很好地实现了它的目的(并且它在我自己的代码中也占有一席之地)。set of 1..2
与set of 0..7
表现相同的副作用是之前缺乏的副作用编译器中的优化。var test: set of 1..2; test := [7]
)编译器应该生成错误。我不会将其归类为错误,因为我认为编译器的行为不应该根据“程序员对坏代码做什么”来定义,而是根据“程序员对好代码做什么”来定义”;尽管如此,编译器应该生成Constant expression违反子范围边界
,就像您尝试以下代码一样:(代码示例)
{$R+} 编译的
,错误的分配应该会引发错误,就像您尝试以下代码一样:(代码示例)
I was curious enough to take a look at the compiled code that gets produced, and I figured out the following about how sets work in Delphi 2010. It explains why you can do
test := [8]
whentest: set of 1..2
, and whyAssert(8 in test)
fails immediately after.How much space is actually used?
An
set of byte
has one bit for every possible byte value, 256 bits in all, 32 bytes. Anset of 1..2
requires 1 byte but surprisinglyset of 100..101
also requires one byte, so Delphi's compiler is pretty smart about memory allocation. On the othter hand anset of 7..8
requires 2 bytes, and set based on a enumeration that only includes the values0
and101
requires (gasp) 13 bytes!Test code:
Conclusions:
set of byte
, with 256 possible bits, 32 bytes.set of 1..2
it probably only uses the first byte, soSizeOf()
returns 1. For theset of 100.101
it probably only uses the 13th byte, soSizeOf()
returns 1. For theset of 7..8
it's probably using the first two bytes, so we getSizeOf()=2
. This is an especially interesting case, because it shows us that bits are not shifted left or right to optimize storage. The other interesting case is theset of TTestEnumeration2
: it uses 6 bytes, even those there are lots of unusable bits around there.What kind of code is generated by the compiler?
Test 1, two sets, both using the "first byte".
For those understand Assembler, have a look at the generated code yourself. For those that don't understand assembler, the generated code is equivalent to:
And that's not a typo, the compiler uses the same pre-compiled value for both assignments.
CompiledGeneratedArray[1] = 2
.Here's an other test:
Again, in pseudo-code, the compiled code looks like this:
Again, no typo: This time the compiler uses different pre-compiled values for the two assignments.
CompilerGeneratedArray1[1]=2
whileCompilerGeneratedArray2[1]=0
; The compiler generated code is smart enough not to overwrite the bits in "B" with invalid values (because B holds information about bits 96..103), yet it uses very similar code for both assignments.Conclusions
set of 1..2
, test with1
and2
. For theset of 7..8
only test with7
and8
. I don't consider theset
to be broken. It serves it's purpose very well all over the VCL (and it has a place in my own code as well).set of 1..2
behave the same asset of 0..7
is the side-effect of the previous lack of optimization in the compiler.var test: set of 1..2; test := [7]
) the compiler should generate an error. I would not classify this as a bug because I don't think the compiler's behavior is supposed to be defined in terms of "what to do on bad code by the programmer" but in terms of "what to do with good code by the programmer"; None the less the compiler should generate theConstant expression violates subrange bounds
, as it does if you try this code:(code sample)
{$R+}
, the bad assignment should raise an error, as it does if you try this code:(code sample)
根据官方文档关于集合(我的重点):
现在,根据子范围类型:
因此,如果您指定
,则基本类型将是字节(最有可能),因此,如果
那么
将起作用,但并非
全部按照官方规范。
According to the official documentation on sets (my emphasis):
Now, according to Subrange types:
Therefore, if you specify
then the base type will be byte (most likely), and so, if
then
will work, but not
all according to the official specification.
我没有“内部知识”,但编译器逻辑似乎相当透明。
首先,编译器认为任何像
set of 1..2
这样的集合都是set of 0..255
的子集。这就是为什么set of 256..257
是不允许的。其次,编译器优化了内存分配 - 因此它只为
set of 1..2
分配 1 个字节。相同的 1 个字节被分配给set of 0..7
,并且这两个集合在二进制级别上似乎没有区别。简而言之,编译器在考虑对齐的情况下分配尽可能少的内存(这意味着编译器永远不会为set
分配 3 个字节 - 它会分配 4 个字节,即使set
code> 适合 3 个字节,例如set of 1..20
)。编译器处理
集
的方式存在一些不一致,可以通过以下代码示例进行演示:I have no "inside knowledge", but the compiler logic seems rather transparent.
First, the compiler thinks that any set like
set of 1..2
is a subset ofset of 0..255
. That is whyset of 256..257
is not allowed.Second, the compiler optimizes memory allocation - so it allocates only 1 byte for
set of 1..2
. The same 1 byte is allocated forset of 0..7
, and there seems to be no difference between the both sets on binary level. In short, the compiler allocates as little memory as possible with alignment taken into account (that means for example that compiler never allocates 3 bytes forset
- it allocates 4 bytes, even ifset
fits into 3 bytes, likeset of 1..20
).There is some inconsistency in a way the compiler treats
sets
, which can be demonstrated by the following code sample:集合存储为数字,并且实际上可以保存不在该集合所基于的枚举中的值。我预计会出现错误,至少当编译器选项中的范围检查处于打开状态时,但情况似乎并非如此。我不确定这是一个错误还是设计使然。
[编辑]
但这很奇怪:
A set is stored as a number and can actually hold values that are not in the enumeration on which the set is based. I would expect an error, at least when Range Checking is on in the compiler options, but this doesn't seem to be the case. I'm not sure if this is a bug or by design though.
[edit]
It is odd, though:
从我的角度来看,这是允许非连续枚举类型的副作用。
.NET 位标志也是如此:因为在这两种情况下,基础类型都与整数兼容,因此您可以在其中插入任何整数(在 Delphi 中仅限于 0..255)。
——杰罗恩
From the top of my head, this was a side effect of allowing non contiguous enumeration types.
The same holds for .NET bitflags: because in both cases the underlying types are compatible with integer, you can insert any integer in it (in Delphi limited to 0..255).
--jeroen
就我而言,没有错误。
例如,采用以下代码
现在,您可以从该代码中获得 2 个结果。如果使用 Range Checking TRUE 进行编译,则第二行将引发异常。如果您没有使用范围检查进行编译,则代码将在没有任何错误的情况下执行并显示消息对话框。
您遇到的情况与集合类似,只是没有编译器开关来强制在这种情况下引发异常(嗯,据我所知......)。
现在,从您的示例来看:
这本质上声明了一个字节大小的集合(如果您调用 SizeOf(Test),它应该返回 1)。一个字节大小的集合只能包含 8 个元素。在这种情况下,它可以包含[0]到[7]。
现在,举个例子:
现在,我需要承认我希望第一行出现“常量表达式违反子范围边界”(但不是第二行)
所以是的......编译器可能存在一个小问题。
至于你的结果不一致......我很确定使用集合的子范围值之外的设置值并不能保证在不同版本的Delphi上给出一致的结果(甚至可能在不同的编译上都不能......所以如果你的范围是 1..2,坚持使用 [1] 和 [2]。
As far as I'm concerned, no bugs there.
For exemple, take the following code
Now, you can get 2 result from this code. If you compiled with Range Checking TRUE, an exception will be raise on the 2nd line. If you did NOT compile with Range Checking, the code will execute without any error and display the message dialogs.
The situation you encountered with the sets is similar, except that there is no compiler switch to force an exception to be raised in this situation (Well, as far as I know...).
Now, from your exemple:
That essentially declare a Byte sized set (If you call SizeOf(Test), it should return 1). A byte sized set can only contain 8 elements. In this case, it can contains [0] to [7].
Now, some exemple:
Now, I need to admit I would kind of expect the "Constant expression violates subrange bounds" on the first line (but not on 2nd)
So yeah... there might be a small issue with the compiler.
As for your result being inconsistent... I'm pretty sure using set values out of the set's subrange values isn't guaranteed to give consistent result over different version of Delphi (Maybe not even over different compiles... So if your range is 1..2, stick with [1] and [2].