संरचनाएं बनाम कक्षाएं

Question

मैं कोड में 100,000 ऑब्जेक्ट बनाने वाला हूं। वे छोटे हैं, केवल 2 या 3 गुणों के साथ। मैं उन्हें एक सामान्य सूची में डालूँगा और जब वे होंगे, तो मैं उन्हें लूप करूँगा और मान की जाँच करूँगा aऔर हो सकता है कि मान अपडेट हो जाए b।

क्या इन वस्तुओं को कक्षा या संरचना के रूप में बनाना तेज / बेहतर है?

संपादित करें

ए। गुण मान प्रकार हैं (स्ट्रिंग के अलावा मुझे लगता है?)

ख। वे हो सकता है (हम अभी तक निश्चित नहीं हैं) एक मान्य विधि है

EDIT 2

मैं सोच रहा था: ढेर पर वस्तुएं और कचरा कलेक्टर द्वारा समान रूप से संसाधित ढेर हैं, या क्या यह अलग काम करता है?

Comments

क्या उनके पास केवल सार्वजनिक क्षेत्र होने वाले हैं, या क्या उनके पास भी तरीके हैं? क्या प्रकार आदिम प्रकार हैं, जैसे पूर्णांक? क्या वे किसी सरणी में, या सूची <T> जैसी किसी चीज़ में शामिल होंगे?

— जेफ फर्ग्यूसन

परिवर्तनशील संरचनाओं की एक सूची? वेलोसिरैप्टर के लिए देखें।

— एंथनी पेग्राम

@ एंथोनी: मुझे डर है कि मैं वेलोसियकप्टर का मजाक नहीं कर रहा हूँ: -s

— मिशेल

वेलोसिरैप्टर का मजाक एक्सकेसीडी से है। लेकिन जब आप 'वैल्यू टाइप्स' को स्टैक पर डालते हैं, तो गलतफहमी / इंप्लीमेंटेशन डिटेल (इम्प्लीमेंटेशन डिलीट) लागू होती है, तो यह एरिक लिपर्ट आपको देखने की जरूरत है ...

— ग्रेग बीच

velociraptor

— वर्नरसीडी

Answer 1

क्या इन वस्तुओं को कक्षा या संरचना के रूप में बनाना तेज है?

आप एकमात्र व्यक्ति हैं जो उस प्रश्न का उत्तर निर्धारित कर सकते हैं। इसे दोनों तरीकों से आज़माएं, एक सार्थक, उपयोगकर्ता-केंद्रित, प्रासंगिक प्रदर्शन मीट्रिक को मापें , और फिर आपको पता चल जाएगा कि क्या परिवर्तन का प्रासंगिक परिदृश्यों में वास्तविक उपयोगकर्ताओं पर सार्थक प्रभाव है।

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

क्या इन वस्तुओं को वर्ग या संरचना के रूप में बनाना बेहतर है?

शायद वर्ग, शायद संरचना। अंगूठे के एक नियम के रूप में: यदि वस्तु है:
1. छोटा
2. तार्किक रूप से एक अपरिवर्तनीय मूल्य
3. उनमें से बहुत कुछ है
तो मैं इसे एक संरचना बनाने पर विचार करूंगा। अन्यथा मैं एक संदर्भ प्रकार के साथ रहना चाहूंगा।

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

क्या कचरे के ढेर पर समान रूप से संसाधित ढेर और ढेर पर वस्तुएं हैं?

नहीं , वे समान नहीं हैं क्योंकि स्टैक पर ऑब्जेक्ट संग्रह की जड़ें हैं । कचरा संग्रहकर्ता को कभी यह पूछने की ज़रूरत नहीं है "क्या यह जिंदा ढेर पर है?" क्योंकि उस प्रश्न का उत्तर हमेशा "हाँ, यह स्टैक पर है"। (अब, आप इस बात पर भरोसा नहीं कर सकते हैं कि किसी वस्तु को जीवित रखने के लिए क्योंकि स्टैक एक कार्यान्वयन विवरण है। घबराना को अनुकूलन का परिचय देने की अनुमति है, जो कहते हैं कि सामान्य रूप से स्टैक मान क्या होगा, और फिर स्टैक पर कभी नहीं है। इसलिए GC यह नहीं जानता है कि यह अभी भी जीवित है। एक अपंजीकृत वस्तु के अपने वंशज को आक्रामक रूप से एकत्र किया जा सकता है, जैसे ही उस पर रखे गए रजिस्टर को फिर से पढ़ा नहीं जा रहा है।)

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

