मेरी सोच को C ++ से C # कैसे माइग्रेट करें

Question

मैं एक अनुभवी C ++ डेवलपर हूं, मैं भाषा को महान विवरणों में जानता हूं और इसकी कुछ विशिष्ट विशेषताओं का गहनता से उपयोग किया है। इसके अलावा, मैं OOD और डिजाइन पैटर्न के सिद्धांतों को जानता हूं। मैं अब C # सीख रहा हूं, लेकिन मैं यह महसूस नहीं कर सकता कि C ++ मानसिकता से छुटकारा पाने में सक्षम नहीं है। मैंने सी ++ की ताकत के लिए खुद को इतना कठिन बना लिया कि मैं कुछ सुविधाओं के बिना नहीं रह सकता। और मुझे C # में उनके लिए कोई अच्छा वर्कअराउंड या रिप्लेसमेंट नहीं मिल रहा है।

क्या अच्छा व्यवहार , डिज़ाइन पैटर्न , मुहावरे जो C # परिप्रेक्ष्य में C # से भिन्न हैं , क्या आप सुझाव दे सकते हैं? कैसे सही सी ++ डिजाइन पाने के लिए सी # में गूंगा नहीं लग रहा है?

विशेष रूप से, मुझे (हाल के उदाहरणों) से निपटने के लिए एक अच्छा C # -ish तरीका नहीं मिल सकता है:

• संसाधनों के जीवनकाल को नियंत्रित करने के लिए नियतात्मक सफाई (जैसे फ़ाइलों) की आवश्यकता होती है। यह usingहाथ में आसान है, लेकिन संसाधन के स्वामित्व को हस्तांतरित किए जाने पर इसे ठीक से कैसे उपयोग किया जाए [... betwen threads]? C ++ में मैं केवल साझा पॉइंटर्स का उपयोग करूँगा और इसे सही समय पर 'कचरा संग्रहण' का ध्यान रखूँगा।
• विशिष्ट जेनरिक के लिए ओवरराइडिंग कार्यों के साथ संघर्ष कर रहा है (मुझे C ++ में आंशिक टेम्पलेट विशेषज्ञता जैसी चीजें पसंद हैं)। क्या मुझे C # में किसी भी सामान्य प्रोग्रामिंग को करने के लिए किसी भी प्रयास को छोड़ देना चाहिए? शायद जेनरिक उद्देश्य पर सीमित हैं और समस्याओं के एक विशिष्ट डोमेन को छोड़कर उनका उपयोग करना # C -ish नहीं है?
• मैक्रो जैसी कार्यक्षमता। जबकि आम तौर पर एक बुरा विचार है, समस्याओं के कुछ डोमेन के लिए कोई अन्य वर्कअराउंड नहीं है (उदाहरण के लिए एक स्टेटमेंट का सशर्त मूल्यांकन, जैसे लॉग जो केवल डीबग रिलीज़ पर जाना चाहिए)। उनके नहीं होने का मतलब है कि मुझे अधिक if (condition) {...}बॉयलरप्लेट लगाने की जरूरत है और यह अभी भी ट्रिगर करने के दुष्प्रभावों के बराबर नहीं है।

Comments

# 1 मेरे लिए एक कठिन है, मैं खुद इसका जवाब जानना चाहूंगा। # 2 - क्या आप एक सरल C ++ कोड उदाहरण दे सकते हैं और समझा सकते हैं कि आपको इसकी आवश्यकता क्यों है? # 3 के लिए - C#अन्य कोड उत्पन्न करने के लिए उपयोग करें। आप एक CSVया XMLएक इनपुट के रूप में आपके पास क्या है या एक फाइल को पढ़ सकते हैं या एक फाइल उत्पन्न C#कर सकते SQLहैं। यह कार्यात्मक मैक्रोज़ का उपयोग करने से अधिक शक्तिशाली हो सकता है।

— नौकरी

मैक्रो जैसी कार्यक्षमता के विषय पर, आप किन विशिष्ट चीजों को करने की कोशिश कर रहे हैं? मैंने पाया है कि आमतौर पर C ++ में मैक्रो के साथ मैंने जो किया है, उसे संभालने के लिए आमतौर पर C # भाषा का निर्माण होता है। सी # प्रीप्रोसेसर निर्देश भी देखें: msdn.microsoft.com/en-us/library/4y6tbswk.aspx

— ravibhagw

