मुझे पता है कि यह एक पुराना धागा है, लेकिन किसी ने भी एबीआई इंटरफेस या विशिष्ट संकलक मुद्दों का उल्लेख नहीं किया है। तो मुझे लगा कि मैं करूंगा।
यह मूल रूप से आप की अवधारणा पर आधारित है या तो लोगों को वितरित करने के लिए एक हेडर के साथ एक पुस्तकालय लिख रहा है या अपने आप को पुन: उपयोग कर रहा है बनाम हेडर में सब कुछ है। यदि आप एक हेडर और सोर्स फाइल्स को पुनः प्रयोग करने और हर प्रोजेक्ट में इनका पुनः उपयोग करने की सोच रहे हैं तो यह वास्तव में लागू नहीं होता है।
मूल रूप से यदि आप अपना C ++ कोड संकलित करते हैं और एक संकलक के साथ एक पुस्तकालय का निर्माण करते हैं, तो उपयोगकर्ता एक अलग संकलक या उसी संकलक के एक अलग संस्करण के साथ उस पुस्तकालय का उपयोग करने की कोशिश करता है तो आपको बाइनरी अपूर्णता के कारण लिंकर त्रुटियों या अजीब क्रम व्यवहार मिल सकता है।
उदाहरण के लिए संकलक विक्रेता अक्सर संस्करणों के बीच एसटीएल के अपने कार्यान्वयन को बदलते हैं। यदि आपके पास लाइब्रेरी में कोई फ़ंक्शन है जो एक std :: वेक्टर को स्वीकार करता है, तो यह उम्मीद करता है कि उस कक्षा में बाइट्स को उसी तरह व्यवस्थित किया जाए जब वे लाइब्रेरी संकलित किए गए थे। यदि, एक नए संकलक संस्करण में, विक्रेता ने std :: वेक्टर के लिए दक्षता में सुधार किया है, तो उपयोगकर्ता का कोड नई कक्षा को देखता है जिसमें एक अलग संरचना हो सकती है और उस नई संरचना को आपके पुस्तकालय में पास कर सकती है। सब कुछ वहाँ से नीचे चला जाता है ... यही कारण है कि पुस्तकालय की सीमाओं के पार एसटीएल वस्तुओं को पारित नहीं करने की सिफारिश की जाती है। यही बात C रन-टाइम (CRT) प्रकारों पर लागू होती है।
सीआरटी के बारे में बात करते समय, आपके पुस्तकालय और उपयोगकर्ता के स्रोत कोड को आम तौर पर उसी सीआरटी के खिलाफ जोड़ा जाना चाहिए। Visual Studio के साथ यदि आप Multithreaded CRT का उपयोग करके अपनी लाइब्रेरी का निर्माण करते हैं, लेकिन उपयोगकर्ता Multithreaded Debug CRT के विरुद्ध लिंक करता है, तो आपको लिंक समस्याएँ होंगी क्योंकि आपकी लाइब्रेरी को वे प्रतीक नहीं मिल सकते हैं जिनकी उसे आवश्यकता है। मुझे याद नहीं है कि यह कौन सा समारोह था, लेकिन विजुअल स्टूडियो 2015 के लिए माइक्रोसॉफ्ट ने एक सीआरटी फ़ंक्शन इनलाइन बनाया। अचानक यह हेडर में था न कि CRT लाइब्रेरी इसलिए लाइब्रेरीज़ जो कि लिंक टाइम पर इसे ढूंढने की उम्मीद करती थीं, अब ऐसा नहीं कर सकती हैं और इस तरह की गलतियाँ हो सकती हैं। नतीजा यह हुआ कि इन पुस्तकालयों को विजुअल स्टूडियो 2015 के साथ पुन: निर्माण की आवश्यकता थी।
यदि आप Windows API का उपयोग करते हैं तो आप लिंक त्रुटियां या अजीब व्यवहार भी प्राप्त कर सकते हैं, लेकिन आप लाइब्रेरी उपयोगकर्ता के लिए अलग-अलग यूनिकोड सेटिंग्स के साथ निर्माण करते हैं। ऐसा इसलिए है क्योंकि विंडोज एपीआई में फ़ंक्शन हैं जो यूनिकोड या एएससीआईआई स्ट्रिंग्स और मैक्रोज़ / डिफाइन का उपयोग करते हैं जो प्रोजेक्ट के यूनिकोड सेटिंग्स के आधार पर स्वचालित रूप से सही प्रकार का उपयोग करते हैं। यदि आप लाइब्रेरी की सीमा के पार एक स्ट्रिंग पास करते हैं जो गलत प्रकार है तो रनटाइम पर चीजें टूट जाती हैं। या आप पा सकते हैं कि कार्यक्रम पहली जगह में लिंक नहीं करता है।
ये चीजें अन्य तृतीय पक्ष पुस्तकालयों (जैसे एक ईगन वेक्टर या जीएसएल मैट्रिक्स) से पुस्तकालय की सीमाओं के पार वस्तुओं / प्रकारों को पारित करने के लिए भी सही हैं। यदि तृतीय पक्ष पुस्तकालय आपके पुस्तकालय को संकलित करने के बीच आपके हेडर को बदल देता है और आपका उपयोगकर्ता उनके कोड को संकलित करता है तो चीजें टूट जाएंगी।
मूल रूप से सुरक्षित होने के लिए केवल वही चीजें जो आप लाइब्रेरी सीमाओं के पार कर सकते हैं, वे प्रकारों और सादे पुराने डेटा (POD) में निर्मित हैं। आदर्श रूप से कोई भी पीओडी उन संरचनाओं में होना चाहिए जो आपके स्वयं के हेडर में परिभाषित हैं और किसी तीसरे पक्ष के हेडर पर निर्भर नहीं हैं।
यदि आप केवल हेडर प्रदान करते हैं, तो सभी कोड समान संकलक सेटिंग्स के साथ संकलित हो जाते हैं और एक ही हेडर के खिलाफ होते हैं, तो इनमें से बहुत सारी समस्याएं दूर हो जाती हैं (तीसरे आंशिक पुस्तकालयों के संस्करण प्रदान करना जो आपके और आपके उपयोगकर्ता उपयोग एपीआई संगत हैं)।
हालांकि ऐसे नकारात्मक हैं जो ऊपर उल्लेख किए गए हैं, जैसे कि संकलन का समय। इसके अलावा, आप एक व्यवसाय चला रहे हैं ताकि आप अपने सभी उपयोगकर्ताओं को चोरी करने के मामले में अपने सभी स्रोत कोड कार्यान्वयन विवरण अपने सभी उपयोगकर्ताओं को सौंपना न चाहें।