आप "यह" कीवर्ड का उपयोग कब करते हैं? [बन्द है]

Question

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

एक निर्माता में:

public Light(Vector v)
{
    this.dir = new Vector(v);
}

अन्यत्र

public void SomeMethod()
{
    Vector vec = new Vector();
    double d = (vec * vec) - (this.radius * this.radius);
}

Comments

जब आपको वास्तव this में MSDN की आवश्यकता होती है तो मुझे अच्छे उदाहरण मिलते हैं । कृपया इस लिंक का अनुसरण करें ... ;-)

— मैट

यदि आपको किसी और को समझना या अनुकूलित करना या फिर से लिखना है, तो अधिकतर खराब लिखा हुआ कोड आपको thisया किसी अन्य क्वालिफायर के लिए खुश होगा ताकि एक साधारण नज़र से आपको वेरिएबल का दायरा पता चले (विशेष रूप से लटके हुए क्लास क्वालिफायर कांस्टेंट के लिए) (उसी पैकेज या पदानुक्रम) या super/ baseक्वालीफायर)। और आमतौर पर उपयोग किए जाने वाले वाक्यविन्यास का उपयोग करना _fooऐसा नहीं लगता है कि खुद के लिए सुरुचिपूर्ण है। अंतर्मुखी के _लिए दबाव डालने में प्रवेश करने की तुलना में अधिक समय लगता है this। और क्यों परेशान हो! _यदि आप क्वालीफायर को भूल गए हैं, तो ग्रहण-ऑटो-फ़ॉर्मेटिंग फ़ंक्शंस की ज़रूरत नहीं है ।

— djmj

नीचे दिए गए उत्तरों और टिप्पणियों को पढ़ने के साथ-साथ MSDN प्रलेखन: docs.microsoft.com/en-us/prepret-versions/visualstudio/… को पढ़ने के बाद इस कीवर्ड पर जो 6 वर्षों में अद्यतन नहीं किया गया है, मैं सुझाव दूंगा कभी भी इस कीवर्ड का उपयोग न करें । यह व्यर्थ है। मानकों को एक ही नाम न बनाएं, यह भ्रामक और बेवकूफ है। तुम ऐसा क्यों करोगे? इसके अलावा, इस का उपयोग करने में उदाहरण पारित नहीं है , यह भी भ्रामक और बेवकूफ है।

— युष

Answer 1

C # में इस कीवर्ड के कई उपयोग हैं ।

1. समान नाम से छिपे सदस्यों को अर्हता प्राप्त करने के लिए
2. ऑब्जेक्ट को अन्य तरीकों के पैरामीटर के रूप में स्वयं पास करना
3. किसी वस्तु को स्वयं किसी विधि से लौटाना
4. अनुक्रमणिका घोषित करने के लिए
5. विस्तार विधियों की घोषणा करने के लिए
6. कंस्ट्रक्टरों के बीच मापदंडों को पारित करने के लिए
7. आंतरिक रूप से मूल्य प्रकार (संरचना) को पुन: असाइन करने के लिए ।
8. वर्तमान उदाहरण पर विस्तार विधि लागू करने के लिए
9. खुद को दूसरे प्रकार से डालने के लिए
10. उसी श्रेणी में परिभाषित बिल्डरों को श्रृंखलाबद्ध करने के लिए

एक ही नाम के दायरे में सदस्य और स्थानीय चर नहीं होने से आप पहले उपयोग से बच सकते हैं, उदाहरण के लिए सामान्य नामकरण परंपराओं का पालन करके और स्थानीय चर (भी ऊंट) से टकराने से बचने के लिए खेतों (ऊंट मामले) के बजाय संपत्तियों (पास्कल मामले) का उपयोग कर सकते हैं। मामला)। C # 3.0 फ़ील्ड में स्वतः-कार्यान्वित गुणों का उपयोग करके आसानी से गुणों में परिवर्तित किया जा सकता है ।

Comments

8. वर्तमान उदाहरण पर एक विस्तार विधि आह्वान करने के लिए ( this.Foo();काम करेंगे, लेकिन Foo()नहीं होगा)

— मार्क Gravell

इसके अलावा खुद को दूसरे प्रकार के लिए कास्ट करने के लिए, उदाहरण के लिए एक स्पष्ट रूप से कार्यान्वित विधि को बुलाया जाएगा ((ICollection<T>)this).Add(bla)।

— नवफाल

एक ही प्रकार में परिभाषित दूसरे कंस्ट्रक्टर को श्रृंखला निर्माण के लिए। public ClassName(...) : this(...)।

— लासे वी। कार्लसन जू