C ++ में मैक्रोज़ के साथ की गई कई चीजें C # में रिफ्लेक्शन के साथ की जा सकती हैं।

— सेबस्टियन रेडल

यह मेरे पालतू जानवरों में से एक है जब कोई कहता है कि "सही काम के लिए सही उपकरण - आप जिस चीज की आवश्यकता करने जा रहे हैं उसके आधार पर एक भाषा चुनें।" सामान्य प्रयोजन की भाषाओं में बड़े कार्यक्रमों के लिए, यह एक बेकार, बेकार बयान है। उस ने कहा, सी ++ लगभग किसी भी अन्य भाषा की तुलना में बेहतर है, यह निर्धारक संसाधन प्रबंधन है। क्या नियतात्मक संसाधन प्रबंधन आपके कार्यक्रम की एक प्राथमिक विशेषता है, या आपके द्वारा उपयोग की जाने वाली चीज़ है? यदि यह एक महत्वपूर्ण उपयोगकर्ता सुविधा नहीं है, तो आप उस पर अत्यधिक ध्यान केंद्रित कर सकते हैं।

— बेन

Answer 1

मेरे अनुभव में, ऐसा करने के लिए कोई किताब नहीं है। फ़ोरम मुहावरों और सर्वोत्तम प्रथाओं के साथ मदद करते हैं, लेकिन अंत में आपको समय देना होगा। C # में विभिन्न समस्याओं का समाधान करके अभ्यास करें। देखो कि क्या कठिन / अजीब था और अगली बार उन्हें कम कठिन और कम अजीब बनाने का प्रयास करें। मेरे लिए, यह प्रक्रिया लगभग एक महीने पहले हुई जब मुझे "मिल गया"।

ध्यान केंद्रित करने के लिए सबसे बड़ी बात स्मृति प्रबंधन की कमी है। C ++ में यह आपके द्वारा किए गए हर एक डिज़ाइन निर्णय पर लॉर्ड्स है, लेकिन C # में यह काउंटर उत्पादक है। C # में, आप अक्सर अपनी वस्तुओं की मृत्यु या अन्य राज्य परिवर्तनों को अनदेखा करना चाहते हैं। इस तरह के जुड़ाव से अनावश्यक युग्मन जुड़ते हैं।

ज्यादातर, नए उपकरणों का सबसे प्रभावी ढंग से उपयोग करने पर ध्यान केंद्रित करें, न कि खुद को पुराने लोगों के प्रति लगाव के कारण।

कैसे सही सी ++ डिजाइन पाने के लिए सी # में गूंगा नहीं लग रहा है?

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

लेकिन विशिष्ट परिदृश्यों के जवाब में:

साझा अप्रबंधित संसाधन - यह C ++ में एक बुरा विचार था, और C # में केवल एक बुरा विचार है। यदि आपके पास कोई फ़ाइल है तो उसे खोलें, उसका उपयोग करें और उसे बंद करें। इसे थ्रेड्स के बीच साझा करना केवल परेशानी के लिए पूछ रहा है, और यदि केवल एक थ्रेड वास्तव में इसका उपयोग कर रहा है, तो उस थ्रेड को खुला / स्वयं बंद करें। यदि आपके पास वास्तव में किसी कारण से एक लंबे समय तक फ़ाइल है, तो उस का प्रतिनिधित्व करने के लिए एक वर्ग बनाएं और एप्लिकेशन को प्रबंधित करें (जैसे कि बाहर निकलने से पहले बंद करें, एप्लिकेशन को बंद करना घटनाओं के प्रकार, आदि)

आंशिक टेम्पलेट विशेषज्ञता - आप यहां भाग्य से बाहर हैं, हालांकि मैंने जितना अधिक C # का उपयोग किया है, मुझे लगता है कि मैंने C ++ में किए गए टेम्पलेट का उपयोग YAGNI में गिरने के लिए किया है। जब टी हमेशा एक इंट है तो कुछ सामान्य क्यों करें ? इंटरफेस के उदार आवेदन द्वारा C # में अन्य परिदृश्यों को सबसे अच्छा हल किया जाता है। जब आप एक इंटरफ़ेस या प्रतिनिधि प्रकार को दृढ़ता से टाइप कर सकते हैं जो आप अलग-अलग करना चाहते हैं, तो आपको जेनरिक की आवश्यकता नहीं है।

