Flash 有趣的AS3哈希情况。它真的像文档所说的那样使用严格的平等吗？

AS3代码：

import flash.utils.Dictionary;
var num1:Number = Number.NaN;
var num2:Number = Math.sqrt(-1);
var dic:Dictionary = new Dictionary( true );
trace(num1); //NaN
trace(num2); //NaN
dic[num1] = "A";
trace( num1 == num2 ); //false
trace( num1 === num2 ); //false
trace( dic[num1] ); //A
trace( dic[num2] ); //A

关于关键比较方法。。。

---

如果字典使用严格相等，如文档所述，那么num1===num2是假的，而dic[num1]解析为与dic[num2]相同的哈希槽，这是怎么回事呢？

老实说，Adobe给出的描述既不准确也不正确，但它更简单，涵盖了大多数情况

您应该尝试以下方法：

for (var key:* in dic) trace(getQualifiedClassName(key));//will give you 'String'

这种行为同样适用于

数组

和

对象

根据经验：

int

保持

int

，任何其他键都将转换为其字符串表示形式（包括布尔值和浮点值，以及

null

和

未定义的

）

Dictionary

类的不同之处在于它不将非基本对象转换为

String

，而是直接将它们用作键。它们处理所有其他值的方式是“继承”

Object

，如果您愿意的话

基本上，

对象由两个哈希组成，一个用于字符串，一个用于整数键。而
字典
添加了另一个散列，可能只是简单地使用对象内存地址作为整数键

编辑：这不是对实际问题的回答，而是我想详细解释的一点，以回应Triynko的评论：

哈奇？你是说，让它在一个
它不是设计用来工作的吗？好。。。
因为它不是设计用来处理
64位整数，当然是一个
乱劈但是64位就是64位，无论
它们被解释为整数或整数
浮点数

使用64位浮点来表示64位整数已经是一个坏主意，因为从语义上讲，这是完全错误的（您通常可以预期这种误用会导致问题）

但是，将它们的字符串表示形式用作键（如果将浮点用作键，则会发生这种情况）显然是自杀：

var f1:Number = 1000000000000003000000000.0;
var f2:Number = 1000000000000002000000000.0;
trace(f1 == f2);//false
trace(String(f1) == String(f2));//true ... kabooooom

您将很难确定2个64位整数何时会发生冲突，因为前提是它们被解释为浮点数的值的字符串表示形式必须相等。另外，不同的播放器版本可能有不同的浮动字符串转换，也可能有其他运行时，例如。我真的不想依赖这个。当有足够的数据导致冲突时，这会产生一种似乎不知从何而来的bug。你不会喜欢追踪他们

此外，浮点键的性能更差，因为它们在用于哈希查找之前必须转换为字符串。如果您真的非常关心大小，那么您必须以64位int格式传输数据，并仅在闪存端将其转换为十六进制字符串。

尽管如此，我要指出，许多人非常乐意使用XML或JSON，这会带来更糟糕的开销

带宽和任何其他硬件资源都很便宜。发展是昂贵的。你应该编写可维护且健壮的应用程序，否则从长远来看，它们的成本会更高

格里茨

back2dos
恐怕你在这里遇到了一些相当棘手的问题
Dictionary
的工作原理与广告中的一样，即它使用对象标识作为键，而不按值测试对象。在大多数情况下，这与使用严格相等是一样的，因为在大多数情况下，对同一对象的两个引用彼此严格相等

问题在于AS3规范有一个特殊情况：根据定义，所有与NaN的比较都被认为是错误的——甚至是NaN与自身之间的比较（这就是示例代码所做的）。如果NaN在比较中显式出现，甚至会有一个编译时警告。此外，对于一些其他原语，如“true”和“undefined”，还有其他特殊情况

如果您尝试不同的测试值，应该很容易看到发生了什么：

import flash.utils.Dictionary;
var num1:Number = Number.POSITIVE_INFINITY;
var num2:Number = 1 / 0;
var dic:Dictionary = new Dictionary( true );
trace(num1); // Infinity
trace(num2); // Infinity
dic[num1] = "A";
trace( num1 == num2 ); // true!!
trace( num1 === num2 ); // true!!
trace( dic[num1] ); //A
trace( dic[num2] ); //A

这可能看起来很奇怪，这取决于你习惯了什么语言，但这意味着当你创建两个对无穷大的不同引用时，因为3不会给你两个值为无穷大的不同对象，它会给你两个对同一个无穷大对象的引用。因此，引用严格相等，并且它们的键指向相同的值。使用NaN而不是无穷大在各个方面的工作方式都是相同的，除了将值与自身进行比较的部分——由于NaN是一种特殊情况，当它返回false时。
两个稍有不同的IEEE-754双精度浮点值是否会解析为同一字符串？例如，（0.3）.toString（）和（0.1+0.2）.toString（）是略有不同的浮点值，它们解析为不同的字符串。因此，我想知道是否有任何异常值确实略有不同，但解析为相同的字符串（与我的示例不同）。我在SQL Server中使用.NET Int64 ID，并使用BitConverter.Int64BitsToDouble将它们编组为双精度闪存，因为闪存支持IEEE-754双精度，但不支持64位整数。我想用它们作为字典的键，但我不相信它会起作用。。。因为我将处理字典中许多只相差一点点的键。若字典正在比较字符串，那个么可能有问题。我将制作自己的字典，将双精度数写入ByteArray，然后读取每一半作为32位int键进行比较，并使用带有32位int键的两级散列。似乎可以工作，使用双精度数作为键至少到100000，所以我可以按原样使用它们。我一次将3个64位整数写入一个字节数组，每个整数递增1，所以（0,1,2）是第一次出现。。。然后我把它们读出来作为双精度键，并将它们用作键，然后尝试使用键2和键3访问键1。它永远无法访问它们，所以我知道它把只有几位不同的数字视为不同的键。很高兴知道这些。@Triynko:我想，你所做的是非常令人讨厌的。老鼠