@ और यह रन टाइम पर प्रदर्शन को प्रभावित नहीं करेगा। यह मानते हुए कि कोई अस्पष्टता नहीं है, संकलक का आउटपुट समान है चाहे आप लिखें, उदाहरण के लिए this.someField = someValueया someField = someValue। यह संकलक के प्रदर्शन को प्रभावित कर सकता है, क्योंकि संकलक स्रोत कोड को अलग तरीके से पार्स करेगा, लेकिन कोई भी अंतर निश्चित रूप से नगण्य होगा।

— फोग

आप गुणों के माध्यम से फ़ील्ड्स तक पहुंचकर पहले मुद्दे से बच सकते हैं, यदि आप एक शैली सम्मेलन का पालन करते हैं, जिसमें गुणों के पैरामीटर के समान नाम नहीं हो सकते। यह सिर्फ इसलिए होता है कि प्रचलित C # शैली सम्मेलन उस आवश्यकता को पूरा करता है। हालाँकि सभी सी # उस सम्मेलन के तहत नहीं लिखे गए हैं। प्रति से अधिक गुणों के बारे में कुछ भी अंतर्निहित नहीं है जो thisकीवर्ड को अनावश्यक बना देगा ; एक निर्माण पैरामीटर कहा जाता है xएक सदस्य को छिपाएगा xकि क्या सदस्य उस क्षेत्र के लिए एक क्षेत्र, एक संपत्ति या एक घटना है।

— फोज

Answer 2

मैं इस कर्कश ध्वनि के लिए मतलब नहीं है, लेकिन यह कोई फर्क नहीं पड़ता।

गंभीरता से।

उन चीजों को देखें जो महत्वपूर्ण हैं: आपकी परियोजना, आपका कोड, आपकी नौकरी, आपका व्यक्तिगत जीवन। उनमें से कोई भी अपनी सफलता बाकी नहीं है, चाहे आप "इस" कीवर्ड का उपयोग खेतों तक पहुंच प्राप्त करने के लिए करें या नहीं। यह कीवर्ड समय पर जहाज चलाने में आपकी मदद नहीं करेगा। यह बग को कम करने वाला नहीं है, यह कोड की गुणवत्ता या रखरखाव पर कोई सराहनीय प्रभाव नहीं रखने वाला है। यह आपको बढ़ाने नहीं जा रहा है, या आपको कार्यालय में कम समय बिताने की अनुमति देता है।

यह वास्तव में सिर्फ एक शैली का मुद्दा है। यदि आपको "यह" पसंद है, तो इसका उपयोग करें। यदि आप नहीं करते हैं, तो नहीं। अगर आपको सही शब्दार्थ प्राप्त करने की आवश्यकता है तो इसका उपयोग करें। सच तो यह है, हर प्रोग्रामर की अपनी अलग प्रोग्रामिंग स्टाइल होती है। यह शैली उस विशेष प्रोग्रामर की धारणाओं को दर्शाती है कि "सबसे सौंदर्यवादी रूप से सुखदायक कोड" कैसा दिखना चाहिए। परिभाषा के अनुसार, आपके कोड को पढ़ने वाले किसी भी अन्य प्रोग्रामर के पास एक अलग प्रोग्रामिंग शैली होने वाली है। इसका मतलब है कि हमेशा कुछ ऐसा होता है जो आपने किया है कि दूसरे व्यक्ति को पसंद नहीं है, या अलग तरीके से किया जाएगा। कुछ बिंदु पर कुछ आदमी आपके कोड को पढ़ने जा रहे हैं और कुछ के बारे में बड़बड़ा रहे हैं।

मैं इस पर झल्लाहट नहीं करेगा। मैं बस यह सुनिश्चित करूंगा कि कोड आपके अपने स्वाद के अनुसार सौंदर्यशास्त्रीय रूप से मनभावन हो। यदि आप 10 प्रोग्रामर से पूछते हैं कि कोड को प्रारूपित कैसे किया जाता है, तो आपको लगभग 15 अलग-अलग राय मिलने वाली हैं। एक बेहतर बात यह है कि कैसे कोड फैक्टर किया जाए। क्या चीजें सही हैं? क्या मैंने चीजों के लिए सार्थक नाम चुने? क्या बहुत सारे कोड दोहराव है? क्या ऐसे तरीके हैं जिनसे मैं सामान को सरल बना सकता हूं? उन बातों को सही मानने से, मुझे लगता है कि आपकी परियोजना, आपके कोड, आपकी नौकरी और आपके जीवन पर सबसे बड़ा सकारात्मक प्रभाव पड़ेगा। संयोग से, यह शायद दूसरे आदमी को कम से कम गड़बड़ी करने का कारण बनेगा। यदि आपका कोड काम करता है, तो पढ़ना आसान है, और अच्छी तरह से फैक्टर किया गया है, दूसरे व्यक्ति को यह पता नहीं चल रहा है कि आप खेतों को कैसे शुरू करते हैं। वह आपके कोड का उपयोग करने जा रहा है, यह बहुत अच्छा है,