प्रीप्रोसेसर कंडीशन - C # है #if, गो नट्स। बेहतर अभी तक, इसमें सशर्त गुण हैं जो कि संकलक को परिभाषित नहीं किए जाने पर उस फ़ंक्शन को कोड से छोड़ देगा।

Comments

संसाधन प्रबंधन के संबंध में, C # में प्रबंधक कक्षाएं (जो स्थिर या गतिशील हो सकती हैं) होना काफी आम है।

— rwong

साझा संसाधनों के बारे में: प्रबंधित किए जाने वाले सी # में आसान हैं (यदि दौड़-परिस्थितियां अप्रासंगिक हैं), तो अप्रबंधित लोग कहीं अधिक नास्टियर हैं।

— Deduplicator

@rwong - आम, लेकिन प्रबंधक वर्ग अभी भी एक पैटर्न से बचा जा रहा है।

— तेलस्टिन

स्मृति प्रबंधन के संबंध में, मैंने पाया कि C # पर स्विच करने से यह और अधिक कठिन हो गया, खासकर शुरुआत में। मुझे लगता है कि आपको C ++ की तुलना में अधिक जागरूक होना होगा। C ++ में आप जानते हैं कि हर वस्तु को कब और कहां आवंटित किया जाता है, निपटाया और संदर्भित किया जाता है। C # में, यह सब आपसे छिपा हुआ है। कई बार C # में आपको यह भी एहसास नहीं होता है कि किसी ऑब्जेक्ट का रेफरेंस मिल गया है और मेमोरी लीक होने लगती है। सी # में मेमोरी लीक को ट्रैक करना मज़ेदार है, जो आमतौर पर सी ++ में पता लगाने के लिए तुच्छ हैं। बेशक, अनुभव के साथ आप सी # की इन बारीकियों को सीखते हैं, इसलिए वे एक मुद्दे से कम हो जाते हैं।

— डुंक

Answer 2

जहां तक ​​मैं देख सकता हूं, निर्धारक लाइफटाइम मैनेजमेंट के लिए अनुमति देने वाली एकमात्र चीज है IDisposable, जो टूट जाती है (जैसे: कोई भाषा या प्रकार प्रणाली का समर्थन) जब, जैसा कि आपने देखा, तो आपको ऐसे संसाधन के स्वामित्व को स्थानांतरित करने की आवश्यकता है।

आप के रूप में एक ही नाव में होने के नाते - सी ++ डेवलपर कर सी # एटीएम। - सी # प्रकार / हस्ताक्षरों में स्वामित्व हस्तांतरण (फ़ाइलें, डीबी-कनेक्शन, ...) मॉडल के समर्थन की कमी मुझे बहुत परेशान कर रही है, लेकिन मुझे यह स्वीकार करना होगा कि यह "सिर्फ" पर भरोसा करने के लिए काफी ठीक है यह अधिकार पाने के लिए सम्मेलन और एपीआई डॉक्स पर।

• यदि आवश्यक IDisposableहो तो निर्धारक साफ करने के लिए उपयोग करें ।
• जब आपको किसी के स्वामित्व को स्थानांतरित करने की आवश्यकता होती है IDisposable, तो सुनिश्चित करें कि इसमें शामिल एपीआई इस पर स्पष्ट है और usingइस मामले में उपयोग न करें , क्योंकि usingबोलने के लिए "रद्द" नहीं किया जा सकता है।

हां, यह उतना सुंदर नहीं है जितना कि आप आधुनिक C ++ (मूवमेंट वगैरह, आदि) के साथ टाइप सिस्टम में व्यक्त कर सकते हैं, लेकिन यह काम पूरा कर लेता है, और (आश्चर्यजनक रूप से) C # समुदाय के रूप में संपूर्ण नहीं लगता है। ओवरमुच की देखभाल, AFAICT।

Answer 3

आपने दो विशिष्ट C ++ सुविधाओं का उल्लेख किया है। मैं RAII पर चर्चा करूंगा:

यह आमतौर पर लागू नहीं होता है, क्योंकि C # कचरा एकत्र किया जाता है। निकटतम C # निर्माण संभवतः IDisposableइंटरफ़ेस है, जिसका उपयोग निम्नानुसार किया जाता है:

using (FileStream fs = File.OpenRead(@"c:\path\filename.txt"))
{
   //Do stuff with the file.
} //File will be closed here.

