2008-11-23 7 views
8

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

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

किसी भी ज्ञान के लिए धन्यवाद!

उत्तर

4

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

अब आप स्थिर .NET में कड़ी बातें करना चाहते हैं, तो आप या तो

  • मर्ज एक भी विधानसभा में कई विधानसभाओं से कक्षाएं हैं। इससे कई चीजें तोड़ जाएंगी, जैसे "आंतरिक" एक्सेस संशोधक।
  • एक ही निष्पादन योग्य में एक से अधिक असेंबली है।हालांकि असेंबली की पूरी अवधारणा को बेकार कर दिया जाएगा, और .NET Framework में प्रतिबिंब के दृष्टिकोण को फिर से डिजाइन करने की आवश्यकता होगी।

मुझे यकीन है कि इन समस्याओं से बचने के लिए एक चालाक तरीका है, लेकिन मुझे .NET या Java जैसे प्रबंधित वातावरण में स्थिर रूप से लिंक करने का बिंदु बिल्कुल दिखाई नहीं देता है। मेरा मतलब है, स्थिर रूप से जोड़ने से वास्तव में प्रदर्शन में सुधार होता है, लेकिन इतना नहीं। और हम वैसे भी प्रबंधित निष्पादन गति के लिए प्रबंधित भाषाओं का उपयोग नहीं करते हैं।

एक और मुद्दा डीएलएल नरक है, लेकिन .NET में, यह वैसे भी एक हल मुद्दा है।

+25

एक .exe और 30 .dll की बजाय एक .exe रखना चाहते हैं, यह एक बिल्कुल अच्छा कारण है - मेरे ग्राहकों को केवल 30+ फ़ाइलों को खींचना नहीं चाहिए क्योंकि मैं अपने सॉफ़्टवेयर को कई परियोजनाओं में दोबारा बनाना चाहता हूं। और मैं नहीं देखता कि आपने जो भी कहा है, वह * जिस तरह से है - वह मूल रूप से .exe में .dll को संग्रहीत कर सकता है, और इसकी आवश्यकता होने पर इसे .dll की तरह लोड कर सकता है। कोई अच्छा कारण नहीं है कि स्थिर लिंकिंग का समर्थन क्यों नहीं किया जा सकता है। –

+2

मैंने हाल ही में सीखा है कि एफ # वास्तव में इसका समर्थन करता है। –

+0

यहां एक कामकाज है, बस सुनिश्चित करें कि संसाधन नाम आपकी वास्तविक असेंबली को इंगित करता है: http://blogs.msdn.com/b/microsoft_press/archive/2010/02/03/jeffrey-richter-excerpt-2-from-clr -विया-सी-थर्ड-संस्करण.aspx – Kaganar

7

एक स्थैतिक रूप से निष्पादन योग्य में सभी ऑब्जेक्ट्स की आवश्यकता होती है ताकि निष्पादित होने पर कोई बाहरी डीएलएल नहीं बुलाया जा सके। फायदे यह है कि बहुत सारे प्लेटफॉर्म पर पोर्टेबल है इससे कोई फर्क नहीं पड़ता कि उस प्रणाली पर डीएलएल का संस्करण किस प्रकार स्थापित किया गया है। बड़ा नुकसान यह है कि आप संभवतः डिस्क स्पेस बर्बाद कर रहे हैं क्योंकि आप अपने निष्पादन योग्य कोड में शामिल हैं जो सिस्टम/बाहरी डीएलएल में पहले से मौजूद है। इसके अलावा मुझे लगता है, लेकिन मुझे पूरा यकीन नहीं है कि डीएलएल केवल एक बार मुख्य मेमोरी में लोड होते हैं, इससे कोई फर्क नहीं पड़ता कि कितने एक्जिक्यूटिव उनका उपयोग कर रहे हैं, लेकिन यदि आप स्थिर रूप से लाइब्रेरी ऑब्जेक्ट्स को अपने निष्पादन योग्य के अंदर लिंक करते हैं तो आप एक ही कोड को दो बार लोड करते हैं (एक डीएलएल के लिए बाकी कार्यक्रमों और आपके निष्पादन योग्य के लिए उपयोग किया जाता है)। दूसरी तरफ यह एक लाभ के बजाय एक लाभ हो सकता है, क्योंकि निष्पादन योग्य में बाहरी पुस्तकालयों की केवल वस्तुएं होती हैं, जिन्हें पूरी लाइब्रेरी की आवश्यकता होती है। जब एक एप्लिकेशन को इसकी आवश्यकता होती है तो पूरी तरह से एक डीएलएल स्मृति में लोड होता है।

स्टेटिक लिंकिंग छोटे ऐप्स को संकलित करने के लिए आदर्श है जिसे आप एक सिस्टम से दूसरे सिस्टम में ले जाना चाहते हैं। अर्थात। यह मेरे लिए वास्तव में उपयोगी था जब टीसीपीडम्प का एक स्थिर रूप से संकलित संस्करण हो, जब इसे प्रत्येक लिनक्स डिस्ट्रो में शामिल नहीं किया गया था। यह प्रत्येक लिनक्स पर काम करने के लिए बाध्य था इससे कोई फर्क नहीं पड़ता कि कर्नेल, ग्लिबैक या अन्य सिस्टम पुस्तकालयों का संस्करण क्या था। शायद विंडोज़ दुनिया में इतना ज्यादा समझ नहीं है क्योंकि प्लेटफ़ॉर्म अधिक homogeneus हैं। यदि आप Windows XP/NET vX.X के लिए संकलित करते हैं तो यह बहुत सारे कंप्यूटरों पर काम करेगा। यदि आप डेबियन एक्स.एक्स के लिए कुछ संकलित करते हैं तो यह निश्चित रूप से पुराने/नए डेबियन या रेडहाट जैसे अन्य डिस्ट्रोज़ पर काम नहीं करेगा।

यह thread आपके प्रश्न भी हल कर सकते हैं।

7

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

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

1

स्थैतिक बनाम गतिशील लिंकिंग के बीच अंतर का एक अच्छा उदाहरण है। यदि आप इंकस्केप प्रोजेक्ट को देखते हैं तो आपको InkscapePortable और इंकस्केप मिलेगा। इंकस्केप पोर्टेबल यूएसबी स्टिक को चलाएगा। इंकस्केप नहीं होगा।

2

सभी आवश्यक सामान निष्पादन योग्य में पैक किए जाते हैं। तो,

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

निश्चित रूप से निष्पादन योग्य फ़ाइल का आकार बढ़ जाएगा लेकिन यह मूर्ख ग्राफिक्स फ़ाइलों के गुच्छा से छोटा होना चाहिए।

+0

जो लोग निर्भरता नरक की कीमत पर डिस्क स्थान को कम करने के बारे में सोचते हैं, उनकी प्राथमिकताएं पीछे की ओर हैं –