Comments

thisकीवर्ड शब्दार्थ सार्थक है। नीचे देखें @ जेसनबंटिंग की टिप्पणी। आप thisइसके वास्तविक उद्देश्य के साथ शैलीगत अति प्रयोग को भ्रमित करते हैं । आपकी टिप्पणी सिर्फ स्पष्ट नहीं है, यह गलत है!

— दान बैरो

यदि आपको मौका मिलता है, तो आप मेरे उत्तर को फिर से पढ़ना चाहेंगे। मैं उन मामलों में इसका उपयोग करने के बारे में बात करता हूं जहां यह सही शब्दार्थ के लिए आवश्यक है। आप मूल प्रश्न को भी देखना चाह सकते हैं। यह उन उदाहरणों में उपयोग दिखा रहा है जहाँ यह शब्दार्थ से आवश्यक नहीं है। इसलिए, मुझे यकीन नहीं है कि मैंने जो कहा वह "गलत" था। मेरा जवाब निश्चित रूप से नहीं है।

— स्कॉट विस्न्यूस्की

क्या आप जानते हैं कि आपका जवाब मुझे कैसा लगता है? लाइनों के बीच मैंने पढ़ा "आप इस तरह एक प्रश्न पूछने की हिम्मत कैसे करते हैं?" - यह वास्तव में मेरी राय में रचनात्मक नहीं है। किसी को भी सब कुछ नहीं पता है - यही कारण है कि हमारे पास स्टैकओवरफ्लो है: दूसरों की मदद करने और मदद पाने के लिए। कुछ विषय जिन्हें आप जानते हैं, कुछ अन्य जानते हैं। एक-दूसरे की मदद करें, एक-दूसरे से लड़ें नहीं। कृपया इसके बारे में सोंचे।

— मैट

मैं कर्कश ध्वनि करने के लिए मतलब नहीं है, लेकिन यह अब तक के सबसे खराब उत्तरों में से एक है। मैं यह नहीं देखता कि आपकी नौकरी या व्यक्तिगत जीवन से इसकी तुलना कैसे उपयोगी है। सिर्फ इसलिए कि कुछ चीजें दूसरों की तुलना में कम महत्वपूर्ण हैं इसका मतलब यह नहीं है कि वे महत्वहीन हैं । एक सुसंगत प्रोग्रामिंग शैली होना महत्वहीन नहीं है (अपनी पसंद की कोड पठनीयता / स्थिरता पर एक पुस्तक पढ़ें)।

— aioobe

मुझे लगता है कि आपने मेरी बात को गलत समझा होगा। ऐसा नहीं था कि "एक सुसंगत शैली" होना बुरा है। मैं उस प्रभाव को कुछ नहीं कहता। ऐसा लगता है कि "मेरी शैली को जनादेश चाहिए 'का ऑप सवाल है।" सभी फ़ील्ड एक्सेस के लिए उपसर्ग के रूप में? " मनमाना और डरावना है।

— स्कॉट विस्न्यूस्की

Answer 3

मैं केवल इसका उपयोग तब करता हूं जब बिल्कुल आवश्यक हो, अर्थात, जब एक और चर दूसरे को छाया दे रहा हो। जैसे यहाँ:

class Vector3
{
    float x;
    float y;
    float z;

    public Vector3(float x, float y, float z)
    {
        this.x = x;
        this.y = y;
        this.z = z;
    }

}

या जब रयान फॉक्स इंगित करता है, जब आपको इसे एक पैरामीटर के रूप में पारित करने की आवश्यकता होती है। (सदस्य चर पर स्थानीय चर की पूर्वता है)

Comments

इस मामले में, बस निर्माता के इनपुट चर को अलग-अलग नाम क्यों न दें?

— wz366

Answer 4

व्यक्तिगत रूप से, मैं हमेशा उपयोग करने का प्रयास इस जब सदस्य चर का जिक्र है। यह कोड को स्पष्ट करने और इसे अधिक पठनीय बनाने में मदद करता है। यहां तक ​​कि अगर कोई अस्पष्टता नहीं है, तो पहली बार मेरे कोड के माध्यम से पढ़ने वाले किसी व्यक्ति को यह पता नहीं है, लेकिन अगर वे इसे लगातार उपयोग करते हैं, तो उन्हें पता चलेगा कि वे किसी सदस्य चर को देख रहे हैं या नहीं।

Comments

लेकिन अगर आप इसे कुछ समय के लिए इस्तेमाल करना भूल जाते हैं, तो वे भ्रमित हो जाएंगे

