3

背景

我正在编写一个托管的 x64 汇编器（它也是一个库），因此它有多个类，这些类定义了一个无符号 64 位整数属性，用作地址和偏移量。有些是文件偏移，有些是绝对地址（相对于主内存），还有一些是相对虚拟地址。

问题

我ulong在提到的场景中使用属性的数据类型，这很好用。但是，此类属性不符合 CLS。我可以将它们标记为[ClsCompliant(false)]，但是我需要为图书馆的用户提供符合 CLS 的替代方案。

选项和问题

有些人建议提供具有更大数据类型的替代属性，但这不是一个选项，因为没有更大的有符号整数原语可以保存从0to 的所有值UInt64.MaxValue。

我宁愿不将我的整个程序集标记为不符合 CLS，因为在大多数使用场景中，并非所有可能的值UInt64.MaxValue都被使用。因此，例如，Address我可以提供一个替代long属性AddressAlternative，它只接受正值。Address但是，当以某种方式包含高于 的值时会发生什么Int64.MaxValue。应该AddressAlternative抛出一些异常吗？

什么是合适的名称AddressAlternative？

为 的每种用法提供替代方案ulong会导致许多“双重”属性。有一个更好的方法吗？请注意，并非所有ulong属性的使用都具有相同的语义，因此单个struct不会削减它。

最后，我在构造函数参数中遇到了同样的 CLS 合规性问题。那么我应该long为这样的参数提供一个替代的重载接受吗？

我不介意在仅 CLS 的上下文中使用库时限制其（某些功能）的使用，只要它可以在大多数情况下使用即可。

4

2 回答 2

2

但是当它表示 Int64.MaxValue 以上的无符号地址时

您使用了错误的类型，地址必须存储在 IntPtr 或 UIntPtr 中。你的问题不可能是现实的。如果您无法承受丢失 UInt64 中的单个位，那么您离溢出太近了。如果这个数字代表一个索引，那么一个普通的 Int32 就可以了，.NET 内存 blob 被限制为 2 GB，即使在 64 位机器上也是如此。

如果它是一个地址，那么 IntPtr 会在很长一段时间内都可以使用。目前可用的硬件距离达到该限制还有 4.5 个数量级。需要非常彻底的硬件重新设计才能接近，当那一天到来时，您将有更大的问题需要担心。在我退休之前，9 EB 的虚拟内存对每个人来说都足够了。

于 2011-04-05T17:53:52.613 回答
0

Microsoft 将 64 位地址定义为 Int64，而不是 UInt64，因此您仍然可以符合 CLS。

请参阅http://msdn.microsoft.com/en-us/library/837ksy6h.aspx。

基本上说：

IntPtr 构造函数 (Int64)

使用指定的 64 位指针初始化 IntPtr 的新实例。

参数 value 类型：System.Int64 包含在 64 位有符号整数中的指针或句柄。

是的，我刚刚做了一个快速测试，以下在针对 x64 或 Any CPU 的项目中运行良好。我在代码中放置了一个断点并检查了x. 但是，当仅针对 x86 时，它将引发异常。

using System;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            IntPtr x = new IntPtr(long.MaxValue);
        }
    }
}

但是，如果事实证明你真的需要额外的一点。您可以提供两个库。一种是符合 CLS 的，一种不是——用户的选择。这可以通过使用#if 语句和使用条件编译符号来完成。这样，您可以定义相同的变量名，但定义不同。http://msdn.microsoft.com/en-us/library/4y6tbswk.aspx

于 2011-04-16T14:02:19.857 回答