स्पष्ट है क्या?

Comments

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

— जॉन हैना

@Jon: सी # संकलक का अनुकूलन स्थिरांक डेटा नहीं बल्कि केवल पढ़ने के लिए डेटा। मुझे नहीं पता कि जेट कंपाइलर रीडिंगली फ़ील्ड्स पर कोई कैशिंग ऑप्टिमाइज़ेशन करता है या नहीं।

— एरिक लिपर्ट

एक दया, जैसा कि मुझे पता है कि अपरिवर्तनीयता का ज्ञान कुछ अनुकूलन के लिए अनुमति देता है, लेकिन उस बिंदु पर मेरे सैद्धांतिक ज्ञान की हिट सीमाएं हैं, लेकिन वे सीमाएं हैं जिन्हें मैं खिंचाव पसंद करूंगा। इस बीच "यह दोनों तरीकों से तेज हो सकता है, यहां क्यों, अब परीक्षण करें और पता करें कि इस मामले में कौन सा लागू होता है" कहने में सक्षम होने के लिए उपयोगी है :)

— जॉन हैना

मैं dive शुरू करने के लिए simple-talk.com/dotnet/.net-framework/… और अपना खुद का लेख (@Eric): blogs.msdn.com/b/ericlippert/archive/2010/09/30/… पढ़ने की सलाह दूंगा। विवरण में। आसपास कई अन्य अच्छे लेख हैं। BTW, 100 000 छोटे-इन-मेमोरी ऑब्जेक्ट्स के प्रसंस्करण में अंतर शायद ही ध्यान देने योग्य है, क्योंकि कक्षा में कुछ मेमोरी ओवरहेड (~ 2.3 एमबी) है। इसे सरल परीक्षण द्वारा आसानी से जांचा जा सकता है।

— निक मार्टिसचेंको

हाँ, यह स्पष्ट है। आपके व्यापक के लिए बहुत बहुत धन्यवाद (व्यापक बेहतर है; Google अनुवाद ने 2 अनुवाद दिए। मेरा कहने का मतलब था कि आपने संक्षिप्त उत्तर नहीं लिखने के लिए समय लिया, लेकिन सभी विवरण लिखने के लिए समय भी लिया) उत्तर।

— मिशेल

Answer 2

कभी-कभी structआपको नए () कंस्ट्रक्टर को कॉल करने की आवश्यकता नहीं होती है, और इसे सामान्य रूप से बहुत तेज़ी से बनाने वाले फ़ील्ड को सीधे असाइन करें।

उदाहरण:

Value[] list = new Value[N];
for (int i = 0; i < N; i++)
{
    list[i].id = i;
    list[i].isValid = true;
}

से लगभग 2 से 3 गुना तेज है

Value[] list = new Value[N];
for (int i = 0; i < N; i++)
{
    list[i] = new Value(i, true);
}

जहां Valueएक है structदो (क्षेत्रों के साथ idऔर isValid)।

struct Value
{
    int id;
    bool isValid;

    public Value(int i, bool isValid)
    {
        this.i = i;
        this.isValid = isValid;
    }
}

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

Comments

जाहिर तौर पर चीजें बहुत तेज हो जाती हैं, जब आप मूल सीमाओं पर बहुत ज्यादा महत्व रखते हैं।

— लीपी

मैं इसके अलावा किसी अन्य नाम का उपयोग करने का सुझाव देता हूं list, यह देखते हुए कि संकेतित कोड किसी के साथ काम नहीं करेगा List<Value>।

— सुपरकैट

Answer 3

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

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

