背景
我正在编写一个托管的 x64 汇编程序(它也是一个库)，因此它有多个类，这些类定义了一个无符号的 64 位整数属性，用作地址和偏移量。有些是文件偏移量，有些是绝对地址(相对于主内存)，还有一些是相对虚拟地址。
问题
在上述场景中，我对属性使用 ulong 数据类型，并且效果很好。但是，此类属性不符合 CLS。我可以将它们标记为 [ClsCompliant(false)]，但随后我需要为库的用户提供符合 CLS 的替代方案。
选项和问题
一些 suggest提供具有更大数据类型的替代属性，但这不是一个选项，因为没有更大的带符号整数基元可以保存从 0 到 UInt64.MaxValue 的所有值。
我宁愿不将我的整个程序集标记为不符合 CLS，因为在大多数使用场景中，并未使用所有可能的值，直到 UInt64.MaxValue。所以，例如Address 我可以提供一个替代的 long 属性 AddressAlternative，它只接受正值。但是，当 Address 以某种方式包含一个高于 Int64.MaxValue 的值时会发生什么。 AddressAlternative 应该抛出一些异常吗？
AddressAlternative 的合适名称是什么？
为 ulong 的每次使用提供替代方案将导致许多“双重”属性。有一个更好的方法吗？请注意，并非 ulong 属性的所有用法都具有相同的语义，因此单个 struct 不会削减它。
最后，我在构造函数参数中遇到了同样的 CLS 合规性问题。那么我是否应该为这样的参数提供一个接受 long 的替代重载？
当从仅限 CLS 的上下文中使用库时，我不介意限制它的使用(某些功能)，只要它可以在大多数情况下使用即可。
最佳答案
but when it represents an unsigned address above Int64.MaxValue
您使用了错误的类型，地址必须存储在 IntPtr 或 UIntPtr 中。你的问题不可能是现实的。如果您不能承受在 UInt64 中丢失单个位，那么您方式太接近溢出了。如果这个数字代表一个索引，那么一个普通的 Int32 就可以了，.NET 内存块限制为 2 GB，即使在 64 位机器上也是如此。
如果它是一个地址，那么 IntPtr 将在很长很长一段时间内都没有问题。目前可用的硬件距离达到该限制还有 4.5 个数量级。需要非常彻底的硬件重新设计才能接近，当那一天到来时，你会有更大的问题需要担心。在我退休之前，9 艾字节的虚拟内存足够每个人使用。
关于c# - ulong 属性的符合 CLS 的替代方案，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5555294/