आपको IDisposableअक्सर लागू करने की उम्मीद नहीं करनी चाहिए (और ऐसा करना थोड़ा उन्नत है), क्योंकि यह प्रबंधित संसाधनों के लिए आवश्यक नहीं है। हालांकि, आपको किसी भी चीज को लागू करने के लिए usingनिर्माण का उपयोग करना चाहिए (या Disposeअपने आप को कॉल करना , यदि संभव नहीं usingहै) IDisposable। यहां तक ​​कि अगर आप इसे गड़बड़ करते हैं, तो अच्छी तरह से डिज़ाइन की गई सी # कक्षाएं आपके लिए इसे अंतिम रूप देने का उपयोग करने का प्रयास करेंगी। हालांकि, एक कचरा एकत्र की गई भाषा में आरएआई पैटर्न पूरी तरह से काम नहीं करता है (क्योंकि संग्रह गैर-नियतात्मक है), इसलिए आपके संसाधन की सफाई में देरी होगी (कभी-कभी भयावह रूप से)।

Comments

RAII वास्तव में मेरी सबसे बड़ी परेशानी है। मान लें कि मेरे पास एक संसाधन है (एक फ़ाइल कहिए) जो एक धागे से बनाई गई है और दूसरे को दी गई है। मैं यह कैसे सुनिश्चित कर सकता हूं कि यह एक निश्चित समय पर निपटाया जाए जब उस धागे को अब इसकी आवश्यकता नहीं है? बेशक, मैं डिस्पोजल कह सकता हूं, लेकिन फिर यह C ++ में साझा किए गए पॉइंटर्स की तुलना में बदसूरत दिखता है। इसमें RAII का कुछ भी नहीं है।

— एंड्रयू

@ और आप जो वर्णन करते हैं, वह स्वामित्व के अंतरण के लिए लगता है, इसलिए अब दूसरा धागा Disposing()फ़ाइल के लिए ज़िम्मेदार है और शायद इसका उपयोग करना चाहिए using।

— 21

@ और - सामान्य तौर पर, आपको ऐसा नहीं करना चाहिए। आपको इसके बजाय थ्रेड को यह बताना चाहिए कि फ़ाइल कैसे प्राप्त करें और इसे जीवन भर का स्वामित्व दें।

— तेलस्टिन

@Telastyn इसका मतलब यह है कि प्रबंधित संसाधन पर स्वामित्व देना C # की तुलना में C # में एक बड़ी समस्या है? काफी हैरानी की बात है।

— एंड्रयू

@Andrew: मुझे संक्षेप में बताएं: C ++ में, आपको सभी संसाधनों का एक समान, अर्ध-स्वचालित प्रबंधन मिलता है। C # में, आपको मेमोरी का पूरी तरह से स्वचालित प्रबंधन मिलता है - और बाकी सब चीजों का पूरी तरह से मैनुअल प्रबंधन। इसमें कोई वास्तविक परिवर्तन नहीं हुआ है, इसलिए आपका एकमात्र वास्तविक प्रश्न यह नहीं है कि "मैं इसे कैसे ठीक करूं?", केवल "मुझे इसकी कैसे आदत है?"

— जेरी कॉफिन

Answer 4

यह एक बहुत अच्छा प्रश्न है, जैसा कि मैंने कई C ++ डेवलपर्स को भयानक C # कोड लिखते देखा है।

सी # के रूप में "सी ++ के साथ अच्छे सिंटैक्स" के बारे में नहीं सोचना सबसे अच्छा है। वे अलग-अलग भाषाएं हैं जिन्हें आपकी सोच में अलग दृष्टिकोण की आवश्यकता होती है। C ++ आपको लगातार सोचने पर मजबूर करता है कि CPU और मेमोरी क्या कर रहे हैं। C # ऐसा नहीं है। सी # विशेष रूप से डिज़ाइन किया गया है ताकि आप सीपीयू और मेमोरी के बारे में नहीं सोच रहे हैं और इसके बजाय आप जिस व्यवसाय डोमेन के लिए लिख रहे हैं उसके बारे में सोच रहे हैं ।

इसका एक उदाहरण जो मैंने देखा है वह यह है कि बहुत सारे C ++ डेवलपर्स लूप्स के लिए उपयोग करना पसंद करेंगे, क्योंकि वे फॉर्च्यूनर से तेज़ हैं। यह आमतौर पर C # में एक बुरा विचार है क्योंकि यह संग्रह के संभावित प्रकारों को (और इसलिए पुन: प्रयोज्य और कोड के लचीलेपन) को सीमित करता है।

