संयोजन सी ++ और सी #

Question

क्या सी ++ और सी # को गठबंधन करना अच्छा विचार है या क्या यह किसी भी तत्काल मुद्दे को उत्पन्न करता है?

मेरे पास एक ऐसा एप्लिकेशन है जिसके लिए कुछ हिस्सों को सी ++ होने की आवश्यकता है, और कुछ हिस्सों में सी # (बढ़ी दक्षता के लिए) होना चाहिए। सी # में देशी सी ++ डीएल का उपयोग करने का सबसे अच्छा तरीका क्या होगा?

Answer 1

हाँ आपके उत्पाद के लिए सी # और सी ++ का उपयोग करना बहुत आम है और एक अच्छा विचार है।

कभी-कभी आप प्रबंधित सी ++ का उपयोग कर सकते हैं, इस मामले में आप किसी भी अन्य .NET मॉड्यूल की तरह अपने प्रबंधित C++ मॉड्यूल का उपयोग कर सकते हैं।

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

यहाँ सी # में एक DLL के अंदर एक सी समारोह आयात करने का एक उदाहरण है:

[DllImport("user32", CharSet=CharSet.Auto, SetLastError=true)] 
internal static extern int GetWindowText(IntPtr hWnd, [Out, MarshalAs(UnmanagedType.LPTStr)] StringBuilder lpString, int nMaxCount); 

Answer 2

सवाल यह है कि उसकी सी # समाधान के लिए अपने ही सी ++ कोड को एकीकृत करने के लिए, बस नहीं किस क्रम में उपयोग करने के लिए विशेषता स्पष्ट रूप से है Win32 API से मौजूदा फ़ंक्शन को कॉल करने के लिए। भले ही उत्तर पहले ही स्वीकार कर लिया गया हो, मुझे लगता है कि यह अपूर्ण है, और निम्नलिखित लागू होना चाहिए।

हां, यह उन मामलों में सामान्य प्रथा है जहां कार्य या तो तेजी से चल सकता है, कम संसाधनों का उपयोग कर सकता है, और कुछ मामलों में भी .net फ्रेमवर्क में उपलब्ध विधियों तक पहुंचने के लिए।

अपने लक्ष्य दक्षता आप एक देशी अप्रबंधित सी ++ पुस्तकालय कोड करने के लिए की जरूरत है हासिल करने के लिए है, तो आप एक नया अप्रबंधित सी ++ परियोजना (है कि एक dll पुस्तकालय के रूप में संकलित) दृश्य स्टूडियो और संदर्भ अपने सी # परियोजना से इस पुस्तकालय में पैदा करेगा ।

आपके मामले में ऐसा लगता है कि आप एक अप्रबंधित सी ++ लाइब्रेरी लिख रहे हैं, और निम्नलिखित लागू होते हैं।

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

• परिनियोजन: ध्यान रखें कि सी # DLLs आप किसी भी सीपीयू पर चलेगा निर्माण, दोनों 32 और 64 बिट, लेकिन इस नए देशी और अप्रबंधित सी ++ पुस्तकालय अपने कार्यक्रम के लिए बाध्य करेगा होने के लिए या तो 32 के लिए या 64 विशिष्ट।

  यह आपके दृश्य स्टूडियो विन्यास प्रबंधक में कुछ आप कॉन्फ़िगर जाएगा है, और संकलन समय का ध्यान रखा जाना होगा, आप, सी # विधानसभाओं के लिए और अपने नए अप्रबंधित सी ++ पुस्तकालय के लिए AnyCPU ले जाएगा, जिसमें हो जाएगा यह अपनी परियोजना है, Win32 या x64 से चुनने के लिए आपके पास होगा।

  तो अब 2 सेटअप होगा, यह सबसे अच्छा अभ्यास की सिफारिश की अलग व्यवस्था, 32 के लिए एक और 64 के लिए या 32 बिट के बाद से समर्थन बहुत तेजी से गिर रही है एक और एक है करने के लिए है, तो आप 64 बिट पर ध्यान केंद्रित कर सके केवल।

  इसके अलावा, आपकी लाइब्रेरी विजुअल स्टूडियो द्वारा प्रदान किए गए वीसी ++ रेडिस्टिब्यूटेबल को संदर्भित कर सकती है, जिसे आपको अपनी तैनाती में शामिल करना पड़ सकता है, हालांकि इसमें से कुछ संस्करण कई ओएस पर शामिल हैं, मुझे लगता है कि यह शायद ही कभी संकलित है साथ ही यह सुनिश्चित करने के लिए अपने आवेदन के साथ इसे तैनात करना सबसे अच्छा है। यदि यह पैक गुम है, तो लक्ष्य मशीन में eventviewer-> एप्लिकेशन लॉग में SideBySide अपवाद होगा।

  अप्रबंधित कोड से निकाले गए अपवाद को पकड़ने और संभालने के लिए, केवल एक ही पकड़ जो काम करता है वह खाली है, जिसे कैच() के बाद कोष्ठक में कोई अपवाद प्रकार नहीं है। इसलिए यदि आप एक .net प्रकार जैसे कैच (अपवाद) डालते हैं, तो आप अप्रबंधित कोड के अंदर से हटाए गए सभी अप्रबंधित अपवादों को संभालने के लिए अपनी कॉल को अप्रबंधित कोड में लपेट सकते हैं, यह केवल उस पर कूद जाएगा। एक अप्रबंधित अपवाद को पकड़ने का एकमात्र तरीका, प्रबंधित कोड के अंदर इस प्रारूप में है।

    try 
    { 
     //call unmanaged code 
    } 
    catch 
    { 
     //handle unmanaged exception 
    } 