— सर्फ

@surfen जिसे अतिरिक्त स्टाइल जांच से बचा जा सकता है, उदाहरण के लिए जावा में आप चेकस्टाइल का उपयोग कर सकते हैं और इसे पूर्ण निर्माण के बाद चला सकते हैं (और किसी भी लोकप्रिय पुनरावृत्ति / OO भाषा में समान उपकरण होंगे)

— Maarten Bodewes

@surfen जैसे कि आप इसे अस्पष्ट मामलों में भूल जाते हैं। मैं "लेकिन अगर तुम भूल जाओ ..." कहकर किसी भी तर्क को तोड़ सकते हैं।

— आस्कोलिन

ज़्यादातर लोगों को लगता है कि वे कभी नहीं पढ़ेंगे, किसी और के कोड को ऑप्टिमाइज़ या रीराइट करेंगे! क्वालिफायर समय और प्रेरणा सेवर हैं! क्वालीफायर के बिना इसके जादू की तरह अगर आप कोड की कोई भी मनमानी लाइन देखते हैं। तो आप हर समय सिर्फ चेकइन बर्बाद करते हैं जहां ये चर आते हैं।

— djmj

मुझे पता है कि यह बहुत पुरानी पोस्ट है, लेकिन इस जवाब की विडंबना पर टिप्पणी करने में मदद नहीं कर सकता (लेकिन मैं इससे सहमत हूं)। बुराई हंगेरियन संकेतन के खिलाफ जिहाद में, जो कोई भी "m_" के साथ अपने सदस्य चर को उपसर्ग करने की हिम्मत करता था, उसे जल्दी से गोली मार दी गई थी क्योंकि सदस्य चर को भेद करना उपयोगी या आवश्यक नहीं था।

— माइकल जे।

Answer 5

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

Comments

मैं वर्ग चर को जितना अलग कर सकता हूं, उतना अलग करना चाहता हूं, इसलिए कोड अधिक स्पष्ट है। मैं उपसर्ग m_ (सदस्य चर) उदा निजी स्ट्रिंग m_name का उपयोग करता था। अगर मैं कक्षा टेस्ट {प्राइवेट स्ट्रिंग ए; public someMethod () {this.a = "foo"; }}

— ब्रॉडबैंड

Answer 6

मैं उन सभी लोगों पर विश्वास नहीं कर सकता जो कहते हैं कि इसका उपयोग करना हमेशा एक "सर्वोत्तम अभ्यास" और ऐसा होता है।

"इस" का उपयोग करें जब अस्पष्टता हो, जैसा कि कोरी के उदाहरण में या जब आपको ऑब्जेक्ट को एक पैरामीटर के रूप में पारित करने की आवश्यकता होती है, जैसा कि रेयान के उदाहरण में है । अन्यथा इसका उपयोग करने का कोई कारण नहीं है क्योंकि गुंजाइश श्रृंखला के आधार पर एक चर को हल करने में सक्षम होने के कारण पर्याप्त स्पष्ट होना चाहिए कि इसके साथ योग्य चर अनावश्यक होना चाहिए।

संपादित करें: "यह" पर C # प्रलेखन एक और उपयोग को इंगित करता है, इसके अलावा दो मैंने उल्लेख किया है, "यह" कीवर्ड के लिए - इंडेक्स घोषित करने के लिए

संपादित करें: @ जुआन: हुह, मुझे अपने बयानों में कोई असंगतता नहीं दिखती है - ऐसे 3 उदाहरण हैं जब मैं "इस" कीवर्ड का उपयोग करूंगा (जैसा कि सी # प्रलेखन में लिखा गया है), और वे ऐसे समय होते हैं जब आपको वास्तव में इसकी आवश्यकता होती है। एक कंस्ट्रक्टर में वेरिएबल्स के सामने "यह" चिपके रहना जब कोई शैडोइंग नहीं हो रही हो तो बस कीस्ट्रोक्स की बर्बादी होती है और इसे पढ़ते समय मेरा समय बर्बाद होता है, इससे कोई फायदा नहीं होता है।

Comments

@ जेसनबंटिंग : आप कभी-कभी कुछ नहीं कर सकते हैं और कुछ अन्य नहीं ... यह भ्रमित करने वाला है ... मुझे आशा है कि मैं आपके कोड में कभी काम नहीं करूंगा। आप हमेशा यह नहीं मान सकते कि कोई व्यक्ति जो भविष्य में आपके कोड को पढ़ता है वह आपको समझ जाएगा लिखा है, आपको जितना संभव हो उतना स्पष्ट होने की आवश्यकता है, और इसे प्राप्त करने का एक तरीका सुसंगत होना है

— जुआन

@ जुआन, 10 साल बाद। आप अभी भी सोचते हैं कि "यह" अच्छा अभ्यास है? :)

