有没有办法在核心数据中存储 unsigned long ？答案

【问题标题】：Is there any way to store unsigned long in core data?有没有办法在核心数据中存储 unsigned long ？
【发布时间】：2012-01-19 15:28:47
【问题描述】：

CoreData 提供 Integer 16、Integer 32 和 Integer 64 存储，但不支持任何符号限定符。您可以将无符号整数（32 位）存储为有符号长整数（64 位）并确保在整个范围内保留该值，但无符号长整数似乎需要存储 128 位有符号整数，这当然不是t 受 CoreData 支持。那么有什么方法可以将 unsigned long 存储在 coreData 中吗？

【问题讨论】：

标签： cocoa core-data size

【解决方案1】：

[上一条评论提升为回答]

听起来是位模式对您很重要，而不是整数值本身。您可以将其存储为有符号的 - 只需将其转换为 C 有符号无符号转换不会强制数学正确性，而只是保留位。将其重新投射以使用它。

跟进问题：

在 (Obj-)C(++) 中通常是的，您可以将无符号整数值存储到具有等效有符号整数类型的变量中，反之亦然。当使用 2 的补码整数并且两种类型的大小相同时，根据定义，从有符号 -> 无符号的 C 转换等同于位复制。反过来，无符号 -> 有符号是“定义的实现” - 实际上通常意味着位复制。 Clang 和 GCC 对两者都使用位复制，但如果您想绝对确定可以使用 union：

unsigned long r;
long l;

r = (unsigned long)l; // will always work (cast optional)

// following is l = (long)r (cast optional) without "implementation defined" risk
{ union { long sValue; unsigned long uValue; } tmp; tmp.uValue = r; l = tmp.sValue;}

但说真的，我怀疑有人会这样做！（注意：Clang 至少会将其编译为直接赋值（位复制）。）

【讨论】：

【解决方案2】：

如果您真的需要 64 位无符号的完整精度，您可以将其 可转换（查看有关存储 非标准持久属性的文档强>）。 CoreData 可以让你以这种方式存储任何东西。但是您可能不需要完整的 64 位精度...？！？

【讨论】：

我正在尝试存储一个文件编号，该编号以无符号长整数形式提供给我，我不确定操作系统对 inode 编号范围的保证。
@Tony - 听起来对您来说重要的是位模式，而不是整数值本身。您可以将其存储为有符号的 - 只需将其转换为 C 有符号无符号转换不会强制数学正确性，而只是保留位。将其重新投射以使用它。
我明白了，这很有帮助。如果不是评论，我会将其标记为正确答案。现在，这是否意味着一般来说，如果你有一个无符号值，你仍然可以将它存储在一个有符号值中，即使它溢出，只要你保证稍后将它转换回来？

【解决方案3】：

unsigned long 还不是 128 位。
（或者你有 128 位 CPU？）

在 Mac 上，根据您的 CPU 架构，它可能是 32 位或 64 位。

查看：

NSLog( @"%u", sizeof( unsigned long ) );

所以基本上unsigned long 将与Integer32 或Integer64 兼容。

【讨论】：

这里的问题略有误读，OP 没有说 unsigned long 是 128 位，但您似乎需要一个 128 位有符号值来存储所有可表示为 unsigned long 的值 - 从技术上讲，您只有需要 65 位签名，但由于某种原因，它们并不常见；-)。 NSNumber 将 unsigned long 存储为带符号的 128 位值（因为在内部它将所有整数存储为带符号的）。

【解决方案4】：

您始终可以将 [反] 序列化为字符串。它不是特别干净，但它使您能够存储它，只要您可以将其解析回无符号长整数。

【讨论】：

不要转换成字符串。太贵了。
就像我说的，它并不干净，但它会工作，即使可能有许多更好的方法。一般来说，字符串是功能性的“最小公分母”，许多人忘记了它们是 UNIX 进程间通信的全部基础。
然后人们开始抱怨 CoreData 很慢。
人们总是会抱怨，但如果他们不知道自己在做什么。有一个工作的起点比没有工作的起点更容易优化。