• कहानियो: कोई भी पद्धति जो अब बुला रहे हैं अप्रबंधित कोड सी # से किया कॉल अब स्वचालित रूप से नाम बदलने से बाहर रखा जाएगा। और दूसरा पहलू पर, अपने अप्रबंधित सी ++ पुस्तकालय की जरूरत है अपने प्रबंधित विधानसभाओं से तरीकों कॉल करने के लिए, उन आदेश सी ++ पुस्तकालय उन्हें बुला को दिखाई करने के लिए, का नाम बदलने के लिए, मैन्युअल से बाहर रखा होने की आवश्यकता होगी।

आपको क्या चाहिए केवल Windows लोगों की तरह अच्छी तरह से ज्ञात सी ++ पुस्तकालयों कॉल करने के लिए है, तो आप एक नया अप्रबंधित सी ++ प्रोजेक्ट बनाने के लिए की जरूरत नहीं होगी ही पिछले एक जवाब में उपयोग [DllImport()] सुझाव विशेषता। और इस मामले में आप एक बार देख इस संदर्भ में http://www.pinvoke.net/

Answer 3

अतिरिक्त जानकारी के बारे में सी # बनाम सी ++ मतभेद लेते हैं और उन्हें विलय मुद्दों possibles सकता है:

• सी # एक व्याख्या की, जावा की तरह है। सी ++ देशी बाइनरी में संकलित है। निम्नलिखित बिंदुओं में आगे कई मतभेदों को समझाया गया है।
• प्लेटफार्म संगतता: सी #, व्याख्या और माइक्रोसॉफ्ट उत्पाद के रूप में, यह विंडोज़ पर ठीक काम करता है, लिनक्स पर सही ढंग से एक महान परियोजना Mono के लिए धन्यवाद, लेकिन अन्य प्लेटफार्मों (एंड्रॉइड, आईओएस, अन्य) पर यह अच्छी तरह से (या बिल्कुल नहीं) ।) यदि आप एम्बेडेड के लिए सॉफ़्टवेयर लिखना चाहते हैं जहां ऑपरेटिंग सिस्टम का कोई समर्थन नहीं है, या ओएस लिखने के लिए, तो आप ज्यादातर सी # का उपयोग नहीं कर सकते हैं। जैसे ही आपके पास एक कंपाइलर होता है (सी आमतौर पर मामला होता है) सी ++ पूरी तरह क्रॉस-प्लेटफार्म है।
• व्याख्याित कोड आमतौर पर बाइनरी कोड [1] की तुलना में धीमी गति का एक क्रम होता है। यही कारण है कि आप सी ++ लिंक का उपयोग करेंगे।
• बाइनरी बनाम इंटरमीडिएट कोड: किसी विशिष्ट आर्किटेक्चर पर उपलब्ध किसी भी दुभाषिया पर इंटरमीडिएट कोड काम, सी ++ को प्रत्येक आर्किटेक्चर के लिए पुन: संकलन की आवश्यकता होती है।
• सीखने की अवस्था: डेवलपर को कई भाषाओं को सीखना आवश्यक है, जो सीखने का समय बढ़ाते हैं। दोनों भाषाओं में विशेषज्ञों को ढूंढना भी मुश्किल है।
• आईडीई: सी ++ के लिए, कोई टेक्स्ट-एडिटर पर्याप्त है, सी # के लिए आपको अधिकतर विशिष्ट आईडीई की आवश्यकता होगी।
• रीयल-टाइम: सी # के साथ वास्तविक समय की स्थितियों की कल्पना करना मुश्किल लगता है।
• सी # कोड (महत्वपूर्ण सॉफ्टवेयर) के साथ कुछ गुणवत्ता प्रमाणन असंभव हो सकता है।

क्या उन्हें गठबंधन करना एक अच्छा विचार है?

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

---

[1] मैं कई बार है कि व्याख्या कोड भी तेजी से बाइनरी कोड की तुलना में कुछ मामले में है पढ़ते हैं, यह एक गलत धारणा की वजह से है: दुभाषिया सुविधा के लिए कई कार्य को लागू करता है, इसलिए जब आप फोन (जैसे) सॉर्ट(), हकीकत में यह इस फ़ंक्शन के बाइनरी कार्यान्वयन को कॉल करता है। यदि यह फ़ंक्शन अच्छी तरह से अनुकूलित किया गया है, तो अंतिम समय तेज़ हो सकता है, लेकिन सिर्फ इसलिए कि द्विआधारी और व्याख्या किए गए घटक में चलने वाले सभी सॉर्ट करने के लिए आवश्यक समय की तुलना में न्यूनतम हैं। दूसरी ओर, यदि आप दोनों भाषाओं में एक पूर्ण तर्क कोड करते हैं, तो बाइनरी संस्करण हमेशा महत्वपूर्ण रूप से तेज़ होगा। कारण सरल है: एक दुभाषिया एक बाइनरी है जो आपके कोड के अलावा, सभी भाषा ढांचे के अलावा चलता है।