— स्कॉट एडम्स

मैं अभी भी, हाँ स्थिरता और स्पष्टता में विश्वास करते हैं @ScottAdams

— Juan

एक चर (चाहे वह स्थानीय हो या सदस्य चर) का दायरा निर्धारित करने के बारे में सिर्फ उसे देखकर क्या होगा? क्या इस उद्देश्य के लिए 'यह' उचित नहीं है? या आपके कहने का मतलब है कि अगर हम छोटे तरीकों को लिखते हैं तो यह काफी आसान हो सकता है कि वैसे भी चर के दायरे को समझ सकें?

— बॉर्नटूकोड

Answer 7

जब भी StyleCop मुझसे कहता है मैं इसका उपयोग करता हूं । स्टाइलकॉप का पालन करना चाहिए। अरे हाँ।

Comments

और ReSharper मुझे इसका उपयोग नहीं करने के लिए कहता है। जब मैं एक ही समय में StyleCop और ReSharper दोनों का उपयोग कर रहा हूं, तो भ्रमित करने की तरह :) लेकिन मैं ऊपर कोर का जवाब देता हूं, केवल 'आवश्यक' इस 'कीवर्ड' का उपयोग करने के लिए।

— गुन्नार

@Gunnar, बेमानी से छुटकारा पाने का एक विकल्प है "यह।" आर में #

— विंगर सेंटन

@EmipleAiman ​​- हां, मुझे पता है। मेरा कहना था कि दो लोकप्रिय स्वरूपण उपकरण डिफ़ॉल्ट रूप से हैं, दो अलग-अलग चीजों का सुझाव देते हैं और यह भ्रमित हो सकता है। "होना या न होना ..." :)

— गुन्नर

Answer 8

किसी भी समय आपको वर्तमान वस्तु के संदर्भ की आवश्यकता होती है।

एक विशेष रूप से उपयोगी परिदृश्य तब होता है जब आपकी वस्तु किसी फ़ंक्शन को कॉल कर रही है और उसमें खुद को पास करना चाहती है।

उदाहरण:

void onChange()
{
    screen.draw(this);
}

Answer 9

मैं इसका उपयोग हर जगह भी करता हूं, बस यह सुनिश्चित करने के लिए कि यह स्पष्ट है कि यह उदाहरण के सदस्य हैं जिनसे हम निपट रहे हैं।

Answer 10

मैं इसका इस्तेमाल कहीं भी कर सकता हूँ अस्पष्टता (स्पष्ट रूप से) हो सकती है। न केवल संकलक अस्पष्टता (उस मामले में इसकी आवश्यकता होगी), बल्कि कोड को देखने वाले किसी व्यक्ति के लिए अस्पष्टता भी।

Answer 11

इस कीवर्ड के लिए एक और दुर्लभ उपयोग है, जब आपको कार्यान्वयन वर्ग के भीतर से एक स्पष्ट इंटरफ़ेस कार्यान्वयन को लागू करने की आवश्यकता होती है। यहाँ एक उदाहरण दिया गया है:

class Example : ICloneable
{
    private void CallClone()
    {
        object clone = ((ICloneable)this).Clone();
    }

    object ICloneable.Clone()
    {
        throw new NotImplementedException();
    }
}

Answer 12

जब मैं इसका उपयोग कर रहा हूँ:

• कक्षा के भीतर से निजी तरीकों तक पहुंच (अंतर करने के लिए)
• वर्तमान ऑब्जेक्ट को किसी अन्य विधि (या किसी ईवेंट के मामले में एक प्रेषक ऑब्जेक्ट के रूप में) पास करना
• विस्तार विधियाँ बनाते समय: डी

मैं निजी क्षेत्रों के लिए इसका उपयोग नहीं करता क्योंकि मैं एक अंडरस्कोर (_) के साथ निजी क्षेत्र चर नामों को उपसर्ग करता हूं।

Answer 13

[C ++]

मैं "इसका उपयोग तब करता हूं जब आपको ब्रिगेड" से सहमत होना पड़ता है। साथ अनावश्यक रूप से कोड सजा यह एक बहुत अच्छा विचार है क्योंकि संकलक आपको चेतावनी नहीं होगा जब आप यह करने के लिए भूल नहीं है। उम्मीद लोगों के लिए यह द्वारा प्रस्तुत संभावित भ्रम यह हमेशा वहाँ हो सकता है, यानी वे करना होगा लगता है इसके बारे में।

तो, आप इसका इस्तेमाल कब करेंगे? मैंने बस कुछ यादृच्छिक कोड के चारों ओर एक नज़र रखी है और इन उदाहरणों को पाया है (मैं इस पर निर्णय नहीं दे रहा हूं कि ये करने के लिए अच्छी चीजें हैं या अन्यथा):

