为什么我不能用 < 和 > 比较两个 IntPtr？

Question

我目前的 a problem 带有不安全的指针，这似乎是一个编译器错误。

注意：问题不在于我使用了指针和不安全的代码；该代码运行良好。该问题与已确认的编译器错误有关，该错误在某些情况下拒绝编译合法代码。如果您对此问题感兴趣，请访问my other question

由于我的问题在于指针变量的声明，我决定解决这个问题，改用IntPtr，并在需要时转换为实际指针。

但是，我注意到我不能这样做：

IntPtr a = something;
IntPtr b = somethingElse;
if (a > b) // ERROR. Can't do this
{
}

> 和 < 运算符似乎没有为 IntPtr 定义。请注意，我确实可以比较两个实际的指针。

IntPtr 有一个.ToInt64() 方法。但是，这会返回一个 有符号 值，当涉及正值和负值时，与 > 和 < 进行比较时，可能会返回不正确的值。

说实话，考虑到pointer comparisons are performed unsigned，我真的不明白返回有符号值的.ToInt64() 方法有什么用，但这不是我的问题。

有人可能会说IntPtrs 是不透明的句柄，因此与> 和< 进行比较是没有意义的。不过我要指出的是IntPtr有加减法，也就是说IntPtr其实有一个顺序的概念，所以>和<确实有意义。

我想我可以将ToInt64() 的结果转换为ulong 然后进行比较，或者将IntPtr 转换为指针然后进行比较，但这让我想为什么不是>以及为IntPtr 定义的<。

为什么我不能直接比较两个IntPtrs？

Answer 1

IntPtr一直有点被忽视。在 .NET 4.0 之前，甚至没有 Add/operator+ 和 Subtract/operator-。

现在...如果你想比较两个指针，如果它们是IntPtr，则将它们转换为long，如果它们是UIntPtr，则将它们转换为ulong。请注意，在 Windows 上，仅当您使用带有 /3GB 选项的 32 位程序时才需要 UIntPtr，因为否则 32 位程序只能使用较低的 2gb 地址空间，而对于 64 位程序，很多使用的地址空间少于 64 位（此时为48 bits）。

很明显，如果您在 .NET 中进行内核编程，这会发生变化 :-)（我在这里开玩笑，我希望 :-)）

IntPtr 优于 UIntPtr 的原因：https://msdn.microsoft.com/en-us/library/system.intptr%28v=vs.110%29.aspx

IntPtr 类型符合 CLS，而 UIntPtr 类型不符合。在公共语言运行库中仅使用 IntPtr 类型。提供 UIntPtr 类型主要是为了与 IntPtr 类型保持架构对称性。

有些语言不区分有符号和无符号类型。 .NET 希望支持它们。

使用做一些测试

editbin /LARGEADDRESSAWARE myprogram.exe

（我什至可以让我的图形适配器崩溃 :-)）

static void Main(string[] args)
{
    Console.WriteLine("Is 64 bits", Environment.Is64BitProcess);

    const int memory = 128 * 1024;

    var lst = new List<IntPtr>(16384); // More than necessary

    while (true)
    {
        Console.Write("{0} ", lst.Count);

        IntPtr ptr = Marshal.AllocCoTaskMem(memory);
        //IntPtr ptr = Marshal.AllocHGlobal(memory);
        lst.Add(ptr);

        if ((long)ptr < 0)
        {
            Console.WriteLine("\nptr #{0} ({1}, {2}) is < 0", lst.Count, ptr, IntPtrToUintPtr(ptr));
        }
    }
}

我能够使用 32 位程序（在 64 位操作系统上）分配近 4 GB 的内存（所以我有否定的 IntPtr）

这里是从IntPtr 到UIntPtr 的演员表

public static UIntPtr IntPtrToUintPtr(IntPtr ptr)
{
    if (IntPtr.Size == 4)
    {
        return unchecked((UIntPtr)(uint)(int)ptr);
    }

    return unchecked((UIntPtr)(ulong)(long)ptr);
}

请注意，由于符号扩展的工作原理，您不能简单地执行(UIntPtr)(ulong)(long)ptr，因为它会在 32 位时中断。

但请注意，很少有程序真正支持 > 2 GB 的 32 位...http://blogs.msdn.com/b/oldnewthing/archive/2004/08/12/213468.aspx

Answer 2

比较 IntPtr 非常非常危险。 C# 语言不允许这样做的核心原因，即使 CLR 对此没有任何问题。

IntPtr 经常用于存储非托管指针值。大问题是：指针值不是有符号值。只有 UIntPtr 是存储它们的适当托管类型。 UIntPtr 的大问题是它不是符合 CLS 的类型。许多语言不支持无符号类型。 Java、JScript 和早期版本的 VB.NET 就是示例。因此，所有框架方法都使用 IntPtr。

它特别讨厌，因为它通常可以毫无问题地工作。从 32 位版本的 Windows 开始，地址空间的高 2 GB 保留给操作系统，因此程序中使用的所有指针值始终

但并非在所有情况下都是如此。您可以在 64 位操作系统上的 wow64 模拟器中作为 32 位应用程序运行。操作系统不再需要上面 2 GB 的地址空间，因此您获得了 4 GB 的地址空间。这非常好，现在 32 位代码经常绕过 OOM。指针值现在做 >= 0x80000000。现在 IntPtr 比较在完全随机的情况下失败。例如，0x80000100 的值实际上大于 0x7FFFFE00，但比较会说它更小。不好。而且它不会经常发生，指针值往往是相似的。而且它是非常随机的，实际的指针值是高度不可预测的。

这是一个没人能诊断出来的错误。

使用 C 或 C++ 的程序员也很容易犯这个错误，他们的语言不会阻止他们。微软想出了另一种方法来避免这种痛苦，这样的程序必须与特定的linker option 链接才能获得超过 2 GB 的地址空间。

Answer 3

恕我直言，IntPtr 并不是为了更高/更低比较等目标而开发的。它是存储内存地址的结构，只能测试是否相等。您不应该考虑内存中任何东西的相对位置（由 CLI 管理）。就像比较Enternet中哪个IP更高。