2010-05-03 8 views
6

यदि कोई सी में असुरक्षित structs के अंदर बाल structs के लिए पॉइंटर्स की एक सरणी डाल सकता है जैसे कि सी में हो सकता है, प्रति ऑब्जेक्ट एक ऑब्जेक्ट रखने के ऊपरी हिस्से के बिना जटिल डेटा संरचनाओं का निर्माण करना बहुत आसान और कम समय के सिंक के रूप में होगा, अच्छी तरह से वाक्य रचनात्मक रूप से क्लीनर और अधिक पढ़ने योग्य।सी # में असुरक्षित structs में पॉइंटर्स के सरणी डालने में सक्षम नहीं होने के अंतर्निहित कारण क्या हैं?

क्या कोई गहरा आर्किटेक्चरल कारण है कि असुरक्षित structs के अंदर निश्चित सरणी केवल "मूल्य प्रकार" से बने होने की अनुमति है और पॉइंटर्स नहीं?

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

डिजिटल मंगल डी डी तुलनात्मक रूप से सुराग और पॉइंटर्स की तुलना में सुदृढ़ रूप से हैंडल करता है, और मुझे लगता है कि संक्षिप्त डेटा संरचनाओं को तेजी से विकसित करने में सक्षम नहीं है; सी # में संदर्भ अमूर्त बनाकर, बहुत सारी शक्ति भाषा से हटा दी गई है, भले ही पॉइंटर्स कम से कम मार्केटिंग भावना में हों।

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

उत्तर

2

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

वैसे भी आप ulong रों की एक सरणी का उपयोग करें और उसके संकेतों को कास्ट कर सकते हैं:

unsafe struct s1 
{ 
    public int a; 
    public int b; 
} 

unsafe struct s 
{ 
    public fixed ulong otherStruct[100]; 
} 

unsafe void f() { 
    var S = new s(); 
    var S1 = new s1(); 
    S.otherStruct[4] = (ulong)&S1; 
    var S2 = (s1*)S.otherStruct[4]; 
} 
4

एक बहुत ही सरल कारण: डॉटनेट में कचरा कलेक्टर कंपैक्टिंग है। यह चीजों को चारों ओर ले जाता है। तो अगर आप इस तरह के सरणी बना सकते हैं, तो आपको प्रत्येक आवंटित ब्लॉक पिन करना होगा और आप सिस्टम को क्रॉल में धीमा कर देंगे।

लेकिन आप एक धारणा के आधार पर अनुकूलित करने की कोशिश कर रहे हैं। डॉटनेट में ऑब्जेक्ट्स का आवंटन और सफाई अत्यधिक अनुकूलित है। तो पहले एक वर्किंग प्रोग्राम लिखें और फिर अपनी बाधाओं को खोजने के लिए एक प्रोफाइलर का उपयोग करें। यह संभवतः आपकी वस्तुओं का आवंटन नहीं होगा।

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

संपादित करें, उत्तरार्द्ध जवाब देने के लिए।

मुझे लगता है कि सी # (या कोई भी प्रबंधित भाषा) जटिल डेटा संरचनाओं (कुशलतापूर्वक) का प्रतिनिधित्व करने में अधिक शक्तिशाली है। निम्न स्तर के पॉइंटर्स से कचरा एकत्रित संदर्भों में बदलकर।

+0

क्या प्रोफाइलर आप सुझाव है? – cons

+2

यह कारण नहीं हो सकता है, क्योंकि आप असुरक्षित संरचनाओं के अंदर अन्य असुरक्षित संरचनाओं के पॉइंटर्स का बहुत अच्छी तरह से उपयोग कर सकते हैं (इस तरह बाइनरी पेड़ संरचना बनाने में कोई समस्या नहीं है ...) प्रतिबंध केवल असुरक्षित structs के अंदर सरणी पर लागू होता है (जिसे निश्चित कहा जाता है आकार बफर), और इसका कारण मेरी राय में स्पष्ट नहीं है (संभावित स्पष्टीकरण के लिए मेरी प्रतिक्रिया देखें) – MartinStettner

+1

@cons: यह प्रश्न देखें: http://stackoverflow.com/questions/3927/ –

1

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

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

+0

दिलचस्प। क्या आप कुछ लेखों के लिए एक लिंक दे सकते हैं, या थोड़ा सा 16 बाइट क्यों समझा सकते हैं? –

+0

@Alexander: माइक्रोसॉफ्ट अपने दिशानिर्देशों में यही कहता है: http://msdn.microsoft.com/en-us/library/y23b5415%28VS.71%29.aspx – Guffa

+0

आकार सीमा जहां एक वर्ग एक से अधिक कुशल बन जाएगा संरचना उपयोग पैटर्न के साथ काफी भिन्न होता है। 16 बाइट से छोटे अपरिवर्तनीय वर्ग शायद ही कभी विपरीत परिदृश्यों के बाहर संरचनाओं की तुलना में अधिक कुशल होंगे, लेकिन कई उपयोग पैटर्न के साथ भी "बड़े" (64-256 बाइट्स) संरचनाएं कक्षाओं से बेहतर हो सकती हैं। कुछ उपयोग पैटर्न के लिए, संरचनाओं के लिए "जीतने वाला मार्जिन" वास्तव में बड़े पेलोड के साथ बढ़ता है (बशर्ते वे ढेर को तोड़ने के लिए इतने बड़े न हों)। – supercat

संबंधित मुद्दे