यहां अधिक:

http://msdn.microsoft.com/en-us/library/aa288471(VS.71).aspx

Comments

मुझे पता है कि यह MSDN पर कहता है, लेकिन MSDN पूरी कहानी नहीं बता रहा है। स्टैक बनाम हीप एक कार्यान्वयन विवरण है और संरचनाएं हमेशा स्टैक पर नहीं जाती हैं। इस पर सिर्फ एक हाल के ब्लॉग के लिए, देखें: blogs.msdn.com/b/ericlippert/archive/2010/09/30/…

— एंथनी

"... यह मान द्वारा पारित किया गया है ..." दोनों संदर्भ और संरचनाएं मान से पारित हो जाती हैं (जब तक कि कोई 'रेफ' का उपयोग नहीं करता है) - यह है कि क्या कोई मान या संदर्भ पारित किया जा रहा है जो अलग-अलग है, अर्थात संरचना मूल्य-दर-मूल्य से पारित हो जाती है , कक्षा की वस्तुओं को संदर्भ-दर-मूल्य और रेफरी द्वारा पारित पारमों को संदर्भ-दर-संदर्भ दिया जाता है।

— पॉल रुआन

यह लेख कई प्रमुख बिंदुओं पर भ्रामक है, और मैंने MSDN टीम को इसे संशोधित करने या हटाने के लिए कहा है।

— एरिक लिपर्ट

@ सुपरकैट: अपने पहले बिंदु को संबोधित करने के लिए: बड़ा बिंदु यह है कि प्रबंधित कोड में जहां एक मान या संदर्भ को संग्रहीत किया जाता है वह काफी हद तक अप्रासंगिक है । हमने एक मेमोरी मॉडल बनाने के लिए कड़ी मेहनत की है जो ज्यादातर समय डेवलपर्स को उनकी ओर से स्मार्ट स्टोरेज निर्णय लेने के लिए रनटाइम की अनुमति देता है। ये अंतर बहुत मायने रखते हैं जब उन्हें समझने में असफलता के दुर्घटनाग्रस्त परिणाम होते हैं जैसा कि सी में होता है; C # में इतना नहीं।

— एरिक लिपर्ट

@ सुपरकैट: अपने दूसरे बिंदु को संबोधित करने के लिए, कोई भी परस्पर संरचना ज्यादातर बुरी नहीं है। उदाहरण के लिए, शून्य M () {S s = new S (); s.Blah (); एन (रों); }। प्रतिक्षेपक: शून्य DoBlah (एस) {s.Blah (); } void M (S s = new S (); DoBlah (s); N (s);}?। कि सिर्फ एक बग की शुरुआत की क्योंकि S एक उत्परिवर्तनीय संरचना है। क्या आपने तुरंत बग को देखा है? या तथ्य यह है कि S है एक परिवर्तनशील संरचना आपसे बग को छिपाती है?

— एरिक लिपर्ट

Answer 4

स्मृति की एक सन्निहित ब्लॉक में ढेर पर संरचनाओं की किरणों का प्रतिनिधित्व किया जाता है, जबकि वस्तुओं की एक सरणी को ढेर पर वास्तविक वस्तुओं के साथ संदर्भों के एक सन्निहित ब्लॉक के रूप में दर्शाया जाता है, इस प्रकार दोनों वस्तुओं के लिए और उनके सरणी संदर्भों के लिए स्मृति की आवश्यकता होती है। ।

इस मामले में, जैसा कि आप उन्हें एक List<>(और एक List<>सरणी पर समर्थित है) में रख रहे हैं, यह अधिक कुशल, मेमोरी-वार का उपयोग करने के लिए होगा।

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

Comments

इससे refनिपटने के लिए आप कीवर्ड का उपयोग करने में सक्षम हैं ।

— लेप्पी

