जो उपयोग करने के लिए बेहतर/सुरक्षित है: हैंडलरफ या इंटप्रेट (माइक्रोसॉफ्ट से नया स्रोत कोड अब हैंडलरफ का उपयोग नहीं करता है)

Question

उदाहरण के लिए, पुराने .NET Framework 2.0 स्रोत कोड (विंडोज फॉर्म, विजुअल स्टूडियो 2005 - व्हिडबे) में, (Microsoft से, 2009/2010) एक ही समारोह IntPtr का उपयोग कर परिभाषित किया गया है

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

नए विंडोज एपीआई कोड पैक में: GetClientRect समारोह HandleRef का उपयोग कर परिभाषित किया गया था

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

असल में हैंडलरफ किसी भी विंडोज एपीआई कोड पैक स्रोत फ़ाइलों में उपयोग नहीं किया जाता है, जबकि इसका उपयोग पुराने .NET Framework स्रोत फ़ाइलों में देशी विधियों के हस्ताक्षरों में भारी रूप से किया जाता था।

Answer 1

यह थोड़ा सा मछली है। एक हैंडलरफ व्युत्पन्न ऑब्जेक्ट में मानों को संभालते समय हैंडलरफ की आवश्यकता नहीं होती है। कौन सा कोड पैक घोषित करता है, ज़ीरोइनवाल्डहैंडल, जिसमें से कई व्युत्पन्न वाले लोगों को SafeWindowHandle की तरह बताया जाता है।

हालांकि, यह वास्तव में का उपयोग कहीं भी इन सेफ़हैंडल कक्षाओं में से किसी भी का उपयोग नहीं करता है। यह सुनिश्चित नहीं है कि वास्तव में यह है कि, वास्तव में बहुत सारे Vista और Win7 एक्सटेंशन वास्तव में COM इंटरफेस हैं। पारंपरिक हैंडल आधारित सी एपीआई नहीं है। उन्हें संदर्भ संख्याओं के माध्यम से जीवित रखा जाता है और इस प्रकार इस प्रकार के कचरा कलेक्टर दुर्घटना के अधीन नहीं होते हैं।

व्यक्तिगत रूप से मैं इस बारे में कभी चिंता नहीं करता हूं। क्लास ऑब्जेक्ट प्राप्त करना जबकि एपीआई कॉल निष्पादन एक बग है। यह एपीआई कॉल पूरा होने के बाद आसानी से माइक्रोसॉन्ड के साथ हो सकता है। अभी भी एक बग, केवल एक ऐसा नहीं जो एपीआई कॉल विफल करता है। इतना यकीन नहीं है कि मैं वास्तव में इसे असफल नहीं करना चाहता हूं, जब मुझे अपने कोड में एक बग मिला तो मैं अपवाद को बहुत पसंद करता। माइक्रोसॉफ्ट को इससे खुद को बचाने की जरूरत है, वे अपवाद के लिए दोष नहीं लेना चाहते हैं। मैं करता हूँ।

Answer 2

IntPtr केवल संरचना है जो पॉइंटर लपेटती है। हैंडलरफ एमएसडीएन says "हैंडलरफ के साथ एक हैंडल लपेटने की गारंटी है कि प्रबंधित ऑब्जेक्ट कचरा नहीं है जब तक प्लेटफॉर्म का आह्वान कॉल पूरा नहीं हो जाता।" पी/इनवॉक कॉल के बाद यदि आप इसके साथ कुछ भी नहीं करते हैं तो पी/इनवॉक के दौरान जीसी हैंडल को अंतिम रूप दे सकता है। तो हैंडलरफ अधिक सुरक्षित दिखता है।

Answer 3

मेरा अनुमान है कि नए कोड के नमूने केवल IntPtr का उपयोग करते हैं क्योंकि यह समझना आसान है।

.NET Framework में पाए गए विभिन्न NativeMethods कक्षाओं में फ़ंक्शन हस्ताक्षर पर प्रतिबिंब के माध्यम से एक त्वरित नज़र से पता चलता है कि वास्तविक उपयोग दोनों के बीच बहुत अच्छी तरह से विभाजित है।

मुझे लगता है कि यह ऑब्जेक्ट को कचरे से पहले कचरा होने से रोकने की आवश्यकता है या नहीं (primary advantageHandleRef का उपयोग करने के लिए) है। यह भी ध्यान रखें कि HandleRef का उपयोग करना अनावश्यक है जब तक कि आप जिस हैंडल को पारित कर रहे हैं वह प्रबंधित ऑब्जेक्ट है। अप्रबंधित वस्तुओं को कचरा नहीं मिलेगा।