क्या यह समझ में आता है कि अगर कोई नल जाँच नहीं है, तो भी एक कलाकार के बजाय "के रूप में" का उपयोग करें? [बन्द है]

Question

विकास ब्लॉगों में, ऑनलाइन कोड उदाहरण और (हाल ही में) यहां तक ​​कि एक किताब, मैं इस तरह कोड के बारे में ठोकर खा रहा हूं:

var y = x as T;
y.SomeMethod();

या इससे भी बदतर:

(x as T).SomeMethod();

यह मेरे लिए कोई मतलब नहीं है। यदि आप सुनिश्चित हैं कि xयह प्रकार का है T, तो आपको प्रत्यक्ष कलाकारों का उपयोग करना चाहिए (T)x:। यदि आप निश्चित नहीं हैं, तो आप कुछ ऑपरेशन करने से पहले asजांच कर सकते हैं, लेकिन उपयोग कर सकते हैं null। उपरोक्त सभी कोड एक (उपयोगी) InvalidCastExceptionको एक (बेकार) में बदलना है NullReferenceException।

क्या मैं अकेला हूं जो यह सोचता है कि यह asकीवर्ड का एक अपमानजनक दुरुपयोग है ? या मुझे कुछ स्पष्ट याद आया और उपरोक्त पैटर्न वास्तव में समझ में आता है?

Comments

(एस के रूप में चुंबन) .SteveIsSuchA () को देखने के लिए मजेदार हो सकता है; लेकिन मैं सहमत हूं, इसका दुरुपयोग।

— स्वदेवमन 26१

यह लिखने की तुलना में बहुत अच्छा है ((T)x).SomeMethod(), है ना? ;) (सिर्फ मजाक कर रहे हैं, आप बिल्कुल सही हैं!)

— लुसेरो

@P डैडी मैं असहमत हूं, पूरी तरह से अच्छा सवाल (क्या यह कोड पैटर्न वास्तव में समझ में आता है), और बहुत उपयोगी है। प्रश्न के लिए +1 और बंद करने के लिए वोट करने वाले किसी भी व्यक्ति के लिए एक भ्रूभंग।

— MarkJ

ल्यूसर्नो सही है, यह कोडिंग पैटर्न कोष्ठक से बचने की कोशिश से प्रेरित है। लिस्प के संपर्क में आने के बाद लाइलाज।

— हंस पैसेंट

अनुकूलित कोड (f as T).SomeMethod():;)

— मसलक

Answer 1

आपकी समझ सच्ची है। ऐसा लगता है कि मुझे माइक्रो-ऑप्टिमाइज़ करने की कोशिश कर रहा है। जब आप टाइप के बारे में सुनिश्चित हों तो आपको एक सामान्य कास्ट का उपयोग करना चाहिए। अधिक समझदार अपवाद उत्पन्न करने के अलावा, यह तेजी से विफल भी होता है। यदि आप प्रकार के बारे में अपनी धारणा जा रहे गलत, अपने कार्यक्रम तुरंत विफल हो जाएगा और आप विफलता तुरंत बजाय इंतजार कर के कारण देखने के लिए एक के लिए सक्षम हो जाएगा NullReferenceExceptionया ArgumentNullExceptionया यहां तक कि एक तार्किक त्रुटि भविष्य में कुछ समय। सामान्य तौर पर, एक asअभिव्यक्ति जो एक nullचेक द्वारा पीछा नहीं किया जाता है वह एक कोड गंध है।

दूसरी ओर, यदि आप कलाकारों के बारे में निश्चित नहीं हैं और यह असफल होने की उम्मीद करते हैं, तो आपको ब्लॉक के asसाथ लिपटे सामान्य कलाकारों के बजाय उपयोग करना चाहिए try-catch। इसके अलावा, का उपयोग asएक प्रकार की जाँच से अधिक की सिफारिश की जाती है , उसके बाद कलाकारों द्वारा। के बजाय:

