स्थिर और साझा पुस्तकालयों के बीच अंतर क्या है?
मैं ग्रहण का उपयोग करता हूं और स्टैटिक लाइब्रेरी और शेयर्ड लाइब्रेरी सहित कई प्रोजेक्ट प्रकार हैं? क्या एक का दूसरे पर फायदा है?
जवाबों:
साझा लाइब्रेरी हैं .so (या विंडोज .dll, या OS X .dylib में) फाइलें। लाइब्रेरी से संबंधित सभी कोड इस फ़ाइल में है, और इसे रन-टाइम पर इसका उपयोग करके प्रोग्राम द्वारा संदर्भित किया जाता है। एक साझा पुस्तकालय का उपयोग करने वाला एक कार्यक्रम केवल उस कोड का संदर्भ देता है जिसे वह साझा पुस्तकालय में उपयोग करता है।
स्टेटिक लाइब्रेरी एक .a (या विंडोज .lib) फाइलों में होती हैं। पुस्तकालय से संबंधित सभी कोड इस फ़ाइल में हैं, और यह सीधे संकलन समय पर कार्यक्रम में जुड़ा हुआ है। स्टैटिक लाइब्रेरी का उपयोग करने वाला प्रोग्राम उस कोड की कॉपी लेता है जिसे वह स्टैटिक लाइब्रेरी से उपयोग करता है और इसे प्रोग्राम का हिस्सा बनाता है। [विंडोज में .lib फाइलें भी हैं जो .dll फ़ाइलों को संदर्भित करने के लिए उपयोग की जाती हैं, लेकिन वे पहले की तरह ही कार्य करती हैं]।
प्रत्येक विधि में फायदे और नुकसान हैं:
साझा पुस्तकालय, प्रत्येक प्रोग्राम में डुप्लिकेट किए गए कोड की मात्रा को कम कर देते हैं जो कि बायनेरिज़ को छोटा रखते हुए लाइब्रेरी का उपयोग करता है। यह आपको साझा किए गए ऑब्जेक्ट को एक के साथ बदलने की अनुमति देता है जो कार्यात्मक रूप से समतुल्य है, लेकिन हो सकता है कि उस प्रोग्राम को फिर से शुरू करने की आवश्यकता के बिना प्रदर्शन लाभ जोड़ा जाए जो इसका उपयोग करता है। साझा पुस्तकालय, हालांकि कार्यों के निष्पादन के लिए एक छोटी सी अतिरिक्त लागत के साथ-साथ एक रन-टाइम लोडिंग लागत भी होगी क्योंकि पुस्तकालय में सभी प्रतीकों का उपयोग उन चीजों से जुड़ा होना चाहिए। इसके अतिरिक्त, साझा पुस्तकालयों को रन-टाइम पर एक एप्लिकेशन में लोड किया जा सकता है, जो बाइनरी प्लग-इन सिस्टम को लागू करने के लिए सामान्य तंत्र है।
स्टेटिक लाइब्रेरी बाइनरी के समग्र आकार को बढ़ाती है, लेकिन इसका मतलब है कि आपको उस लाइब्रेरी की एक कॉपी साथ ले जाने की आवश्यकता नहीं है जिसका उपयोग किया जा रहा है। जैसा कि कोड संकलन समय पर जुड़ा हुआ है, कोई अतिरिक्त रन-टाइम लोडिंग लागत नहीं है। कोड बस वहाँ है।
व्यक्तिगत रूप से, मैं साझा पुस्तकालयों को पसंद करता हूं, लेकिन यह सुनिश्चित करने के लिए स्थैतिक पुस्तकालयों का उपयोग करता हूं कि बाइनरी में कई बाहरी निर्भरताएं नहीं होती हैं, जिन्हें पूरा करना मुश्किल हो सकता है, जैसे कि C ++ मानक पुस्तकालय के विशिष्ट संस्करण या Boost C ++ पुस्तकालय के विशिष्ट संस्करण।
एक स्थैतिक पुस्तकालय एक किताबों की दुकान की तरह है, और एक साझा पुस्तकालय की तरह है ... एक पुस्तकालय। पूर्व के साथ, आप घर लेने के लिए पुस्तक / फ़ंक्शन की अपनी प्रति प्राप्त करते हैं; उत्तरार्द्ध के साथ आप और बाकी सभी लोग उसी पुस्तक / फ़ंक्शन का उपयोग करने के लिए लाइब्रेरी जाते हैं। तो जो कोई भी (साझा) पुस्तकालय का उपयोग करना चाहता है, उसे यह जानना होगा कि वह कहां है, क्योंकि आपको पुस्तक / फ़ंक्शन को "प्राप्त करना" है। एक स्थैतिक पुस्तकालय के साथ, पुस्तक / कार्य आपका स्वयं का है, और आप इसे अपने घर / कार्यक्रम के भीतर रखते हैं, और एक बार आपके पास यह है कि आपको इसकी परवाह नहीं है कि आपको यह कहाँ या कब मिला है।
सरलीकृत:
स्थैतिक पुस्तकालय के लिए, कोड को पुस्तकालय से लिंकर द्वारा निकाला जाता है और इसका उपयोग उस बिंदु पर अंतिम निष्पादन योग्य बनाने के लिए किया जाता है जिसे आप अपना आवेदन संकलित / निर्माण करते हैं। अंतिम निष्पादन योग्य समय पर पुस्तकालय पर कोई निर्भरता नहीं है
साझा लाइब्रेरी के लिए, कंपाइलर / लिंकर यह जाँचता है कि आपके द्वारा लिंक किए गए नाम लाइब्रेरी में मौजूद हैं जब एप्लिकेशन बनाया गया है, लेकिन उनके कोड को एप्लिकेशन में स्थानांतरित नहीं करता है। रन टाइम पर, साझा लाइब्रेरी उपलब्ध होनी चाहिए।
सी प्रोग्रामिंग भाषा में स्वयं स्थिर या साझा पुस्तकालयों की कोई अवधारणा नहीं है - वे पूरी तरह से एक कार्यान्वयन सुविधा हैं।
व्यक्तिगत रूप से, मैं स्थैतिक पुस्तकालयों का उपयोग करना पसंद करता हूं, क्योंकि यह सॉफ्टवेयर वितरण को सरल बनाता है। हालांकि, यह एक राय है कि अतीत में कितना (लाक्षणिक) रक्त बहाया गया है।
स्टेटिक लाइब्रेरी एक एप्लीकेशन के हिस्से के रूप में संकलित हैं, जबकि साझा लाइब्रेरी नहीं हैं। जब आप एक एप्लिकेशन वितरित करते हैं जो साझा किए गए काम पर निर्भर करता है, पुस्तकालयों, जैसे। MS Windows पर dll स्थापित करने की आवश्यकता है।
स्टैटिक लाइब्रेरियों का लाभ यह है कि एप्लिकेशन चलाने वाले उपयोगकर्ता के लिए कोई निर्भरता आवश्यक नहीं है - उदाहरण के लिए उन्हें अपने DLL को अपग्रेड करने की आवश्यकता नहीं है। नुकसान यह है कि आपका एप्लिकेशन आकार में बड़ा है क्योंकि आप इसे उन सभी पुस्तकालयों के साथ शिपिंग कर रहे हैं जिनकी इसे आवश्यकता है।
साथ ही छोटे अनुप्रयोगों के लिए अग्रणी, साझा पुस्तकालय उपयोगकर्ता को अपने स्वयं के उपयोग करने की क्षमता प्रदान करते हैं, शायद पुस्तकालयों के बेहतर संस्करण एक के बजाय उस अनुप्रयोग पर निर्भर होते हैं
साझा पुस्तकालयों का सबसे महत्वपूर्ण लाभ यह है कि मेमोरी में लोड किए गए कोड की केवल एक प्रति है, चाहे लाइब्रेरी कितनी भी प्रक्रिया का उपयोग कर रही हो। स्थिर पुस्तकालयों के लिए प्रत्येक प्रक्रिया को कोड की अपनी प्रति मिलती है। इससे महत्वपूर्ण मेमोरी अपव्यय हो सकता है।
ओटीओएच, स्टैटिक लाइब्रेरीज़ का एक फायदा यह है कि आपके एप्लिकेशन में सब कुछ बंडल है। इसलिए आपको यह चिंता करने की जरूरत नहीं है कि क्लाइंट के पास उनके सिस्टम पर उपलब्ध सही लाइब्रेरी (और संस्करण) उपलब्ध होगी।
.so* निक्स सिस्टम पर फाइलें थोड़े साझा (गतिशील) पुस्तकालय हैं।
अन्य सभी उत्तरों के शीर्ष पर, एक बात का उल्लेख नहीं किया गया है जो अभी तक डिकॉप्लिंग है:
मुझे एक वास्तविक विश्व उत्पादन कोड के बारे में बोलने दें, जो मैं के साथ काम कर रहा हूं:
एक बहुत बड़ा सॉफ्टवेयर,> 300 प्रोजेक्ट्स (विजुअल स्टूडियो के साथ) से बना है, जो ज्यादातर स्टैटिक लीब के रूप में निर्मित होता है और अंत में सभी लिंक एक साथ एक विशाल निष्पादन योग्य होते हैं, आप निम्नलिखित समस्याओं का अंत करते हैं:
-लिंक का समय बेहद लंबा होता है। आप लिंक के 15 मिनट से अधिक तक समाप्त हो सकते हैं, मान लें कि 10 का संकलन समय है-कुछ उपकरण अपने घुटने पर इतने बड़े निष्पादन योग्य हैं, जैसे कि मेमोरी चेक टूल जो कोड को इंस्ट्रूमेंट करना चाहिए। आप मूर्खों के रूप में देखी गई सीमाओं तक पहुँच सकते हैं।
अधिक समस्याग्रस्त आपके सॉफ़्टवेयर का डिकॉउलिंग है: इस वास्तविक विश्व उदाहरण पर, हर प्रोजेक्ट की हेडर फाइलें किसी भी अन्य प्रोजेक्ट से पहुंच योग्य थीं। परिणामस्वरूप एक डेवलपर के लिए निर्भरता जोड़ना बहुत आसान था; यह हेडर को शामिल करने के बारे में था, क्योंकि अंत में लिंक प्रतीकों का पता लगाएगा। यह भयानक साइकिलिंग निर्भरता और पूर्ण गड़बड़ी से समाप्त होता है।
साझा पुस्तकालय के साथ, यह थोड़ा अतिरिक्त काम है क्योंकि डेवलपर को आश्रित पुस्तकालय को जोड़ने के लिए प्रोजेक्ट बिल्ड सिस्टम को संपादित करना होगा। मैंने देखा कि साझा लाइब्रेरी कोड एक क्लीनर कोड एपीआई पेश करता है।
-------------------------------------------------------------------------
| +- | Shared(dynamic) | Static Library (Linkages) |
-------------------------------------------------------------------------
|Pros: | less memory use | an executable, using own libraries|
| | | ,coming with the program, |
| | | doesn't need to worry about its |
| | | compilebility subject to libraries|
-------------------------------------------------------------------------
|Cons: | implementations of | bigger memory uses |
| | libraries may be altered | |
| | subject to OS and its | |
| | version, which may affect| |
| | the compilebility and | |
| | runnability of the code | |
-------------------------------------------------------------------------