• एक समारोह में "अपने आप" पास करना।
• "अपने आप को" एक सूचक या ऐसा कुछ सौंपना।
• कास्टिंग, यानी अप / डाउन कास्टिंग (सुरक्षित या अन्यथा), कास्टिंग से दूर रहना, आदि।
• संकलक ने संवितरण को लागू किया।

Answer 14

आपको हमेशा इसका उपयोग करना चाहिए, मैं इसे निजी क्षेत्रों और मापदंडों में अंतर करने के लिए उपयोग करता हूं (क्योंकि हमारे नामकरण परंपराएं बताती हैं कि हम सदस्य और पैरामीटर नामों के लिए उपसर्ग का उपयोग नहीं करते हैं (और वे इंटरनेट पर मिली जानकारी पर आधारित हैं, इसलिए मुझे लगता है कि एक प्रकार है) सर्वश्रेष्ठ प्रणालियां))

Answer 15

मैं इसका उपयोग तब करता हूं, जब एक फ़ंक्शन में जो एक ही प्रकार के ऑब्जेक्ट के संदर्भ को स्वीकार करता है, मैं इसे पूरी तरह से स्पष्ट करना चाहता हूं कि मैं किस ऑब्जेक्ट का उल्लेख कर रहा हूं, जहां।

उदाहरण के लिए

class AABB
{
  // ... members
  bool intersects( AABB other )
  {
    return other.left() < this->right() &&
           this->left() < other.right() &&

           // +y increases going down
           other.top() < this->bottom() &&
           this->top() < other.bottom() ;
  }
} ;

(बनाम)

class AABB
{
  bool intersects( AABB other )
  {
    return other.left() < right() &&
           left() < other.right() &&

           // +y increases going down
           other.top() < bottom() &&
           top() < other.bottom() ;
  }
} ;

AABB को किस नज़र right()से देखते हैं? thisएक विशुद्धक का एक सा कहते हैं।

Answer 16

जकूब Jakturc के उत्तर में उनके # 5 के बारे में संदूषण के बीच डेटा पारित करना शायद थोड़ा स्पष्टीकरण का उपयोग कर सकता है। यह ओवरलोडिंग कंस्ट्रक्टर्स में है और यह एक ऐसा मामला है जहां उपयोग thisअनिवार्य है। निम्नलिखित उदाहरण में हम पैरामीटर पैरामीटर को डिफ़ॉल्ट पैरामीटर के साथ पैरामीटर रहित निर्माता से कॉल कर सकते हैं।

class MyClass {
    private int _x
    public MyClass() : this(5) {}
    public MyClass(int v) { _x = v;}
}

मैंने इसे अवसर पर विशेष रूप से उपयोगी सुविधा पाया है।

Answer 17

मुझे यह दृश्य C ++ में उदारतापूर्वक उपयोग करने की आदत है क्योंकि ऐसा करने से IntelliSense मुझे '' '' कुंजी से टकराएगा, और मैं आलसी हूं। (और टाइपो के लिए प्रवण)

लेकिन मैंने इसका उपयोग करना जारी रखा है, क्योंकि मुझे यह देखना आसान है कि मैं एक वैश्विक फ़ंक्शन के बजाय एक सदस्य फ़ंक्शन को कॉल कर रहा हूं।

Answer 18

मैं _ के साथ खेतों को रेखांकित करता हूं, इसलिए वास्तव में कभी भी इसका उपयोग करने की आवश्यकता नहीं है। इसके अलावा आर # उन्हें वैसे भी दूर करने के लिए जाता है ...

Answer 19

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

Answer 20

मैं केवल इसका उपयोग तब करता हूं जब आवश्यक हो, सिवाय इसके सममित संचालन को छोड़कर जो एकल तर्क के कारण बहुरूपता को एक बार के तरीकों में डालना पड़ता है:

boolean sameValue (SomeNum other) {
   return this.importantValue == other.importantValue;
} 

Answer 21

[C ++]

इस असाइनमेंट ऑपरेटर में प्रयोग किया जाता है, जहां बार जब आप की जाँच करें और जैसे (, अनजाने में खतरनाक, या कार्यक्रम के लिए समय की सिर्फ एक अपशिष्ट) अजीब रोकने बातें करने के लिए है के सबसे:

A a;
a = a;

आपका असाइनमेंट ऑपरेटर लिखा जाएगा:

A& A::operator=(const A& a) {
    if (this == &a) return *this;

    // we know both sides of the = operator are different, do something...

    return *this;
}

Answer 22

this C ++ कंपाइलर पर

