पी/सी पुस्तकालय लपेटने के लिए सी /+/सीएलआई

Question

एक मध्यम आकार (40-विषम फ़ंक्शन) सी एपीआई है जिसे सी # प्रोजेक्ट से कॉल करने की आवश्यकता है। फ़ंक्शन लॉजिकल रूप से कुछ कक्षाएं बनाने के लिए टूट जाते हैं जो API के बाकी प्रोजेक्ट को प्रस्तुत किए जाएंगे।

क्या मजबूतता, रखरखाव, तैनाती, ... के संदर्भ में उस एपीआई के नीचे इंटरऑपरेबिलिटी के लिए पी/इनवोक या सी ++/सीएलआई को प्राथमिकता देने का कोई उद्देश्य कारण है?

मुद्दों मैं की है कि हो सकता है सोच सकता है, लेकिन समस्या पैदा करने वाले नहीं हैं:

• C++/CLI एक अलग विधानसभा, पी/आवश्यकता होगी आह्वान कक्षाएं मुख्य विधानसभा में हो सकता है। (हमें पहले से ही कई असेंबली मिल चुकी हैं और सी डीएलएस भी होंगे, इसलिए कोई बड़ी समस्या नहीं है)।
• प्रदर्शन दो विधियों के बीच अलग-अलग दिखाई नहीं देता है।

मुद्दे है कि मैं के बारे में यकीन नहीं है कर रहे हैं:

• मेरे लग रहा है, C++/CLI हो, तो अंतर-सेशन समस्या डिबग करने के लिए आसान हो जाएगा है कि यह सच है?
• भाषा परिचितता पर्याप्त लोगों को सी # और सी ++ पता है लेकिन सी ++/सीएलआई के विवरण का ज्ञान दुर्लभ है।

और कुछ और?

Answer 1

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

सी ++/सीएलआई एक महान तकनीक है, लेकिन आईएमएचओ इसके दस्तावेज इंटरऑप विशिष्ट परिदृश्यों के लिए पीएनवोक की तुलना में सीमित है। इसमें पीनोवोक के इंटरऑप समाधानों के लिए टूलींग इंफ्रास्ट्रक्चर भी नहीं है। एक परिदृश्य के लिए सी ++/सीएलआई असेंबली जोड़ना जिसे PInvoke के साथ हल किया जा सकता है, वह मेरे लिए बहुत महंगा लगता है।

दूसरी तरफ, यदि मैं एक बड़ी सी ++ लाइब्रेरी के साथ काम कर रहा हूं, तो मैं थोड़ा और सी ++/सीएलआई पर विचार करता हूं। PInvoke C++ के साथ काम नहीं करता है, और मुझे किसी प्रकार की इंटरमीडिएट परत जोड़ने को समाप्त करना होगा। अंतराल को पुल करने के लिए सभी सी ++ फ़ंक्शन कॉल या सी ++/सीएलआई लाइब्रेरी को लपेटने के लिए या तो एक छोटी सी परत। सी ++/सीएलआई इस मामले में मेरे लिए थोड़ा और अधिक प्राकृतिक महसूस करता है।

Answer 2

सी ++/सीएलआई डीबग करना आसान होगा यदि आपके पास ऐसे कर्मचारी हैं जो सी ++ को डीबग करने के बारे में जानते हैं। यदि आप नहीं करते हैं, तो यह संभवतः अधिक कठिन हो सकता है।

मैं सुझाव दूंगा कि यहां पर ट्रेडऑफ आपके इंटरऑप असेंबली के उपभोक्ताओं के लिए आसानी से असेंबली के लिए रखरखाव की आसानी के उपयोग के बीच है। यदि आपके पास वरिष्ठ इंजीनियरों का एक ठोस कोर है जो सी ++ से परिचित हैं और जो असहाय रूप से असेंबली को बनाए रख सकते हैं, तो आपकी शेष टीम पर यह बहुत आसान होगा जो देशी कोड से अपरिचित हैं ताकि उन्हें पूरी तरह से प्रबंधित इंटरफ़ेस दिया जा सके। उनके लिए सब कुछ।