मुझे लगता है कि C ++ से C # तक पढ़ने का सबसे अच्छा तरीका एक अलग दृष्टिकोण से कोडिंग की कोशिश करना और दृष्टिकोण करना है। सबसे पहले यह कठिन होगा, क्योंकि आपके द्वारा लिखे गए कोड को फ़िल्टर करने के लिए आपके दिमाग में "सीपीयू और मेमोरी क्या कर रहे हैं" धागे का उपयोग करने के लिए पूरी तरह से उपयोग किया जाएगा। लेकिन C # में, आपको इसके बजाय व्यावसायिक डोमेन में ऑब्जेक्ट्स के बीच संबंधों के बारे में सोचना चाहिए। "मैं कंप्यूटर क्या कर रहा हूं" के विपरीत "मैं क्या करना चाहता हूं"।

यदि आप वस्तुओं की सूची में सब कुछ के लिए कुछ करना चाहते हैं, तो सूची पर लूप के लिए लिखने के बजाय, एक विधि बनाएं जो एक लेता है IEnumerable<MyObject>और एक foreachलूप का उपयोग करता है।

आपके विशिष्ट उदाहरण:

संसाधनों के जीवनकाल को नियंत्रित करने के लिए नियतात्मक सफाई (जैसे फ़ाइलों) की आवश्यकता होती है। यह हाथ में उपयोग करने में आसान है, लेकिन संसाधन के स्वामित्व को [… betwen धागे] स्थानांतरित होने पर इसे ठीक से कैसे उपयोग किया जाए? C ++ में मैं केवल साझा पॉइंटर्स का उपयोग करूँगा और इसे सही समय पर 'कचरा संग्रहण' का ध्यान रखूँगा।

आपको इसे C # (विशेषकर थ्रेड्स के बीच) में कभी नहीं करना चाहिए। यदि आपको किसी फ़ाइल में कुछ करने की आवश्यकता है, तो उसे एक समय में एक ही स्थान पर करें। यह एक रैपर वर्ग लिखने के लिए ठीक है (और वास्तव में अच्छा अभ्यास) जो अप्रबंधित संसाधन का प्रबंधन करता है जो आपकी कक्षाओं के बीच पास हो जाता है, लेकिन कोशिश न करें और थ्रेड्स के बीच एक फाइल पास करें और अलग-अलग कक्षाएं लिखें / पढ़ें / बंद करें / इसे खोलें। अप्रबंधित संसाधनों का स्वामित्व साझा न करें। Disposeसफाई से निपटने के लिए पैटर्न का उपयोग करें ।

विशिष्ट जेनरिक के लिए ओवरराइडिंग कार्यों के साथ संघर्ष कर रहा है (मुझे C ++ में आंशिक टेम्पलेट विशेषज्ञता जैसी चीजें पसंद हैं)। क्या मुझे C # में किसी भी सामान्य प्रोग्रामिंग को करने के लिए किसी भी प्रयास को छोड़ देना चाहिए? शायद जेनरिक उद्देश्य पर सीमित हैं और समस्याओं के एक विशिष्ट डोमेन को छोड़कर उनका उपयोग करना # C -ish नहीं है?

सी # में जेनरिक को सामान्य बनाया गया है। जेनरिक की विशेषज्ञता व्युत्पन्न वर्गों द्वारा नियंत्रित की जानी चाहिए। List<T>अगर यह एक List<int>या एक अलग व्यवहार क्यों करना चाहिए List<string>? किसी भीList<T> पर लागू करने के लिए सभी ऑपरेशन सामान्य हैं । यदि आप ए पर विधि के व्यवहार को बदलना चाहते हैं , तो एक व्युत्पन्न वर्ग या एक निर्मित वर्ग बनाएं जो सामान्य रूप से सामान्य रूप से उपयोग करता है लेकिन चीजों को अलग तरीके से करता है। इससे आपको लिस्कोव सबस्टीट्यूशन सिद्धांत का उल्लंघन करने और दूसरों को अपनी कक्षा का उपयोग करने वाले लोगों पर शिकंजा कसने से बचने में मदद मिलती है। List<T>.AddList<string>MySpecializedStringCollection : List<string>MySpecializedStringCollection : IList<string>