if (x is SomeType)
   ((SomeType)x).SomeMethod();

जो कीवर्ड के लिए एक isinstनिर्देश उत्पन्न करता है is, और कलाकारों के लिए एक castclassनिर्देश (प्रभावी रूप से कलाकारों को दो बार प्रदर्शन करता है), आपको उपयोग करना चाहिए:

var v = x as SomeType;
if (v != null)
    v.SomeMethod();

यह केवल एक isinstनिर्देश उत्पन्न करता है । पूर्व विधि में मल्टीथ्रेडेड एप्लिकेशन में संभावित खराबी है क्योंकि दौड़ की स्थिति के कारण चर isसफल हो सकता है और चेक लाइन के सफल होने के बाद इसका प्रकार बदल सकता है । उत्तरार्द्ध विधि इस त्रुटि के लिए प्रवण नहीं है।

---

_{उत्पादन कोड में उपयोग के लिए निम्नलिखित समाधान की सिफारिश नहीं की गई है। यदि आप वास्तव में C # में इस तरह के एक मौलिक निर्माण से नफरत करते हैं, तो आप VB या किसी अन्य भाषा पर स्विच करने पर विचार कर सकते हैं।}

यदि कोई जाति के सिंटैक्स से सख्त घृणा करता है, तो वह कलाकारों की नकल करने के लिए एक एक्सटेंशन विधि लिख सकता है:

public static T To<T>(this object o) { // Name it as you like: As, Cast, To, ...
    return (T)o;
}

और एक साफ [?] सिंटैक्स का उपयोग करें:

obj.To<SomeType>().SomeMethod()

Comments

मुझे लगता है कि दौड़ की स्थिति अप्रासंगिक है। यदि आप इस समस्या का सामना कर रहे हैं, तो आपका कोड थ्रेड-सुरक्षित नहीं है, और कीवर्ड "जैसे" का उपयोग करके इसे हल करने के अधिक विश्वसनीय तरीके हैं। शेष उत्तर के लिए +1।

— RMorrisey

@RMorrisey: मेरे पास कम से कम एक उदाहरण है: मान लें cacheकि आपके पास एक ऐसी वस्तु है जिसे किसी अन्य सूत्र ने इसे सेट करके अमान्य करने का प्रयास किया है null। लॉक-फ्री परिदृश्यों में, इन प्रकार के सामान उत्पन्न हो सकते हैं।

— मेहरदाद अफश्री

F + कास्ट FxCop से "अनावश्यक रूप से न डालें" चेतावनी को ट्रिगर करने के लिए पर्याप्त है: msdn.microsoft.com/en-us/library/ms182271.aspx जो निर्माण से बचने के लिए पर्याप्त कारण होना चाहिए।

— डेविड श्मिट

आपको विस्तार के तरीकों को बनाने से बचना चाहिए Object। मूल्य प्रकार पर विधि का उपयोग करने से यह अनावश्यक रूप से बॉक्सिंग हो जाएगा।

— MgSam

@MgSam जाहिर है, इस तरह के एक उपयोग के मामले का Toयहां विधि के लिए कोई मतलब नहीं है, क्योंकि यह केवल वंशानुक्रम पदानुक्रम में परिवर्तित होता है, जिसमें मूल्य प्रकारों के लिए वैसे भी मुक्केबाजी शामिल है। बेशक, पूरा विचार गंभीर से अधिक सैद्धांतिक है।

— मेहरदाद अफश्री

Answer 2

IMHO, asबस जब एक nullचेक के साथ संयुक्त अर्थ :

var y = x as T;
if (y != null)
    y.SomeMethod();

Answer 3

'के रूप में' का उपयोग उपयोगकर्ता परिभाषित रूपांतरणों पर लागू नहीं होता है, जबकि कास्ट उन्हें उपयुक्त का उपयोग करेगा। यह कुछ मामलों में एक महत्वपूर्ण अंतर हो सकता है।

Comments

यह याद रखना महत्वपूर्ण है। : एरिक Lippert है कि यहाँ के ऊपर जाता है blogs.msdn.com/ericlippert/archive/2009/10/08/...

— पी डैडी

अच्छी टिप्पणी, पी! यदि आपका कोड इस अंतर पर निर्भर करता है, हालांकि, मैं कहूंगा कि आपके भविष्य में देर रात डिबगिंग सत्र है।

— ट्रूविल

Answer 4

मैंने यहाँ इस बारे में थोड़ा लिखा:

http://blogs.msdn.com/ericlippert/archive/2009/10/08/what-s-the-difference-between-as-and-cast-operators.aspx

मैं आपकी बात समझता हूं। और मैं इसके जोर से सहमत हूं: कि एक कास्ट ऑपरेटर "मुझे यकीन है कि इस ऑब्जेक्ट को उस प्रकार में परिवर्तित किया जा सकता है, और मैं एक अपवाद को जोखिम में डालने के लिए तैयार हूं, अगर मैं गलत हूं", जबकि एक "ऑपरेटर" के रूप में संचार करता है "मुझे यकीन नहीं है कि इस वस्तु को उस प्रकार में परिवर्तित किया जा सकता है, अगर मैं गलत हूं तो मुझे एक अशक्त कर दें"।

हालाँकि, एक सूक्ष्म अंतर है। (x as T)। जो भी () संचार करता है "मुझे पता है कि x को केवल T में परिवर्तित नहीं किया जा सकता है, लेकिन इसके अलावा, ऐसा करने पर केवल संदर्भ या अनबॉक्सिंग रूपांतरण शामिल हैं, और इसके अलावा, वह x शून्य नहीं है"। यह ((T) x) की तुलना में विभिन्न सूचनाओं को संप्रेषित करता है।

Comments

मैं आपके अंतिम वाक्य में कोड के लेखक की आपकी सट्टा रक्षा से असहमत हूं। ((T)x).Whatever() यह भी संचार करता xहै कि [अशक्त होने का इरादा] नहीं है, और मुझे बहुत संदेह है कि एक लेखक आमतौर पर परवाह करेगा कि क्या रूपांतरण Tकेवल संदर्भ या अनबॉक्सिंग रूपांतरणों के साथ होता है, या यदि उसे उपयोगकर्ता-परिभाषित या प्रतिनिधित्व-बदलने वाले रूपांतरण की आवश्यकता होती है। आखिरकार, अगर मैं परिभाषित करता हूं public static explicit operator Foo(Bar b){}, तो यह स्पष्ट रूप से मेरी मंशा है Barजिसे संगत माना जाता है Foo। यह दुर्लभ है कि मैं इस रूपांतरण से बचना चाहूंगा।

— पी डैडी

खैर, शायद कोड के अधिकांश लेखक उस सूक्ष्म अंतर को नहीं बना रहे होंगे। मैं व्यक्तिगत रूप से हो सकता हूं, लेकिन अगर मैं था, तो मैं उस प्रभाव के लिए एक टिप्पणी जोड़ूंगा।

— एरिक लिपर्ट

Answer 5

मैंने अक्सर इस भ्रामक लेख के संदर्भों को सबूत के रूप में देखा है कि "जैसा कि" कास्टिंग की तुलना में तेज़ है।

इस लेख के अधिक स्पष्ट भ्रामक पहलुओं में से एक ग्राफिक है, जो इंगित नहीं करता है कि क्या मापा जा रहा है: मुझे संदेह है कि यह असफल जातियों को माप रहा है (जहां "जैसा कि" स्पष्ट रूप से बहुत तेज़ है क्योंकि कोई अपवाद नहीं फेंका गया है)।

यदि आप माप करने के लिए समय लेते हैं, तो आप देखेंगे कि कास्टिंग तब होती है, जब आप उम्मीद करते हैं, जब कास्ट सफल होता है , तो "जैसे" से अधिक तेजी से होगा।

मुझे संदेह है कि यह कास्ट के बजाय कीवर्ड के "कार्गो पंथ" के उपयोग का एक कारण हो सकता है।

Comments

लिंक के लिए धन्यवाद, यह बहुत दिलचस्प है। मैंने लेख को कैसे समझा, वह गैर-अपवाद मामले की तुलना करता है । फिर भी, .net 1.1 के लिए लेख लिखा गया था, और टिप्पणियाँ बताती हैं कि यह .net 2.0 में बदल गया है: प्रदर्शन अब लगभग बराबर है, उपसर्ग कास्ट थोड़ा तेज भी है।

— हेनजी

लेख का मतलब यह है कि वह गैर-अपवाद मामले की तुलना कर रहा है, लेकिन मैंने कुछ समय पहले कुछ परीक्षण किए थे और .NET 1.x के साथ भी अपने दावा किए गए परिणामों को पुन: पेश करने में सक्षम नहीं था। और चूंकि लेख बेंचमार्क चलाने के लिए उपयोग किए गए कोड प्रदान नहीं करता है, इसलिए यह कहना असंभव है कि इसकी तुलना क्या हो रही है।

— जो

"कार्गो पंथ" - एकदम सही। पूरी जानकारी के लिए "कार्गो कल्ट साइंस रिचर्ड फेनमैन" देखें।

— बॉब डेनी

Answer 6

डायरेक्ट कास्ट को asकीवर्ड से अधिक कोष्ठकों की एक जोड़ी की आवश्यकता होती है । तो यहां तक ​​कि जहां आप 100% सुनिश्चित हैं कि प्रकार क्या है, यह दृश्य अव्यवस्था को कम करता है।

हालांकि अपवाद वाली बात पर सहमत थे। लेकिन कम से कम मेरे लिए, बाद में asजांच के लिए फोड़ा का सबसे अधिक उपयोग होता है null, जो मुझे अपवाद को पकड़ने की तुलना में अच्छा लगता है।

Answer 7

99% उस समय जब मैं "as" का उपयोग करता हूं, जब मुझे यकीन नहीं होता कि वास्तविक वस्तु प्रकार क्या है

var x = obj as T;
if(x != null){
 //x was type T!
}

और मैं स्पष्ट कास्ट अपवादों को नहीं पकड़ना चाहता और न ही दो बार कास्ट करना चाहता हूं, "है" का उपयोग करके:

//I don't like this
if(obj is T){
  var x = (T)obj; 
}

Comments

आपने अभी के लिए उचित उपयोग के मामले का वर्णन किया है as। अन्य 1% क्या है?

— पी डैडी

एक टाइपो में? =) मेरा मतलब था कि ९९% मैं इस सटीक कोड स्निपेट का उपयोग करता हूं , जबकि कभी-कभी मैं "कॉल" के रूप में एक विधि कॉल या किसी अन्य स्थान पर उपयोग कर सकता हूं।

