मैंने SWIG का उपयोग नहीं किया है, इसलिए मैं सीधे उससे बात नहीं कर सकता। लेकिन मैं pretty familiarInline::CPP के साथ हूं।
यदि आप सी ++ कोड लिखना चाहते हैं जो संकलित हो जाता है और पर्ल के भीतर से कॉल करने योग्य हो जाता है, तो इनलाइन :: सीपीपी इसे सुविधाजनक बनाता है। जब तक सी ++ कोड नहीं बदलता है, तब तक इसे केवल एक बार संकलित करना चाहिए। यदि आप इनलाइन :: सीपीपी पर एक मॉड्यूल का आधार रखते हैं, तो कोड मॉड्यूल इंस्टॉल समय पर संकलित किया जाएगा, इसलिए कोई अन्य उपयोगकर्ता वास्तव में पहली बार संकलन अंतराल को कभी नहीं देखता है; यह परीक्षण चरण से ठीक पहले, स्थापित समय पर होता है।
इनलाइन :: सीपीपी पोर्टेबिलिटी इश्यू से 100% मुक्त नहीं है। लक्ष्य उपयोगकर्ता के पास एक सी ++ कंपाइलर होना चाहिए जो कि सीएल कंपाइलर को पर्ल बनाने के लिए उपयोग किए जाने वाले समान स्वाद का होता है, और सी ++ मानक पुस्तकालय उन संस्करणों का होना चाहिए जो पर्ल के साथ बाइनरी-संगत कोड उत्पन्न करते हैं। इनलाइन :: सीपीएपी के पास सीपीएएन परीक्षकों के साथ 94% सफलता दर है। और उन अंतिम 6% लगभग हमेशा स्थापना प्रक्रिया के मुद्दों पर उबालते हैं जो सी ++ कंपाइलर और पुस्तकालयों का उपयोग करने के लिए सही ढंग से समझ नहीं लेते हैं। ... और उनमें से, यह आमतौर पर पुस्तकालयों के लिए आता है।
आइए मान लें कि एक मॉड्यूल लेखक आपको उस 95% में ढूंढता है जिसे इनलाइन :: सीपीपी स्थापित करने में कोई समस्या नहीं है। यदि आप जानते हैं कि आपके लक्षित दर्शक उसी श्रेणी में आ जाएंगे, तो इनलाइन :: सीपीपी के आधार पर एक मॉड्यूल तैयार करना सरल है। आपको मूल रूप से कुछ निर्देश (संस्करण और NAME) जोड़ना होगा, और अपने Makefile.PL के ExtUtils :: मेकमेकर कॉल इनलाइन :: मेकमेकर (यह ExtUtils :: MakeMaker का आह्वान करेगा) को स्वैप करना होगा। जब आप अपना वितरण बनाते हैं तो आप ExtUtils :: MakeMaker के वर्तमान संस्करण को निर्दिष्ट करने के लिए CONFIGURE_REQUIRES निर्देश भी प्राप्त कर सकते हैं; यह बीमा करता है कि आपके उपयोगकर्ताओं के पास क्लीनर इंस्टॉल अनुभव है।
अब यदि आप सामान्य खपत के लिए मॉड्यूल बना रहे हैं और आपको पता नहीं है कि आपका लक्ष्य उपयोगकर्ता उस 94% बहुमत को फिट करेगा जो इनलाइन :: सीपीपी का उपयोग कर सकता है, तो आप इनलाइन :: सीपीपी निर्भरता को हटाने से बेहतर हो सकते हैं। आप वैसे भी निर्भरता श्रृंखला को कम करने के लिए ऐसा करना चाहते हैं; यह आपके उपयोगकर्ताओं के लिए अच्छा है। उस स्थिति में, इनलाइन :: सीपीपी के साथ काम करने के लिए अपना कोड लिखें, और फिर इनलाइनएक्स :: सीपीपी 2 एक्सएस का उपयोग इसे सादे पुराने एक्सएस मॉड्यूल में बदलने के लिए करें। आपका उपयोगकर्ता अब इनलाइन :: सीपीपी को पहली बार खींचने की प्रक्रिया के बिना इंस्टॉल करने में सक्षम होगा।
सी ++ एक बड़ी भाषा है, और इनलाइन :: सीपीपी इसका एक बड़ा सबसेट संभालती है। यह निर्धारित करने के लिए टाइपमैप फ़ाइल पर ध्यान दें कि पैरामीटर को किस तरह से पारित किया जा सकता है (और रूपांतरित) स्वचालित रूप से, और "गेट्स और एपीआई" कॉल का उपयोग करके किस प्रकार बेहतर तरीके से निपटाया जाता है। एक सुविधा जो मैं अनुशंसा नहीं करता हूं स्वचालित स्ट्रिंग रूपांतरण है, क्योंकि यह यूनिकोड-असभ्य रूपांतरण उत्पन्न करेगा। एपीआई कॉल के माध्यम से स्पष्ट रूप से तारों को संभालने के लिए बेहतर है।
सी ++ का हिस्सा जो इनलाइन :: सीपीपी द्वारा गहन रूप से संभाला नहीं गया है टेम्पलेट मेटाप्रोग्रामिंग है। आप अपने कोड में टेम्पलेट्स का उपयोग करने के लिए स्वतंत्र हैं, और एसटीएल का उपयोग करने के लिए स्वतंत्र हैं। हालांकि, आप बस एसटीएल प्रकार के पैरामीटर पास नहीं कर सकते हैं और आशा करते हैं कि इनलाइन :: सीपीपी उन्हें कन्वर्ट करने के बारे में जानेंगे। यह पीओडी (मूल डेटा प्रकार) से संबंधित है, एसटीएल सामान नहीं। इसके अलावा, यदि आप टेम्पलेट-आधारित फ़ंक्शन या ऑब्जेक्ट विधि लिखते हैं, तो C++ कंपाइलर यह नहीं जान पाएगा कि पर्ल ने फ़ंक्शन को कॉल करने की क्या योजना बनाई है, इसलिए यह नहीं पता कि संकलन पर टेम्पलेट पर किस प्रकार का उपयोग करना है। नतीजतन, इनलाइन :: सीपीपी को सीधे सामने आने वाले कार्यों और ऑब्जेक्ट विधियों को सादे कार्य या विधियों की आवश्यकता होती है; टेम्पलेट फ़ंक्शन या कक्षाएं नहीं।
अभ्यास में ये सीमाएं तब तक निपटने में मुश्किल नहीं हैं जब तक आप जानते हों कि क्या उम्मीद करनी है। यदि आप सीधे टेम्पलेट क्लास को इनलाइन :: सीपीपी में बेनकाब करना चाहते हैं, तो बस एक रैपर क्लास लिखें जो या तो टेम्पलेट क्लास के उत्तराधिकारी या रचना करता है, लेकिन यह इनलाइन :: सीपीपी के साथ काम करने के लिए एक ठोस प्रकार देता है।
इनलाइन :: सीपीपी मौजूदा सी ++ पुस्तकालयों के लिए स्वचालित रूप से फ़ंक्शन रैपर उत्पन्न करने में भी उपयोगी है। दस्तावेज बताता है कि यह कैसे करें।
इनलाइन :: बड़ा घूँट से अधिक सीपीपी को लाभ यह है कि अगर आप पहले से perlguts, perlapi, और perlcall के साथ कुछ अनुभव है, तो आप सही घर पर पहले से ही महसूस होगा है। स्विग के साथ, आपको पहले चीजों को करने का स्विग तरीका सीखना होगा, और उसके बाद पर्ल पर इसे लागू करने के तरीके को समझना होगा, और संभवतः, सीपीएएन-वितरित करने योग्य तरीके से इसे कैसे करें।
इनलाइन :: सीपीपी का उपयोग करने का एक अन्य लाभ यह है कि यह पर्ल समुदाय में कुछ हद तक परिचित उपकरण है। आपको बहुत अधिक लोग मिलेंगे जो पर्ल एक्सएस, इनलाइन :: सी, और कुछ हद तक इनलाइन :: सीपीपी को समझेंगे, जिन लोगों ने पर्ल के साथ स्विग का इस्तेमाल किया है। हालांकि एक्सएस गन्दा हो सकता है, यह एक सड़क है जो स्विग के साथ पर्ल का उपयोग करने से अधिक यात्रा करती है।
इनलाइन :: सीपीपी [email protected] मेलिंग सूची पर भी एक आम विषय है। अपने आप के अलावा, इनलाइन :: सी और कई अन्य इनलाइन-पारिवारिक रखरखाव के रखरखाव सूची में अक्सर रहते हैं, और मॉड्यूल के इनलाइन परिवार के साथ हाथ रखने की आवश्यकता वाले लोगों की सहायता करने के लिए हमारी पूरी कोशिश करते हैं।
आपको यह भी पता लगाने में उपयोगी my Perl Mongers talk on Inline::CPP मिल सकता है कि यह आपके लिए कैसे काम कर सकता है। इसके अतिरिक्त, Math::Prime::FastSieve इनलाइन :: सीपीपी (इनलाइन :: सीपीपी निर्भरता के साथ) पर एक मॉड्यूल के आधार पर सबूत-ऑफ-अवधारणा के रूप में खड़ा है। इसके अलावा, रोब (सिसिफस), वर्तमान इनलाइन रखरखाव, और इनलाइनएक्स :: सीपीपी 2 एक्सएस के लेखक ने वास्तव में InlineX::CPP2XS वितरण में एक उदाहरण शामिल किया है जो मेरा मैथ :: प्राइम :: फास्टसिव लेता है और इसे अपने इनलाइनएक्स :: का उपयोग करके सादा एक्सएस कोड में परिवर्तित करता है। CPP2XS।
नहीं, लगभग सभी एक्सएस मॉड्यूल हैंड-लिखित (सादा एक्सएस) हैं या [इनलाइनएक्स :: सी 2 एक्स एस] (http://p3rl.org/InlineX::C2XS) के साथ बूटस्ट्रैप किए गए हैं, केवल अल्पसंख्यक की सहायता से उत्पन्न अल्पसंख्यक । – daxim
@daxim: thanx, प्रश्न – kobame