"हालांकि, सावधान रहें कि बड़े सरणियों को लार्ज ऑब्जेक्ट हीप पर अपना रास्ता मिल जाएगा, जहां यदि उनका जीवनकाल लंबा है, तो आपकी प्रक्रिया के स्मृति प्रबंधन पर प्रतिकूल प्रभाव पड़ सकता है।" - मुझे यकीन नहीं है कि आप ऐसा क्यों सोचेंगे? LOH पर आवंटित होने से मेमोरी प्रबंधन पर कोई प्रतिकूल प्रभाव नहीं पड़ेगा जब तक (संभवतः) यह एक अल्पकालिक वस्तु नहीं है और आप जेन 2 संग्रह के इंतजार के बिना मेमोरी को जल्दी से पुनः प्राप्त करना चाहते हैं।

— जॉन आर्टस

@ जॉन आर्टस: एलओएच को संकुचित नहीं किया जाता है। कोई भी लंबे समय तक रहने वाली वस्तु LOH को पहले मुक्त मेमोरी के क्षेत्र में और उसके बाद के क्षेत्र में विभाजित करेगी। आवंटन के लिए समृद्ध स्मृति की आवश्यकता होती है और यदि ये क्षेत्र आवंटन के लिए पर्याप्त नहीं हैं तो अधिक मेमोरी एलओएच को आवंटित की जाती है (यानी आपको एलओएच विखंडन मिलेगा)।

— पॉल रूआन

Answer 5

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

आपके दूसरे संपादन के लिए, GC केवल ढेर से संबंधित है, लेकिन स्टैक स्पेस की तुलना में बहुत अधिक हीप स्पेस है, इसलिए स्टैक पर चीजों को रखना हमेशा एक जीत नहीं होती है। इसके अलावा, संरचना-प्रकारों की एक सूची और वर्ग-प्रकारों की एक सूची दोनों तरह से ढेर पर होगी, इसलिए यह इस मामले में अप्रासंगिक है।

संपादित करें:

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

निजी नेस्टेड संरचनाओं के साथ उचित अपवाद हो सकते हैं, जहां उस संरचना के सभी उपयोग बहुत सीमित दायरे तक ही सीमित हैं। हालांकि यह यहाँ लागू नहीं होता है।

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

Answer 6

सबसे अच्छा उपाय है मापना, फिर से मापना, फिर कुछ और मापना। आप जो कर रहे हैं, उसका विवरण सरल हो सकता है, "स्टैम्प का उपयोग करें" या "कक्षाओं का उपयोग करें" जैसे आसान उत्तर देना मुश्किल हो सकता है।

Comments

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

— मिशेल

Answer 7

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

मुझे लगता है कि अधिकांश संरचना-बनाम-श्रेणी भ्रम इस तथ्य से उपजा है कि संरचनाओं में दो अलग-अलग उपयोग के मामले हैं, जिनके लिए बहुत अलग डिजाइन दिशानिर्देश होने चाहिए, लेकिन एमएस दिशानिर्देश उनके बीच अंतर नहीं करते हैं। कभी-कभी किसी वस्तु की आवश्यकता होती है जो एक वस्तु की तरह व्यवहार करती है; उस मामले में, एमएस दिशानिर्देश बहुत उचित हैं, हालांकि "16 बाइट सीमा" शायद 24-32 की तरह अधिक होनी चाहिए। कभी-कभी, हालांकि, जो आवश्यक है वह चर का एक एकत्रीकरण है। उस उद्देश्य के लिए उपयोग की जाने वाली संरचना में केवल सार्वजनिक क्षेत्रों का एक समूह होना चाहिए, और संभवतः एक Equalsओवरराइड, ToStringओवरराइड औरIEquatable(itsType).Equalsकार्यान्वयन। संरचनाएं जो खेतों के एकत्रीकरण के रूप में उपयोग की जाती हैं, वे ऑब्जेक्ट नहीं हैं, और होने का नाटक नहीं करना चाहिए। संरचना के दृष्टिकोण से, क्षेत्र का अर्थ "इस क्षेत्र के लिए लिखी गई अंतिम चीज" से अधिक या कम नहीं होना चाहिए। किसी भी अतिरिक्त अर्थ को ग्राहक कोड द्वारा निर्धारित किया जाना चाहिए।