— मैक्स गैल्किन

D'oh, और यह कैसे दूसरे लोकप्रिय उत्तर की तुलना में कम उपयोगी है ???

— मैक्स गल्किन

+1 मैं सहमत हूं कि यह बाहर

— रूबिन फरास

Answer 8

यह सिर्फ इसलिए है क्योंकि लोग इसे जिस तरह से देखते हैं, वह बहुत पठनीय है।

इसका सामना करें: C- जैसी भाषाओं में कास्टिंग / रूपांतरण ऑपरेटर बहुत भयानक, पठनीयता-वार है। मुझे यह अच्छा लगेगा अगर C # को या तो जावास्क्रिप्ट सिंटैक्स अपनाया जाए:

object o = 1;
int i = int(o);

या एक toऑपरेटर को परिभाषित करें , की कास्टिंग बराबर as:

object o = 1;
int i = o to int;

Comments

बस आप जानते हैं, आपके द्वारा बताए गए जावास्क्रिप्ट सिंटैक्स को C ++ में भी अनुमति दी गई है।

— पी डैडी

@PDdy: हालांकि यह प्रत्यक्ष 100% संगत वैकल्पिक वाक्यविन्यास नहीं है और इसका उद्देश्य (ऑपरेटर एक्स बनाम रूपांतरण निर्माता) के रूप में नहीं है