मैक्रो जैसी कार्यक्षमता। जबकि आम तौर पर एक बुरा विचार है, समस्याओं के कुछ डोमेन के लिए कोई अन्य वर्कअराउंड नहीं है (जैसे किसी स्टेटमेंट का सशर्त मूल्यांकन, जैसे लॉग जो केवल डिबग रिलीज पर जाना चाहिए)। उनके नहीं होने का मतलब है कि मुझे और अधिक डालने की जरूरत है अगर (स्थिति) {...} बॉयलरप्लेट और यह अभी भी ट्रिगर करने के दुष्प्रभावों के बराबर नहीं है।

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

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

Comments

WRT। संसाधन अंतरण: "आपको ऐसा कभी नहीं करना चाहिए" इसे IMHO नहीं काटता है। अक्सर, एक बहुत अच्छा डिजाइन पता चलता है एक के हस्तांतरण IDisposable( नहीं एक वर्ग से दूसरे में कच्चे संसाधन): बस देखना StreamWriter एपीआई, जहां इस के लिए एकदम सही समझ में आता है Dispose()पारित कर दिया धारा के। और सी # भाषा में छेद निहित है - आप इसे टाइप सिस्टम में व्यक्त नहीं कर सकते।

— मार्टिन बा

"इसका एक उदाहरण जो मैंने देखा है वह यह है कि बहुत सारे C ++ डेवलपर्स लूप के लिए उपयोग करना पसंद करेंगे क्योंकि वे फ़ॉरच से तेज़ हैं।" यह C ++ में भी एक बुरा विचार है। शून्य-लागत अमूर्तता सी ++ की महान शक्ति है, और अधिकांश मामलों में लूप के लिए फॉर्च या अन्य एल्गोरिदम को हाथ से लिखे जाने की तुलना में धीमा नहीं होना चाहिए।

— सेबस्टियन रेडल

Answer 5

मेरे लिए जो चीज सबसे अलग थी, वह थी नई चीजों की प्रवृत्ति । यदि आप एक वस्तु चाहते हैं, तो इसे एक दिनचर्या में पारित करने और अंतर्निहित डेटा साझा करने की कोशिश करना भूल जाएं, ऐसा लगता है कि सी # पैटर्न सिर्फ अपने आप को एक नई वस्तु बनाने के लिए है। यह, सामान्य तौर पर, C # तरीके से बहुत अधिक लगता है। पहले तो यह पैटर्न बहुत अकुशल लग रहा था, लेकिन मुझे लगता है कि C # में ज्यादातर ऑब्जेक्ट बनाना एक त्वरित ऑपरेशन है।

हालांकि, वहाँ भी स्थिर वर्ग है कि वास्तव में मुझे परेशान है क्योंकि हर बार जब आप इसे केवल एक का उपयोग करने के लिए बनाने की कोशिश करते हैं तो आपको इसे बस उपयोग करना होगा। मुझे पता है कि इसका उपयोग करना इतना आसान नहीं है।

मैं सी # प्रोग्राम में काफी खुश हूँ, बस इसे अनदेखा करने के लिए जब मुझे इसकी आवश्यकता नहीं है, लेकिन बस याद रखें कि उस वस्तु में क्या है - आम तौर पर आपको केवल यह सोचना होगा कि इसमें कुछ 'असामान्य' डेटा है या नहीं, जिन वस्तुओं में केवल मेमोरी होती है बस खुद से दूर चले जाओ, दूसरों को निपटाना होगा या आपको यह देखना होगा कि उन्हें कैसे नष्ट किया जाए - मैन्युअल रूप से या उपयोग ब्लॉक द्वारा यदि नहीं।

आप बहुत जल्दी इसे उठा लेंगे, हालांकि C # VB से शायद ही कोई भिन्न हो, इसलिए आप इसे उसी RAD टूल के रूप में मान सकते हैं (यदि यह C # के बारे में सोचने में मदद करता है जैसे VB.NET तो ऐसा करें, सिंटैक्स केवल थोड़ा सा है अलग-अलग, और वीबी के उपयोग के मेरे पुराने दिनों ने मुझे आरएडी विकास के लिए सही मानसिकता में मिला दिया)। एकमात्र मुश्किल बिट यह निर्धारित कर रहा है कि आपको कौन सी विशाल .net लाइब्रेरी का उपयोग करना चाहिए। Google निश्चित रूप से यहाँ आपका मित्र है!

Comments

अंतर्निहित डेटा साझा करने के लिए एक रूटीन के लिए एक वस्तु को पास करना सी # में पूरी तरह से ठीक है, कम से कम एक वाक्यविन्यास परिप्रेक्ष्य से।

— ब्रायन