新的IntPtr.Add方法-我是否缺少int的要點？

Question

從FW 4.0開始， IntPtr結構具有Add方法：

public static IntPtr Add(
    IntPtr pointer,
    int offset
)

這是偉大的，因為它應該解決所有這些問題IntPtr我們有數學（ 1 ， 2 ，可能更多）。

但是為什么offset int呢？
一定不是IntPtr嗎？ 我可以輕松地想象將一個64位指針偏移一個超出int范圍的值。

---

例如，考慮Marshal.OffsetOf ：

public static IntPtr OffsetOf(
    Type t,
    string fieldName
)

它返回一個IntPtr作為結構成員的偏移量。 這是完全合理的！ 而且，您無法輕松地通過新的Add方法使用此偏移量。 您必須將其Int64為Int64 ，然后在循環中多次調用Add 。

同樣，這似乎扼殺了IntPtr.Size與正確編寫的應用程序無關的想法。 您將必須將偏移量轉換為特定類型，例如Int64 ，此時必須開始管理大小差異。 並IntPtr當出現128位IntPtr時會發生什么。

---

我的問題是，為什么？
我的結論是正確的，還是我遺漏了重點？

Answer 1

它對應於x64體系結構中的限制。 相對尋址限制為帶符號的32位偏移值。 馬特·彼得雷克（Matt Pietrek）在本文中提到了這一點 （“幸運的是，答案是否定的”）。 此限制還解釋了為什么在64位模式下.NET對象仍限於2GB。 同樣，在本機x64 C / C ++代碼中，內存分配也受到限制。 這並不是說這是不可能的，排量可以存儲在一個64位寄存器，它只是這將使數組索引貴了不少 。

Marshal.OffsetOf（）的神秘返回類型可能是一個極端情況。 在應用大於2GB的[StructLayout]和[MarshalAs]之后，托管結構可能會導致非托管版本。

是的，這不太適合將來的某些128位體系結構。 但是，當沒人知道它的外觀時，很難為當今的軟件准備一個拱門。 也許古老的格言是合適的，對於任何人來說16 TB應該足夠了。 並有大量的空間留給增長超出，2 ^ 64是相當大的多。 當前的64位處理器僅實現2 ^ 48。 在機器可以移動到如此近的距離之前，需要解決一些嚴重的非平凡問題。

Answer 2

如果僅定義：

public static IntPtr Add(IntPtr pointer, IntPtr offset)

那么，恕我直言，將32位偏移量添加到64位指針上的可讀性較差。

同樣，如果您定義

public static IntPtr Add(IntPtr pointer, long offset)

那么，將64位偏移量添加到32位指針也是不好的。

順便說一下， Substract返回一個IntPtr，因此無論如何都不會破壞IntPtr邏輯。