— रूबेन बार्टेलिंक

मैं इसे dynamic_cast<>()(और समान) के C ++ सिंटैक्स का उपयोग करना पसंद करूंगा । आप कुछ बदसूरत कर रहे हैं, यह बदसूरत दिखना चाहिए।

— टॉम हॉल्टिन -

Answer 9

लोग asइसे बहुत पसंद करते हैं क्योंकि यह उन्हें अपवादों से सुरक्षित महसूस कराता है ... जैसे कि एक बॉक्स पर गारंटी। एक आदमी बॉक्स पर एक फैंसी गारंटी देता है क्योंकि वह चाहता है कि आप सभी गर्म और स्वादिष्ट महसूस करें। आपको लगता है कि आप रात में अपने तकिए के नीचे उस छोटे से बक्से को रख सकते हैं, गारंटी परी नीचे आ सकती है और एक चौथाई छोड़ सकती है, क्या मैं सही हूं?

विषय पर वापस ... प्रत्यक्ष डाली का उपयोग करते समय, एक अमान्य कास्ट अपवाद की संभावना है। इसलिए लोग asअपनी सभी कास्टिंग जरूरतों के लिए कंबल समाधान के रूप में आवेदन करते हैं क्योंकि as(खुद से) कभी भी अपवाद नहीं फेंकेंगे। लेकिन इसके बारे में मजेदार बात यह है कि आपने जो उदाहरण दिया है, (x as T).SomeMethod();आप एक अशक्त संदर्भ अपवाद के लिए एक अमान्य कास्ट अपवाद का व्यापार कर रहे हैं। जब आप अपवाद देखते हैं तो वास्तविक समस्या को रोकता है।