दूसरी तरफ, यदि आप सी ++ अनुभव के साथ दुकान में एकमात्र व्यक्ति हैं, तो मैं परियोजना में सी ++ मॉड्यूल को एम्बेड करने के लिए बहुत उत्साहित हूं, अगर किसी और को इसे बाद में बनाए रखना है।

Answer 3

पी/आवेक प्लेटफ़ॉर्म आमंत्रण के रूप में सोचें, क्या आप Win32 API की तरह कुछ कॉल कर रहे हैं जो बहुत पी/Invoc अनुकूल है या क्या आपको एक अप्रबंधित लाइब्रेरी के लिए .NET बाइंडिंग प्रदान करने की आवश्यकता है?

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

यदि आप अतिरिक्त डीएलएल से छुटकारा पाने के लिए चाहते हैं तो आप हमेशा आईएलएमर्ज का प्रयास कर सकते हैं, लेकिन मुझे यकीन नहीं है कि यह मिश्रित असेंबली, (apparently not) को संभालने में सक्षम है, लेकिन ऐसा लगता है कि प्रबंधित और अप्रबंधित दोनों को लिंक करना संभव है * इस तरह PlatformSDK लिंकर साथ .obj फ़ाइलें:

cl.exe /MD /c /clr Unmanaged.cpp 
csc.exe /target:module /addmodule:*.obj Managed.cs 
link.exe /DLL /LTCG /NOENTRY /CLRIMAGETYPE:IJW *.obj Managed.netmodule 

Answer 4

यहाँ अच्छा जवाब में से बहुत सारे - एक और परिप्रेक्ष्य मौजूदा सी एपीआई के लिए योजना है। PInvoke प्रयोग करने के लिए तर्क में शामिल हैं:

• आप
• आप इसे बड़ी है और प्रवास के रूप में सी में कोड रखने की जरूरत भी महंगा
है अन्य सी उपभोक्ताओं के साथ संगतता के लिए चारों ओर एक सी एपीआई रखने की जरूरत है

C++/CLI उपयोग करने के लिए तर्क में शामिल हैं:

• आप ले जाना चाहते संभव के रूप में कोड CLR

को इस मामले में आप C++/CLI के साथ शुरू कर सकते हैं और फिर और अधिक और सी #

Answer 5

जाने वाले स्थानों पर ले जाने के इस आकार (के एक एपीआई के लिए ~ 40 कुल प्रविष्टि के रूप में ज्यादा अंक), मैं C++/CLI और P/Invoke के बीच विभाजित रेखा को आकर्षित करता हूं, इस पर आधारित है कि आपको "हेडर फ़ाइल गंक" कितनी सी # में डुप्लिकेट करना है। यदि यह एक छोटी (मामूली) राशि है, तो पी/आमंत्रण ठीक है। एक बार जब आप बहुत से डुप्लिकेट करना शुरू कर देते हैं। सी # में फ़ाइलें - विशेष रूप से उन चीजों के लिए जो आपके .NET API में प्रकट नहीं होती हैं - आप C++/CLI का उपयोग करके बेहतर हो सकते हैं।

Answer 6

यह बड़े हिस्से में निर्भर करता है कि मेमोरी स्वामित्व कैसे संभाला जाता है। पी/आवेषण केवल मार्शल पॉइंटर्स कर सकते हैं जब स्मृति प्रबंधन दो विशेष तरीकों में से एक है, आमतौर पर कॉलर-आवंटित बफर। यदि आपका एपीआई पॉइंटर्स लौटाता है (रिटर्न वैल्यू या आउट पैरामीटर के माध्यम से, इससे कोई फर्क नहीं पड़ता) और उम्मीद है कि उन्हें बाद में विनाश समारोह में सौंप दिया जाएगा ... पी/आवेक या तो स्वचालित मार्शलिंग करेगा या आपको पॉइंटर तक सीधे पहुंच देगा मूल्य जो आपको बाद में भेजने की जरूरत है, दोनों कभी नहीं। तो सी ++/सीएलआई उस मामले में एक बहुत वांछनीय दृष्टिकोण बन जाता है।