使用不可复制的对象作为 NSMutableDictionary 的键？

Question

我试图找出这段代码引用：Cocoa：带有枚举键的字典？

+ (NSValue*)valueWithReference:(id)target
{
    return [NSValue valueWithBytes:&target objCType:@encode(id*)];
}

并且，

[table setObject:anObject forKey:[NSValue valueWithReference:keyObject]];

但感觉有些不太好。有什么建议吗？

Answer 1

你说得对，这不好。

其一，您编码了错误的类型（应该是 @encode(id)，而不是 @encode(id*)），但在大多数情况下，这应该是'不会造成大问题。

更大的问题是这完全忽略了内存管理。该对象不会被保留或复制。如果其他代码释放它，它可能会消失，然后你的字典键将是一个指向垃圾的装箱指针，甚至是一个完全不同的对象。这基本上是世界上最先进的悬空指针。

您有两个不错的选择：

1. 您可以将 NSCopying 添加到类中或创建一个可复制的子类。

   • 此选项仅适用于可有意义复制的对象。这是大多数类，但不一定是全部（例如，有多个对象代表同一输入流可能会很糟糕）
   • 即使对于有意义的类来说，实现复制也可能很痛苦 - 本身并不困难，但有点烦人
2. < p>您可以使用 CFDictionary 创建字典API。由于 Core Foundation 类型没有通用复制功能，CFDictionary 默认情况下仅保留其键（尽管您可以根据需要自定义其行为）。但 CFDictionary 也与 NSDictionary 进行免费桥接，这意味着您只需将 CFDictionaryRef 转换为 NSDictionary* （或 NSMutableDictionary*）然后像对待任何其他 NSDictionary 一样对待它。
   • 这意味着您用作键的对象在字典中时不得更改（至少不能以影响其哈希值的方式更改）——确保不会发生这种情况这就是为什么 NSDictionary 通常想要复制它的键

Answer 2

供以后参考。

现在我知道还有更多选择。

1. 重写 NSCopying 协议中的方法，并返回 self 而不是复制自身。 （如果您不使用 ARC，则应该保留它）此外，您还确保对象始终为 -hash 方法返回相同的值。

2. 创建一个可复制的简单容器类，对原始关键对象持有强引用。容器是可复制的，但是在复制时它只传递原始密钥。覆盖相等/散列方法也可以匹配语义。即使只是 NSArray 的实例仅包含关键对象也能很好地工作。

方法#1 看起来很安全，但实际上我不确定这是否安全。因为我不知道 NSDictionary 的内部行为。所以我通常使用 #2 方式，这在 Cocoa 约定中是完全安全的。

更新

现在，从 6.0 版开始，我们在 iOS 中也有了 NSHashTable 和 NSMapTable。

Answer 3

我不能 100% 确定该解决方案的正确性，但我将其发布以防万一。

如果您不想使用 CFDictionary，也许您可​​以使用这个简单的类别：

@implementation NSMutableDictionary(NonCopyableKeys)
- (void)setObject:(id)anObject forNonCopyableKey:(id)aKey {
    [self setObject:anObject forKey:[NSValue valueWithPointer:aKey]];
}

- (id)objectForNonCopyableKey:(id)aKey {
    return [self objectForKey:[NSValue valueWithPointer:aKey]];
}

- (void)removeObjectForNonCopyableKey:(id)aKey {
    [self removeObjectForKey:[NSValue valueWithPointer:aKey]];
}
@end

这是我在网上看到的类似方法（找不到原始来源）的概括，用于使用可以使用 UITouch 键存储对象的 NSMutableDictionary。

与 Chuck 的答案相同的限制适用：用作键的对象不得以影响其散列值的方式更改，并且当它位于字典中时不得被释放。

另请确保不要混合使用 -(void)setObject:(id)anObject forNonCopyableKey:(id)aKey 和 - (id)objectForKey:(id)aKey 方法，因为它不起作用（后者将返回nil）。

这似乎工作正常，但可能会产生一些我没有想到的不良副作用。如果有人发现此解决方案有任何其他问题或警告，请发表评论。