C ++ कंपाइलर एक प्रतीक के लिए चुपचाप खोजेगा यदि यह तुरंत नहीं मिलता है। कभी-कभी, ज्यादातर समय अच्छा होता है:

• यदि आपने इसे चाइल्ड क्लास में ओवरलोड नहीं किया है तो मदर क्लास की विधि का उपयोग करें।
• एक प्रकार के मूल्य को दूसरे प्रकार में बढ़ावा देना

लेकिन कभी-कभी, आप सिर्फ अनुमान लगाने वाले को नहीं चाहते हैं। आप चाहते हैं कि कंपाइलर सही सिंबल उठाए और दूसरा नहीं।

मेरे लिए , वे समय होते हैं, जब किसी विधि के भीतर, मैं किसी सदस्य विधि या सदस्य चर पर पहुंचना चाहता हूं। मैं सिर्फ इसलिए नहीं चाहता कि कुछ यादृच्छिक प्रतीक सिर्फ इसलिए उठाए गए क्योंकि मैंने printfइसके बजाय लिखा था print। this->printfसंकलित नहीं होता।

मुद्दा यह है कि, सी लीगेसी लाइब्रेरी (,) के साथ, वर्षों पहले लिखित विरासत कोड (§§), या जो भी भाषा में हो सकता है जहां कॉपी / पेस्ट करना एक अप्रचलित लेकिन फिर भी सक्रिय सुविधा है, कभी-कभी, संकलक को नहीं खेलने के लिए कह रहा है। बुद्धि एक महान विचार है।

ये मेरे द्वारा उपयोग किए जाने वाले कारण हैं this।

(Still) यह अभी भी मेरे लिए एक तरह का रहस्य है, लेकिन मुझे अब आश्चर्य होता है कि क्या आप अपने स्रोत में <windows.h> शीर्ष लेख को शामिल करते हैं, यही कारण है कि सभी विरासत सी पुस्तकालयों के प्रतीक आपके वैश्विक नामों को प्रदूषित करेंगे।

(A) यह महसूस करते हुए कि "आपको एक हेडर शामिल करने की आवश्यकता है, लेकिन इस हेडर सहित आपका कोड टूट जाएगा क्योंकि यह एक सामान्य नाम के साथ कुछ डंबल मैक्रो का उपयोग करता है" कोडर के जीवन के उन रूसी रूलेट क्षणों में से एक है

Answer 23

'यह।' बहुत सारे सदस्यों के साथ 'यह' वर्ग पर सदस्यों को खोजने में मदद करता है (आमतौर पर एक गहरी विरासत श्रृंखला के कारण)।

CTRL + Space को हिट करना इस में मदद नहीं करता है, क्योंकि इसमें प्रकार भी शामिल हैं; जहाँ-जहाँ 'यह।' केवल सदस्य शामिल हैं।

मैं आमतौर पर इसे हटा देता हूं एक बार मेरे पास वह है जो मैं था: लेकिन यह सिर्फ मेरी शैली को तोड़ रहा है।

शैली के संदर्भ में, यदि आप एक अकेला-रेंजर हैं - आप तय करते हैं; यदि आप किसी कंपनी की कंपनी की नीति पर काम करते हैं (स्रोत नियंत्रण में सामान देखें और देखें कि अन्य लोग क्या कर रहे हैं)। सदस्यों को अर्हता प्राप्त करने के लिए इसका उपयोग करने के संदर्भ में, न तो सही है या गलत है। केवल गलत चीज असंगति है - यही शैली का सुनहरा नियम है। निति-त्याग करने वाले को छोड़ दें। इसके बजाय वास्तविक कोडिंग समस्याओं को सुलझाने में अपना समय व्यतीत करें - और स्पष्ट रूप से कोडिंग - बजाय।

Answer 24

मैं हर बार इसका उपयोग कर सकता हूं। मेरा मानना ​​है कि यह कोड को अधिक पठनीय बनाता है, और अधिक पठनीय कोड कम बग और अधिक रखरखाव के बराबर होता है।

Answer 25

जब आप एक ही कोड आधार पर काम कर रहे कई डेवलपर होते हैं, तो आपको कुछ कोड दिशानिर्देशों / नियमों की आवश्यकता होती है। जहां मैं काम करता हूं वहां हम खेतों, संपत्तियों और घटनाओं पर 'इस' का उपयोग करने के इच्छुक हैं।

मेरे लिए यह इस तरह से करने के लिए अच्छा समझ में आता है, जब आप कक्षा-चर और विधि-चर के बीच अंतर करते हैं तो यह कोड को पढ़ना आसान बनाता है।

Answer 26

