1

したがって、私が知る限り、私が見つけた IntPtr 追加の管理された例はすべてWRONGです。

例: http://www.atalasoft.com/cs/blogs/stevehawley/archive/2006/10/16/10987.aspx

私の考えでは、32 ビット システムで IntPtr が int32.MaxValue に (またはその近くに) あり、int32 をオーバーフローするオフセットを追加した場合、それはまだ有効なメモリ アドレスではありません (uint32 で有効であるため、 IntPtr では負の数で表されます)?!

コードは次のようにする必要があると思います。

public static IntPtr Offset(IntPtr src, int offset)
{
    switch (IntPtr.Size) {
    case 4:
        return new IntPtr((int)((uint)src + offset));
    case 8:
        return new IntPtr((long)((ulong)src + offset));
    default:
        throw new NotSupportedException("Not supported");
    }
}

私はクレイジーですか？

誰もが実証済みの真の IntPtr 追加の例を持っていますか?

4

3 に答える 3

1

.NET 4.0 では、新しい静的メソッド IntPtr.Add(IntPtr pointer, int offset) が追加されています。

以前の .NET バージョンでは、整数に変換する別の方法として、「安全でない」コード ブロックを使用し、IntPtr を (byte *) にキャストする方法があります。加算を実行し、結果を IntPtr に戻します。コンパイラーはポインター幅の詳細を処理します。:-)

例：

  new IntPtr((byte *)pipe.Root + EventNameOffset)

また：

  (IntPtr)((byte *)pipe.Root + EventNameOffset)
于 2010-04-22T16:03:34.313 に答える
0

追加する前に、IntPtr が にキャストされuint、次にオフセットが適用されます。これは正しく機能しますが、結果はlong.

私の知る限り、ulong と int の足し算はできないので、64bit ポインタの部分が間違っています。実際、コンパイルさえしません。エレガントな解決策は本当に考えられませんが、long代わりに a を使用するだけでおそらく安全です。これは、使用できるメモリの半分です*、8エクサバイトです:)メモリアドレスマッピングは、理論的には問題になる可能性があります。

*: まあ、現在の .NET Framework の実装が、もちろんそれよりずっと前にあなたの行動を止めないなら:)

于 2009-11-10T10:31:35.570 に答える