哪个更好/更安全使用:HandleRef或IntPtr(来自Microsoft的较新源代码不再使用HandleRef)

Question

例如,在旧的.NET Framework 2.0源代码(Windows窗体,Visual Studio 2005 - Whidbey)中,使用HandleRef定义了GetClientRect函数:

    [DllImport(ExternDll.User32, ExactSpelling=true, CharSet=CharSet.Auto)]
    public static extern bool GetClientRect(HandleRef hWnd, [In, Out] ref NativeMethods.RECT rect); 

在新的Windows API代码包(来自Microsoft,2009/2010)中,使用IntPtr定义了相同的函数:

    [DllImport("user32.dll")]
    [return: MarshalAs(UnmanagedType.Bool)]
    internal static extern bool GetClientRect(IntPtr hwnd, ref CoreNativeMethods.RECT rect);

实际上,HandleRef不用于任何Windows API Code Pack源文件,而是在旧.NET Framework源文件中的本机方法签名中大量使用.

Answer 1

这有点可疑.当句柄值存储在SafeHandle派生对象中时,不需要HandleRef.代码包声明了ZeroInvalidHandle,其中包含几个派生的,如SafeWindowHandle.

但是,它实际上并没有在任何地方使用任何这些SafeHandle类.不确定它是否真的必须,很多Vista和Win7扩展实际上是COM接口.不是传统的基于句柄的C API.它们通过引用计数保持活跃,因此不会受到这种垃圾收集器事故的影响.

就个人而言,我从不担心这一点.获取收集类对象,而该API调用执行是一个错误.在API调用完成后,它可以轻松地发生一微秒.仍然是一个错误,只是没有一个使API调用失败的错误.不太确定我真的希望它不会失败,当我的代码中出现错误时,我更喜欢异常.微软需要保护自己免受此事的侵害,他们不想为这个例外负责.我做.

Answer 2

我的猜测是，使用较新的代码示例IntPtr仅仅是因为它更容易理解。

通过 Reflector 快速浏览一下 .NET Framework 中各个NativeMethods类中的函数签名，就会发现两者的实际用法相当不同。

我认为这是基于是否需要防止对象过早被垃圾收集（这是使用 的主要优点HandleRef）。另请记住，HandleRef除非您传递的句柄是托管对象，否则不需要使用。非托管对象不会被垃圾收集。