यह उस कोडिंग मानक पर निर्भर करता है जिसके तहत मैं काम कर रहा हूं। यदि हम एक उदाहरण चर को दर्शाने के लिए _ का उपयोग कर रहे हैं तो "यह" निरर्थक हो जाता है। अगर हम _ का उपयोग नहीं कर रहे हैं, तो मैं इसका उपयोग उदाहरण चर को दर्शाने के लिए करता हूं।

Answer 27

मैं इसका इस्तेमाल आह्वान करने के लिए Intellisense जैसे JohnMcG , लेकिन मैं वापस जाकर मिटा देंगे "इस->" जब मेरा कार्य पूर्ण हो। मैं "m_" के साथ सदस्य चर को उपसर्ग करने के Microsoft सम्मेलन का पालन करता हूं, इसलिए इसे दस्तावेज़ीकरण के रूप में छोड़ देना सिर्फ बेमानी होगा।

Answer 28

1 - सामान्य जावा सेटर मुहावरे:

 public void setFoo(int foo) {
     this.foo = foo;
 }

2 - जब एक पैरामीटर के रूप में इस ऑब्जेक्ट के साथ एक फ़ंक्शन कॉल करना

notifier.addListener(this);

Answer 29

एक उपयोग है जो पहले से ही सी ++ में उल्लेख नहीं किया गया है, और वह स्वयं की वस्तु को संदर्भित नहीं करना है या किसी प्राप्त चर से एक सदस्य की अवहेलना करना है।

आप thisएक गैर-निर्भर नाम को एक तर्क पर निर्भर नाम में परिवर्तित करने के लिए उपयोग कर सकते हैं, जो कि अन्य वर्गों से प्राप्त होने वाले टेम्पलेट वर्गों के अंदर है।

template <typename T>
struct base {
   void f() {}
};

template <typename T>
struct derived : public base<T>
{
   void test() {
      //f(); // [1] error
      base<T>::f(); // quite verbose if there is more than one argument, but valid
      this->f(); // f is now an argument dependent symbol
   }
}

टेम्पलेट्स को दो पास तंत्र के साथ संकलित किया जाता है। पहले पास के दौरान, केवल गैर-तर्क पर निर्भर नाम हल किए जाते हैं और जांचे जाते हैं, जबकि आश्रित नाम केवल सुसंगतता के लिए जांचे जाते हैं, वास्तव में टेम्पलेट तर्कों को प्रतिस्थापित किए बिना।

उस चरण में, वास्तव में प्रकार को प्रतिस्थापित किए बिना, कंपाइलर को लगभग कोई जानकारी नहीं है कि क्या base<T>हो सकता है (ध्यान दें कि आधार टेम्पलेट की विशेषज्ञता इसे पूरी तरह से अलग प्रकारों, यहां तक ​​कि अपरिभाषित प्रकारों में बदल सकती है), इसलिए यह मान लेता है कि यह एक प्रकार है । इस स्तर पर गैर-आश्रित कॉल fजो प्रोग्रामर के लिए स्वाभाविक लगती है वह एक प्रतीक है जिसे कंपाइलर को सदस्य के रूप में derivedया नामस्थान को घेरने के लिए खोजना होगा - जो उदाहरण में नहीं होता है - और यह शिकायत करेगा।

समाधान गैर-निर्भर नाम fको निर्भर नाम में बदल रहा है । यह कुछ तरीकों से किया जा सकता है, स्पष्ट रूप से उस प्रकार को बताते हुए जहां इसे लागू किया गया है (- base<T>::fजिससे base<T>प्रतीक निर्भर करता है Tऔर कंपाइलर केवल यह मान लेगा कि यह मौजूद होगा और दूसरे पास के लिए वास्तविक चेक को स्थगित कर देगा, के बाद तर्क प्रतिस्थापन।

दूसरा तरीका, बहुत अधिक सॉर्टर यदि आप उन टेम्प्लेट से विरासत में लेते हैं जिनमें एक से अधिक तर्क हैं, या लंबे नाम हैं, तो बस this->प्रतीक से पहले जोड़ रहे हैं । जैसा कि आप जिस टेम्प्लेट क्लास को लागू कर रहे हैं, वह एक तर्क पर निर्भर करता है (यह जिस से विरासत में मिलता है base<T>) this->तर्क पर निर्भर है, और हमें एक ही परिणाम मिलता है: this->fदूसरे दौर में जाँच की जाती है, टेम्पलेट पैरामीटर प्रतिस्थापन के बाद।

Answer 30

आपको "यह" तब तक उपयोग नहीं करना चाहिए जब तक कि आप बिल्कुल न करें।

वहाँ अनावश्यक दंड से संबंधित एक दंड है। आपको उस कोड के लिए प्रयास करना चाहिए जो ठीक उसी समय तक है जब तक उसे होना चाहिए, और अब नहीं।