मान लें कि आप केवल सी ++ दुनिया में काम करते हैं (क्रॉस-भाषा इंटरऑप आवश्यक नहीं है)। एक सादे मूल डीएलएल के बजाय COM का उपयोग करने में आप क्या फायदे/असुविधाजनक देखते हैं? क्या आपको लगता है कि COM का उपयोग परेशानी के लायक है यदि आप विभिन्न भाषाओं से इंटरफ़ेस का उपयोग नहीं कर रहे हैं?एक सादा डीएलएल पर COM का उपयोग करने का क्या फायदा है?
कॉम के लिए सादे पुराने सी ++ में उपयोगी हो सकता है:
उस ने कहा, अगर आपको इसकी आवश्यकता नहीं है, तो इसका उपयोग न करें।
कुछ अतिरिक्त सुविधाओं है कि आप मिल गया है रहे हैं। इन दिनों COM समर्थन की आवश्यकता के बिना भी लेनदेन समर्थन प्रवाह कर सकते हैं।
IUnknown इंटरफ़ेस वैसे भी समर्थन करने के लिए एक अच्छा आधार स्तर है - आप पुराने ग्राहकों (QueryInterface) और व्यापक संदर्भ गिनती को तोड़ने के बिना सुविधाओं को जोड़ने के लिए एक रास्ता हो जाता है। आप COM में सब कुछ खरीदने के बिना इसे कार्यान्वित कर सकते हैं।
फिर, जब भी आप कक्षा में कोई सुविधा जोड़ रहे हों, तो यदि आप इसके लिए COM इंटरफ़ेस का उपयोग करते हैं, तो आपको कम से कम एक इंटरफ़ेस मिलता है - उदाहरण के लिए यदि आप प्रतिबिंब सुविधाओं को चाहते हैं तो IDISpatch।
आपका केवल डेल्टा सक्षम किया जा रहा से दूर किसी अन्य भाषा से कहा जा तो पंजीकरण और वर्ग कारखाना होगा।
DLL के साथ आप बहुत करीब युग्मन प्राप्त कर सकते हैं, COM बातचीत को सीमित करता है, जबकि बहुत ठीक। यह फायदे और नुकसान दोनों की जड़ है!
आपको अधिक शक्ति और लचीलापन मिलता है (उदा। डीएलएल में परिभाषित कक्षाओं से प्राप्त, COM में व्यवहार्य नहीं) लेकिन निर्भरता इस प्रकार बहुत मजबूत है (उपयोगकर्ता को डीएलएल में कुछ बदलावों के लिए पुनर्निर्माण की आवश्यकता है)।
अक्सर विशेष रूप से पिटाई यह है कि सभी डीएलएल और EXE को समान प्रकार की रनटाइम लाइब्रेरी और विकल्पों का उपयोग करना चाहिए (उदाहरण के लिए सभी गतिशील रूप से msvcrt* के गैर-डीबग मल्टीथ्रेड संस्करण से जुड़ा हुआ है - केवल एक का उपयोग करने के लिए पुनर्निर्माण नहीं कर सकता बहुत संभावित त्रुटियों के बिना डीबग संस्करण!)।
कॉम के हारने युग्मन जब तक आप वास्तव में एक विशेष मामले (में बातचीत के करीब-युग्मन प्रकार की जरूरत है जैसे, एक रूपरेखा है, जो निश्चित रूप से अपनी कक्षाओं से इनहेरिट करना उपयोगकर्ता के कोड की आवश्यकता है, एक होना चाहिए, अक्सर बेहतर इसलिए है DLL)।
क्योंकि इंटरफेस किसी भी विशेष डीएलएल से अपने सबसे सरल स्तर पर स्वतंत्र हैं, कम से कम दृष्टिकोण पर एक COM आपको कम से कम एक इंटरफ़ेस की सेवा करने वाले डीएल को बदलने के लिए स्वतंत्र करता है, बिना नए डीएल नाम के विरुद्ध अपने ऐप को दोबारा इकट्ठा किए बिना ।
एमआईडीएल परिभाषित इंटरफेस और प्रॉक्सी स्टब डीएलएस के साथ पूर्ण COM का उपयोग करने का अर्थ है कि आप थ्रेड सुरक्षा इन-प्रोसेस, उसी पीसी पर इंटरप्रोसेस कॉमर्स को प्रबंधित करने के लिए COM का उपयोग कर सकते हैं, या यहां तक कि दूरस्थ पीसी पर COM सर्वर ऑब्जेक्ट से कनेक्ट भी कर सकते हैं।
वास्तव में सच नहीं है। यदि आप फ़ंक्शन परिभाषा को नहीं बदलते हैं और केवल कार्यान्वयन को बदलते हैं तो आपको अपने ऐप को फिर से कंपाइल करने की आवश्यकता नहीं है - केवल डीएलएल। यदि आप फ़ंक्शंस के हस्ताक्षर बदलते हैं, तो आपको सीधे डीएलएल या COM का उपयोग करने के लिए पुन: संकलित करने की आवश्यकता होगी। –
मेरा मतलब था। डीएलएल का नाम बदलना, समारोह नहीं। कॉम मॉड्यूल हां, अपने अनुप्रयोग डिजाइन में कुछ साल, आप a.dll, b.dll और c.dll बनाए रखने के लिए बंद नहीं अलग करता।आप COM ऑब्जेक्ट्स को बड़े डीएलएस में स्वतंत्र रूप से मर्ज कर सकते हैं, या उन अनुप्रयोगों को और अधिक विभाजित कर सकते हैं जैसे आपके अनुप्रयोगों को विकसित करने की आवश्यकता है। –
हर कोई COM के प्लस कॉलम में मौजूद चीजों का उल्लेख कर रहा है। मैं कुछ विचलन का उल्लेख करूंगा।
जब आप COM का उपयोग कर अपने सिस्टम को लागू, आप कॉम 'सर्वर' रजिस्टर करने की आवश्यकता सेट अप के समय (वे इन-proc या बाहर के proc हो) और उन्हें स्थापना रद्द करें पर अपंजीकृत। यह आपके सेटअप सिस्टम की जटिलता को थोड़ा बढ़ा सकता है और रीबूट की आवश्यकता होती है जब तक कि उपयोगकर्ता पहले चल रही प्रक्रियाओं को सावधानी से नीचे नहीं डालता।
COM एक ही काम करने के अन्य मानक तरीकों की तुलना में धीमी है। यह टिप्पणी शायद बहुत नफरत और शायद कुछ डाउनवॉट उत्पन्न करेगी, लेकिन इस तथ्य का तथ्य यह है कि किसी बिंदु पर आपको डेटा को मार्शल करना होगा, और यह महंगा है।
COM के नियमों के मुताबिक, एक बार इंटरफ़ेस प्रकाशित होने पर इसे कभी भी बदला नहीं जा सकता है। यह स्वयं में नकारात्मक नहीं है, और आप यह भी तर्क दे सकते हैं कि यह आपको इंटरफ़ेस शिपिंग करने से पहले पूरी तरह से डिज़ाइन करने के लिए मजबूर करता है। लेकिन सच्चाई यह है कि ऐसी कोई चीज नहीं है, और उत्पादन कोड इंटरफेस में बदलती है। निस्संदेह आपको विधियों को जोड़ने या मौजूदा तरीकों के हस्ताक्षर बदलने की आवश्यकता होगी। इसे पूरा करने के लिए आपको या तो COM के नियमों को तोड़ना होगा - जिनके खराब प्रभाव हैं - या COM के नियमों का पालन करें जो एक फ़ंक्शन में पैरामीटर जोड़ने से अधिक जटिल हैं जैसे कि आप एक अस्थिर DLL के साथ करेंगे।
> COM की तुलना धीमी है ... <मैं असहमत हूं। COM "सक्रिय" या "instanciating" होने पर केवल "धीमा" होता है। एक बार ऑब्जेक्ट बनने के बाद, जितना तेज़ हो उतना तेज़ हो सकता है। चाहे सक्रियण/निर्माण समय महत्वपूर्ण है समस्या के विनिर्देशों पर निर्भर करता है। साथ ही, कॉम केवल कॉल में धीमा है यदि आप अपार्टमेंट पार करते हैं, तो आपको केवल तभी करना चाहिए जब आपको "इसकी आवश्यकता हो" (जिस स्थिति में आपको किसी अन्य वैकल्पिक अपमान के तहत समान धीमी गति की आवश्यकता होगी)। प्रदर्शन आमतौर पर COM का उपयोग न करने का एक कारण नहीं है। –
यदि आप इसका उपयोग नहीं कर सकते हैं। मेरे आखिरी प्रोजेक्ट में कॉम ने सी ++ इंटरफेस में इस्तेमाल होने वाली बहुत सी सीमाएं लाईं। बस कल्पना करें, कि आप बस एक std :: स्ट्रिंग पास नहीं कर सकते हैं लेकिन पात्रों की एक सरणी का उपयोग करना है। उस स्थिति में आप स्ट्रिंग का निर्माण करते हैं, फिर उसे एक सरणी में कॉपी करें जिसे COM द्वारा नियंत्रित किया जा सकता है।
आप केवल मौलिक प्रकारों के बहुत सीमित सेट का उपयोग कर सकते हैं, पास और स्वामित्व मेमोरी प्रबंधन कर सकते हैं। आप नए/डिलीट का उपयोग नहीं कर सकते हैं, लेकिन COM अपने कार्यों का उपयोग करना होगा।
तुम भी बस एक अपवाद फेंक नहीं सकते हैं, लेकिन कुछ COM इंटरफेस IErrorInfo है, जो दूसरे छोर पर rethrown हो जाएगा प्रारंभ करने की है।
तो यदि आपको आवश्यकता नहीं है, तो इसका उपयोग न करें। यह निश्चित रूप से आपके डिजाइन को पेंच करेगा। और यदि आप इसे ज़रूरत है, अन्य इंटरॉप संभावनाओं का मूल्यांकन करने का प्रयास करें: बढ़ावा :: इंटरप्रोसेस, zeroc बर्फ ...
सादर,
Ovanes
यहां एक अनुमान है: यदि आप डीएलएल का उपयोग करते हैं तो आपको std :: string के आस-पास गुजरने में भी यही समस्या हो सकती है। इससे बचने का एकमात्र तरीका डीएलएल और क्लाइंट कोड के लिए एक ही कंपाइलर का उपयोग करना है। अधिक विशेष रूप से, std :: स्ट्रिंग का एक ही कार्यान्वयन। –
हाँ मुझे पता है। हमने सभी परियोजनाओं के लिए एक ही कंपाइलर का इस्तेमाल किया। लेकिन वर्णित std :: स्ट्रिंग समस्या अलग-अलग प्रकृति भी हो सकती है। जब आप एक ही कंपाइलर के साथ भी अपने प्रोजेक्ट में मानक lib के विभिन्न कार्यान्वयन का उपयोग करते हैं। – ovanes
हाँ पूरी तरह सहमत हूँ - जब तक आप इसे की जरूरत है, यह अक्सर अधिक है मुसीबत। – stephbu
आमेन। COM और प्रौद्योगिकियों कि इसके साथ जाना OLE और जहाँ हम अब कुछ है कि आप के लिए जब तक आप इसे टाल नहीं सकते पीछे करना चाहते हैं नहीं हैं, लेकिन बीच एक बड़ा स्टेपिंग बिंदु थे। COM की प्राथमिक कठिनाई यह है कि आप स्वयं को हाथों से कर पाएंगे जो अन्य समाधान पृष्ठभूमि में हल होते हैं। – quillbreaker