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

CoreData提供整数16，整数32和整数64存储，但不支持任何符号限定符。您可以将一个无符号整型（32位）存储为一个有符号长整型（64位），并确保整个范围内的值保留，但无符号长整型似乎需要一个128位有符号整数来存储，当然这不是' t由CoreData支持。有什么方法可以在coreData中存储unsigned long？有没有办法在核心数据中存储unsigned long？

来源

2012-01-19 Tony

[上一页评论晋升回答]

听起来就像是位模式这是对你很重要，而不是整数值本身。你可以将它作为一个签名来存储 - 只需将它转换为C签署的< - >无符号强制转换不会强制数学正确性并只保留这些位。重新使用它。

后续问题：

通常是在（Obj-）C（++），则可以无符号整数值存储到与等效符号整型变量，并且反之亦然。 C使用2的补码整数从符号 - >无符号定义等价于一个位复制，并且这两个类型的大小相同。换句话说，unsigned - > signed，是“实现定义” - 在实践中通常是意味着一个位拷贝。锵& 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至少会将其编译为直接分配（位拷贝）。）

来源

2012-01-20 04:01:43 CRD

你总是可以将[de]序列化为一个字符串。它并不是特别干净，但只要您可以将其解析为无符号长整型，它就可以存储它。

来源

2012-01-19 15:32:02 cdeszaq

不要转换为字符串。这非常昂贵。 –

就像我说过的那样，它不是干净的，但它会_work_，即使有可能_many_更好的方法。一般来说，字符串是一个功能“最低公分母”，许多人忘记了它们是UNIX进程间通信的全部基础。 – cdeszaq

然后人们开始抱怨CoreData速度很慢。 –

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

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

见有：

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

所以基本上一个unsigned long将是兼容的意志Integer32或Integer64。

来源

2012-01-19 15:32:38 Macmade

在这里稍微误解了这个问题，OP没有说unsigned long是128位，但是你看起来需要一个128位有符号值来存储所有可表示为无符号long的值 - 从技术上讲，你只需要一个65位有符号但是由于某些原因，他们不常见;-)。 'NSNumber'将一个无符号长整型存储为有符号的128位值（因为它在内部将所有整数存储为有符号）。 – CRD

如果你真的需要 64位无符号的全精度，你可以把它变形（查看文档有关存储非标准持久属性）。 CoreData让你存储任何方式的东西。但是你可能不需要完整的64位精度......？！？

来源

2012-01-19 17:46:53

我试图存储一个文件编号，它是作为一个无符号长整型给出的，我不确定os是如何保证inode编号的范围。 – Tony

@Tony - 听起来像是对你很重要的位模式，而不是整数值本身。你可以将它作为一个签名来存储 - 只需将它转换为C签名<->无符号强制转换不会强制数学正确性并只保留位。重新使用它。 – CRD

我明白了，这非常有帮助。如果它不是评论，我会将其标记为正确答案。现在，这是否意味着一般情况下，如果你有一个无符号值，你仍然可以将它存储在一个有符号值中，即使它溢出了，只要你保证稍后将它返回。 – Tony

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

回答

相关问题