उदाहरण के लिए, यदि एक चर-समुच्चय संरचना में सदस्य हैं Minimumऔर Maximum, संरचना को स्वयं कोई वादा नहीं करना चाहिए Minimum <= Maximum। एक पैरामीटर के रूप में ऐसी संरचना प्राप्त करने वाले कोड को ऐसा व्यवहार करना चाहिए मानो इसे अलग Minimumऔर Maximumमानों के साथ पारित किया गया हो । एक आवश्यकता जो Minimumकिसी से अधिक नहीं Maximumहोनी चाहिए उसे एक आवश्यकता की तरह माना जाना चाहिए कि एक Minimumपैरामीटर अलग-अलग पारित होने से अधिक नहीं है Maximum।

कभी-कभी विचार करने के लिए एक उपयोगी पैटर्न ExposedHolder<T>कुछ इस तरह से परिभाषित एक वर्ग है:

class ExposedHolder<T>
{
  public T Value;
  ExposedHolder() { }
  ExposedHolder(T val) { Value = T; }
}

यदि किसी के पास एक चर है List<ExposedHolder<someStruct>>, जहां someStructएक चर-समुच्चय संरचना है, तो कोई भी ऐसा काम कर सकता है myList[3].Value.someField += 7;, लेकिन myList[3].Valueदूसरे कोड को देने से इसे Valueबदलने का साधन देने की बजाय सामग्री मिलेगी । इसके विपरीत, यदि कोई उपयोग करता है List<someStruct>, तो इसका उपयोग करना आवश्यक होगा var temp=myList[3]; temp.someField += 7; myList[3] = temp;। यदि कोई परस्पर श्रेणी के प्रकार का उपयोग करता है, तो myList[3]बाहरी कोड की सामग्री को उजागर करने के लिए सभी फ़ील्ड को किसी अन्य ऑब्जेक्ट पर कॉपी करने की आवश्यकता होगी। यदि कोई अपरिवर्तनीय वर्ग प्रकार, या "ऑब्जेक्ट-स्टाइल" संरचना का उपयोग करता है, तो एक नए उदाहरण का निर्माण करना आवश्यक होगा जो myList[3]इसके अलावा someFieldअलग था, और फिर उस नए उदाहरण को सूची में संग्रहीत करें।

एक अतिरिक्त ध्यान दें: यदि आप बड़ी संख्या में समान चीजों का भंडारण कर रहे हैं, तो संरचनाओं के संभवतः-नेस्टेड सरणियों में उन्हें स्टोर करना अच्छा हो सकता है, अधिमानतः प्रत्येक सरणी का आकार 1K और 64K के बीच रखने की कोशिश कर रहा है। संरचनाओं की सारणियां विशेष हैं, उस अनुक्रमण में एक संरचना के भीतर एक सीधा संदर्भ मिलेगा, इसलिए कोई "[12] .x = 5;" कह सकता है। यद्यपि कोई सरणी जैसी वस्तुओं को परिभाषित कर सकता है, सी # उन्हें सरणियों के साथ इस तरह के वाक्यविन्यास को साझा करने की अनुमति नहीं देता है।

Answer 8

कक्षाओं का उपयोग करें।

एक सामान्य नोट पर। आप उन्हें बनाते समय मान b क्यों अपडेट नहीं करते?

Answer 9

एक c ++ परिप्रेक्ष्य से मैं सहमत हूं कि यह एक वर्ग की तुलना में एक संरचनात्मक गुणों को धीमा करने वाला होगा। लेकिन मुझे लगता है कि ढेर के बजाय ढेर पर आवंटित संरचना के कारण वे पढ़ने में तेज होंगे। ढेर से डेटा पढ़ना स्टैक से अधिक जांच की आवश्यकता है।

Answer 10

ठीक है, यदि आप स्ट्रक्चर ऑफ्टर के साथ जाते हैं, तो स्ट्रिंग से छुटकारा पाएं और निश्चित आकार के चार या बाइट बफर का उपयोग करें।

वह फिर से है: प्रदर्शन।