मैं आमतौर पर asबहुत ज्यादा उपयोग नहीं करता हूं । मैं isपरीक्षण को पसंद करता हूं क्योंकि मेरे कारण, यह अधिक पठनीय प्रतीत होता है और अधिक समझ में आता है फिर एक डाली की कोशिश कर रहा है और अशक्त की जाँच कर रहा है।

Comments

"मुझे लगता है कि परीक्षण है" - "है" के बाद एक कलाकार की तुलना में धीमी है "के रूप में" अशक्त के लिए एक परीक्षण द्वारा पीछा किया (बस "IDEDIA.ContainsKey" की तरह अनुक्रमणिका का उपयोग कर dereferencing द्वारा पीछा किया है "IDEDIA.TryGetValue की तुलना में धीमी है" ")। लेकिन अगर आपको यह अधिक पठनीय लगता है, तो इसमें कोई संदेह नहीं है कि अंतर शायद ही महत्वपूर्ण है।

— जो

मध्य भाग में महत्वपूर्ण कथन यह है कि लोग asकंबल समाधान के रूप में कैसे लागू होते हैं क्योंकि यह उन्हें सुरक्षित महसूस कराता है।

— बॉब

Answer 10

यह मेरे शीर्ष में से एक है ।

स्ट्रॉस्ट्रुप के डी एंड ई और / या कुछ ब्लॉग पोस्ट मैं अभी नहीं मिल सकता है एक toऑपरेटर की धारणा पर चर्चा करता है जो https://stackoverflow.com/users/73070/johannes-rossel (यानी, समान सिंटैक्स) के साथ asलेकिन DirectCastशब्दार्थ के साथ बनाए गए बिंदु को संबोधित करेगा। )।

इसका कारण यह नहीं किया गया है क्योंकि एक कलाकारों को दर्द का कारण होना चाहिए और बदसूरत होना चाहिए ताकि आप इसका उपयोग करने से दूर हो जाएं।

दया आती है कि 'चतुर' प्रोग्रामर (अक्सर पुस्तक लेखक (Juval Lowy IIRC)) asइस शैली में गाली देकर चारों ओर कदम बढ़ाते हैं (C ++ does not a offer as, संभवतः इस कारण से)।

यहां तक कि वीबी एक समान वाक्य रचना होने में अधिक निरंतरता है कि बलों आप एक चुनने के लिए TryCastया DirectCastऔर अपना मन बना !

Comments

+1। आप शायद DirectCast व्यवहार का मतलब था , वाक्यविन्यास नहीं ।

— हेनजी

@ हिनजी: ता के लिए +1। अच्छी बात। स्मार्टरेज़ बनने और semanticsइसके बजाय उपयोग करने का निर्णय लिया गया : पी

— रूबेन बार्टेलिंक

यह देखते हुए कि C # में C, C ++, या Java के साथ संगतता का कोई ढोंग नहीं है, मुझे लगता है कि यह उन भाषाओं से उधार ली गई कुछ चीजों में खुद को झाँक रहा है। यह "मैं जानता हूं कि यह एक एक्स है" से परे है, और "मुझे पता है कि यह एक्स नहीं है, लेकिन एक के रूप में प्रतिनिधित्व किया जा सकता है", "मुझे पता है कि यह एक्स नहीं है, और वास्तव में एक के रूप में प्रतिनिधित्व करने योग्य नहीं हो सकता है" , लेकिन मुझे एक एक्स वैसे भी दे दो। " मैं एक double-to-intकास्ट के लिए उपयोगिता देख सकता था जो असफल होता अगर doubleएक सटीक मूल्य का प्रतिनिधित्व नहीं करता जो एक में फिट हो सकता है Int32, लेकिन (int)-1.5उपज -1 होने पर बस बदसूरत है।

— सुपरकैट

@supercat हां, लेकिन भाषा डिज़ाइन आसान नहीं है, जैसा कि हम सभी जानते हैं - C # nullables में शामिल ट्रेडऑफ़ के सेट को देखें। एकमात्र ज्ञात मारक गहराई के संस्करणों में C # का नियमित रूप से पढ़ना है क्योंकि वे साथ आते हैं :) शुक्र है कि मैं इन दिनों एफ # की बारीकियों को समझने के लिए अधिक चिंतित हूं और यह इन मामलों के बहुत सारे के आसपास बहुत अधिक समझदार है।

— रूबेन बार्टलिंक

@RubenBartelink: मैं बिल्कुल स्पष्ट नहीं हूं कि अशक्त प्रकारों को हल करने के लिए कौन सी सटीक समस्याएं थीं, लेकिन मुझे लगता है कि ज्यादातर मामलों में यह MaybeValid<T>दो सार्वजनिक क्षेत्रों के साथ होने के लिए अच्छा होगा IsValidऔर Valueकौन सा कोड इसे फिट होने के साथ देख सकता है। जैसे कि अनुमति दी होगी MaybeValid<TValue> TryGetValue(TKey key) { var ret = default(MaybeValid<TValue>); ret.IsValid = dict.TryGetValue(key, out ret.Value); return ret; }। न केवल कि तुलना में कम से कम दो कॉपी संचालन को बचाने के लिए Nullable<T>, लेकिन यह भी किसी भी प्रकार T- सिर्फ कक्षाओं के साथ लायक हो सकता है ।

— सुपरकैट

Answer 11

मेरा मानना ​​है कि asकीवर्ड को dynamic_castC ++ से अधिक सुरुचिपूर्ण दिखने वाले संस्करण के रूप में सोचा जा सकता है ।

Comments

मैं कहूंगा कि C # में एक सीधे कास्ट dynamic_castC ++ की तरह है।

— पी डैडी

मुझे लगता है कि C # में स्ट्रेट कास्ट C ++ में static_cast के बराबर है।

— एंड्रयू गैरीसन 15

@ रूबेन बार्टेलिंक: यह केवल संकेत के साथ अशक्त देता है। संदर्भों के साथ, जिसे आपको संभव होने पर उपयोग करना चाहिए, यह फेंकता है std::bad_cast।

— पी डैडी

@Andrew Garrison: static_castकोई रनटाइम प्रकार की जाँच नहीं करता है। C # में इसके समान कोई कास्ट नहीं है।

— पी डैडी

अफसोस की बात है, मुझे नहीं पता था कि आप संदर्भों पर भी जातियों का उपयोग कर सकते हैं, जैसा कि मैंने केवल पॉइंटर्स पर उनका उपयोग किया है, लेकिन पी डैडी बिल्कुल सही हैं!

— एंड्रयू गैरीसन

Answer 12

यह संभवतः बिना किसी तकनीकी कारण के अधिक लोकप्रिय है, लेकिन सिर्फ इसलिए कि इसे पढ़ना और अधिक सहज ज्ञान युक्त है। (यह नहीं कहना कि सवाल का जवाब देने की कोशिश करना बेहतर है)

Answer 13

"जैसा" उपयोग करने का एक कारण:

T t = obj as T;
 //some other thread changes obj to another type...
if (t != null) action(t); //still works

इसके बजाय (बुरा कोड):

if (obj is T)
{
     //bang, some other thread changes obj to another type...
     action((T)obj); //InvalidCastException
}

Comments

अगर आपको रेस कॉंडिटन्स मिल गया है तो इस बदसूरत आप को बड़े मुद्दे मिल गए हैं (लेकिन दूसरों के साथ जाने के लिए इसके अच्छे नमूने पर सहमत हों +1

— Ruben Bartelink

-1 के रूप में यह एक गिरावट है। यदि अन्य थ्रेड्स ओबज के प्रकार को बदल सकते हैं, तो आपको अभी भी समस्याएं हैं। "// स्टिल वर्क" का दावा सही होने के लिए बहुत ही अनुचित है, क्योंकि T को T के लिए एक पॉइंटर के रूप में उपयोग किया जाएगा, लेकिन यह मेमोरी की ओर इशारा करता है जो अब T नहीं है। न तो कोई समाधान काम करेगा जब दूसरा थ्रेड का प्रकार बदलता है obj जबकि क्रिया (t) प्रगति पर है।

— स्टीफन सी। स्टील

@ स्टीफन सी। स्टील: आप काफी भ्रमित लग रहे हैं। का प्रकार बदलने से objबदल रहा है मतलब होगा objचर ही किसी अन्य वस्तु के लिए एक संदर्भ पकड़ करने के लिए। यह स्मृति की सामग्री को परिवर्तित नहीं करेगा, जिस पर मूल रूप से संदर्भित ऑब्जेक्ट रहता है obj। यह मूल ऑब्जेक्ट अपरिवर्तित रहेगा, और tचर अभी भी इसका संदर्भ रखेगा।

— पी डैडी

infoq.com/news/2010/01/CDS-Dictionary

— रूबेन बार्टेलिंक

@ पी डैडी - मुझे लगता है कि आप सही हैं, और मैं गलत था: यदि ओबीज टी ऑब्जेक्ट से टी 2 ऑब्जेक्ट पर पलटाव था, तो टी अभी भी पुराने टी ऑब्जेक्ट की ओर इशारा करेगा। चूँकि t अभी भी पुरानी वस्तु को संदर्भित करता है, इसलिए इसे कचरा एकत्र नहीं किया जा सकता है, इसलिए पुरानी T वस्तु मान्य रहेगी। मेरी दौड़ स्थिति डिटेक्टर सर्किट को C ++ पर प्रशिक्षित किया गया था, जहां डायनेमिक_कास्ट का उपयोग करने वाला समान कोड एक संभावित समस्या होगी।

— स्टीफन सी। स्टील