💃🏼 🏾 💱 हम C # से C ++ तक के पोर्टिंग उत्पादों को कैसे स्वचालित करते हैं 👩‍🍳 🥓 👁‍🗨

हेलो, हैबर। इस पोस्ट में मैं बात करूँगा कि हम C ++ भाषा के लिए पुस्तकालयों की मासिक रिलीज़ को व्यवस्थित करने में कैसे कामयाब रहे, इसका स्रोत कोड C # में विकसित किया गया है। यह प्रबंधित C ++ के बारे में नहीं है, या मानव रहित C ++ और CLR वातावरण के बीच एक पुल बनाने के बारे में भी है - यह C ++ कोड पीढ़ी को स्वचालित करने के बारे में है जो एपीआई और मूल C # कोड की कार्यक्षमता को दोहराता है।

हमने भाषाओं के बीच कोड का अनुवाद करने और स्वयं .Net पुस्तकालय के कार्यों का अनुकरण करने के लिए आवश्यक बुनियादी ढाँचा लिखा, इस प्रकार एक समस्या को हल करना जिसे आमतौर पर अकादमिक माना जाता है। इसने हमें C ++ भाषा के लिए प्री-डोनट्स उत्पादों की मासिक रिलीज़ जारी करने की अनुमति दी, साथ ही C # कोड के संबंधित संस्करण से प्रत्येक रिलीज़ के लिए कोड प्राप्त किया। इसी समय, मूल कोड को कवर करने वाले परीक्षणों को इसके साथ पोर्ट किया जाता है और आपको सी ++ में विशेष रूप से लिखित परीक्षणों के साथ परिणामी समाधान के प्रदर्शन को नियंत्रित करने की अनुमति मिलती है।

इस लेख में मैं संक्षेप में हमारी परियोजना के इतिहास और उसमें प्रयुक्त तकनीकों का वर्णन करूंगा। मैं केवल पारित करने में आर्थिक औचित्य के मुद्दों पर संपर्क करूंगा, क्योंकि तकनीकी पक्ष मेरे लिए बहुत अधिक दिलचस्प है। श्रृंखला के निम्नलिखित लेखों में, मेरी योजना कोड पीढ़ी और मेमोरी प्रबंधन, साथ ही कुछ अन्य लोगों पर है, अगर समुदाय के पास प्रासंगिक प्रश्न हैं।

पृष्ठभूमि

प्रारंभ में, हमारी कंपनी .Net मंच के लिए पुस्तकालयों की रिहाई में लगी हुई थी। ये पुस्तकालय मुख्य रूप से कुछ फ़ाइल स्वरूपों (दस्तावेज़, टेबल, स्लाइड, ग्राफिक्स) और प्रोटोकॉल (ईमेल) के साथ काम करने के लिए एपीआई प्रदान करते हैं, ऐसे समाधानों के लिए बाजार में एक निश्चित स्थान पर कब्जा कर रहे हैं। सभी विकास C # में आयोजित किए गए थे।

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

निर्णय को दो भागों में तोड़ने का निर्णय लिया गया। पहला - तथाकथित कुली - जावा के C # स्रोत कोड सिंटैक्स को एक साथ बदल देगा, साथ ही साथ .net प्रकार और विधियों को जावा पुस्तकालयों से अपने समकक्षों के साथ बदल देगा। दूसरा - लाइब्रेरी - .Net लाइब्रेरी के उन हिस्सों के काम का अनुकरण करेगा जिसके लिए उपलब्ध तृतीय-पक्ष घटकों का उपयोग करके, जावा के साथ सीधे पत्राचार स्थापित करना मुश्किल या असंभव है।

इस तरह की योजना की प्रमुख व्यवहार्यता के पक्ष में, निम्नलिखित बात की:

वैचारिक रूप से, सी # और जावा भाषा काफी समान हैं - कम से कम, प्रकार की संरचना और स्मृति के साथ काम के संगठन के साथ;
यह पुस्तकालयों को पोर्ट करने के बारे में था, जीयूआई को पोर्ट करने की कोई आवश्यकता नहीं थी;
, , - , System.Net System.Drawing;
, .Net ( Framework, Standard Xamarin), .

मैं विवरण में नहीं जाऊंगा, क्योंकि वे एक अलग लेख के लायक हैं (और एक नहीं)। मैं केवल यह कह सकता हूं कि विकास की शुरुआत से पहले जावा उत्पाद के रिलीज तक लगभग दो साल लग गए, और तब से जावा उत्पादों की रिहाई कंपनी का एक नियमित अभ्यास बन गया है। परियोजना के विकास के दौरान, पोर्टर एक साधारण उपयोगिता से विकसित हुआ है, जो स्थापित नियमों के अनुसार पाठ को परिवर्तित करता है, एक जटिल कोड जनरेटर को जो स्रोत कोड के एएसटी प्रतिनिधित्व के साथ काम करता है। पुस्तकालय भी कोड के साथ ऊंचा हो गया है।

जावा दिशा की सफलता ने कंपनी की खुद के लिए नए बाजारों में और विस्तार करने की इच्छा को निर्धारित किया, और 2013 में इसी तरह के परिदृश्य में सी ++ भाषा के लिए उत्पादों की रिहाई के बारे में सवाल उठाया गया था।

समस्या का निरूपण

उत्पादों के सकारात्मक संस्करणों की रिहाई सुनिश्चित करने के लिए, एक ऐसा ढांचा तैयार करना आवश्यक था जो आपको C # कोड को मनमाने ढंग से C # कोड प्राप्त करने की अनुमति दे, उसे संकलित करे, जाँच करे और ग्राहक को दे। यह पुस्तकालयों के बारे में था जिसमें कई सौ हजार से लेकर कई मिलियन लाइनें (निर्भरता को छोड़कर) थीं।

उसी समय, जावा कुली के साथ अनुभव को ध्यान में रखा गया था: शुरू में, जब यह सिंटैक्स को परिवर्तित करने के लिए सिर्फ एक सरल उपकरण था, तो पोर्टेड कोड को स्वाभाविक रूप से अंतिम रूप देने का अभ्यास उत्पन्न हुआ था। अल्पावधि में, उत्पादों की तेजी से रिलीज पर ध्यान केंद्रित किया गया था, यह प्रासंगिक था, क्योंकि इसने विकास प्रक्रिया में तेजी लाने की अनुमति दी थी, हालांकि, लंबी अवधि में, प्रत्येक बार हर अनुवाद त्रुटि को ठीक करने की आवश्यकता के कारण रिलीज के लिए प्रत्येक संस्करण को तैयार करने की लागत में काफी वृद्धि हुई।

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

कुली के अलावा, C ++ में एक पुस्तकालय विकसित करना भी आवश्यक था जो निम्नलिखित समस्याओं को हल करेगा:

काम करने के लिए पोर्ट कोड के लिए आवश्यक है कि इस हद तक .Net पर्यावरण का अनुकरण;
C ++ की वास्तविकताओं (प्रकार संरचना, स्मृति प्रबंधन, अन्य सेवा कोड) की पोर्टिंग C # कोड को अपनाना;
"पुनर्लेखन C #" और C ++ के बीच के अंतरों को चौरसाई करना, ताकि प्रोग्रामर के लिए पोर्ट कोड का उपयोग करने के लिए .net प्रतिमानों से परिचित न हों।

स्पष्ट कारणों के लिए, मानक पुस्तकालय से सीधे टाइप करने के लिए .Net प्रकारों के लिए कोई प्रयास नहीं किया गया था। इसके बजाय, यह हमेशा डोनेट प्रकारों के प्रतिस्थापन के रूप में अपनी लाइब्रेरी से प्रकारों का उपयोग करने का निर्णय लिया गया था।

कई पाठक तुरंत पूछेंगे कि उन्होंने मोनो जैसे मौजूदा कार्यान्वयन का उपयोग क्यों नहीं किया । उसके कारण थे।

इस तरह के एक तैयार पुस्तकालय को आकर्षित करने से, केवल पहली आवश्यकता को पूरा करना संभव होगा, लेकिन दूसरा नहीं और तीसरा नहीं।
Mono C# , , , .
(API, , , C++, ) , .
, .Net, . , , .

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

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

फ्रेमवर्क के लिए एक महत्वपूर्ण आवश्यकता यह थी कि पोर्ट किए गए कोड को उपयोगकर्ता अनुप्रयोगों (जहां तक पुस्तकालयों का संबंध था) के हिस्से के रूप में काम करने में सक्षम होना चाहिए। इसका मतलब है कि मेमोरी प्रबंधन मॉडल को C ++ प्रोग्रामर के लिए स्पष्ट किया जाना चाहिए था, क्योंकि हम कचरा संग्रहण वातावरण में चलाने के लिए ग्राहक कोड को मनमाना नहीं कर सकते। स्मार्ट पॉइंटर्स का उपयोग एक समझौता मॉडल के रूप में चुना गया था। इस तरह के संक्रमण (विशेष रूप से, परिपत्र संदर्भों की समस्या को हल करने के लिए) को सुनिश्चित करने में हम कैसे कामयाब रहे, इस बारे में मैं एक अलग लेख में चर्चा करूंगा।

एक अन्य आवश्यकता न केवल पुस्तकालयों को पोर्ट करने की क्षमता थी, बल्कि उनके लिए परीक्षण भी था। कंपनी अपने उत्पादों के परीक्षण कवरेज की एक उच्च संस्कृति का दावा करती है, और C ++ में चलने की क्षमता वही परीक्षण जो मूल कोड के लिए लिखे गए थे, अनुवाद के बाद समस्याओं की खोज को बहुत सरल करेंगे।

शेष आवश्यकताएं (लॉन्च प्रारूप, परीक्षण कवरेज, प्रौद्योगिकी, आदि) मुख्य रूप से परियोजना के साथ और परियोजना पर काम करने के तरीकों से संबंधित हैं। मैं उन पर नहीं बसूंगा।

कहानी

जारी रखने से पहले, मुझे कंपनी की संरचना के बारे में कुछ शब्द कहना होगा। कंपनी दूरस्थ रूप से काम करती है, इसमें सभी टीमों को वितरित किया जाता है। एक निश्चित उत्पाद का विकास आमतौर पर भाषा (लगभग हमेशा) और भूगोल (मुख्य रूप से) द्वारा एकजुट एक टीम की जिम्मेदारी है।

परियोजना पर सक्रिय कार्य 2013 के पतन में शुरू हुआ। कंपनी की वितरित संरचना के कारण, और विकास की सफलता के बारे में कुछ संदेह के कारण, फ्रेमवर्क के तीन संस्करणों को तुरंत लॉन्च किया गया था: उनमें से दो ने एक उत्पाद को सेवा दी, तीसरे ने एक बार में तीन को कवर किया। यह मान लिया गया था कि इससे यदि आवश्यक हो तो कम प्रभावी समाधान और वास्तविक संसाधनों के विकास को रोक दिया जाएगा।

भविष्य में, चार और टीमें "सामान्य" ढांचे पर काम में शामिल हुईं, जिनमें से दो ने बाद में अपने फैसले पर पुनर्विचार किया और सी ++ के लिए उत्पादों को जारी करने से इनकार कर दिया। 2017 की शुरुआत में, "व्यक्तिगत" समाधानों में से एक के विकास को रोकने और संबंधित टीम को "सामान्य" ढांचे के साथ काम करने के लिए स्थानांतरित करने का निर्णय लिया गया था। रुके हुए विकास ने बोहेम जीसी के उपयोग को स्मृति प्रबंधन के साधन के रूप में ग्रहण किया और सिस्टम लाइब्रेरी के कुछ हिस्सों का अधिक समृद्ध कार्यान्वयन किया, जिसे तब "सामान्य" समाधान में स्थानांतरित कर दिया गया था।

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

एक समान ढांचे पर स्वतंत्र रूप से काम करने वाली टीम ने 2018 में अपनी पहली C ++ रिलीज़ भी जारी की।

पहले रिलीज में मूल उत्पादों के छंटे हुए संस्करण शामिल थे, जो कि असम्पीडित भागों के प्रसारण के काम को जितना संभव हो उतना विलंबित करने की अनुमति देते थे। बाद के रिलीज में, कार्यक्षमता का एक अंश-वार जोड़ हुआ है (और हो रहा है)।

परियोजना पर काम का संगठन

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

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

काम के इस रूप में भी इसकी कमियां थीं, इसलिए भविष्य में एक और सुधार किया गया था। "केंद्रीय" टीम को बहाल किया गया था, हालांकि एक छोटी रचना में, लेकिन विभिन्न कार्यों के साथ: अब यह परियोजना के वास्तविक विकास के लिए जिम्मेदार नहीं था, लेकिन इस पर संयुक्त कार्य के संगठन के लिए। इसमें CI पर्यावरण के लिए समर्थन, मर्ज अनुरोध प्रथाओं का आयोजन, विकास प्रतिभागियों के साथ नियमित बैठकें करना, प्रलेखन का समर्थन करना, परीक्षणों को कवर करना, वास्तु समाधानों और समस्या निवारण के साथ मदद करना और इसी तरह शामिल थे। इसके अलावा, टीम ने तकनीकी ऋण और अन्य संसाधन-गहन क्षेत्रों को खत्म करने का काम किया। इस मोड में, विकास आज भी जारी है।

इस प्रकार, यह परियोजना कई (लगभग पाँच) डेवलपर्स के प्रयासों द्वारा शुरू की गई थी और सर्वोत्तम समय में लगभग बीस लोगों की संख्या थी। कुछ दस से पंद्रह लोग फ्रेमवर्क के विकास और समर्थन के लिए जिम्मेदार हैं और छह पोर्टेड उत्पादों की रिहाई को हाल के वर्षों में एक स्थिर मूल्य माना जा सकता है।

2016 के मध्य में इन पंक्तियों के लेखक कंपनी में शामिल हो गए, "कॉमन" समाधान का उपयोग करके अपने कोड को प्रसारित करने वाली टीमों में से एक में काम करना शुरू कर दिया। उसी वर्ष की सर्दियों में, जब "केंद्रीय" टीम को फिर से बनाने का निर्णय लिया गया, तो मैं उनकी टीम के नेता की स्थिति में चला गया। इस प्रकार, आज परियोजना में मेरा अनुभव साढ़े तीन साल से अधिक है।

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

टेक्नोलॉजीज

यह परियोजना में उपयोग की जाने वाली प्रौद्योगिकियों के बारे में बात करने का समय है। पोर्टर C # में लिखा गया एक कंसोल एप्लिकेशन है, क्योंकि इस रूप में उन स्क्रिप्ट्स में एम्बेड करना आसान है जो "पोर्ट-कंपाइल-रन टेस्ट" जैसे कार्य करते हैं। इसके अलावा, एक GUI घटक है जो आपको बटनों पर क्लिक करके समान लक्ष्य प्राप्त करने की अनुमति देता है।

प्राचीन NRefactory पुस्तकालय पार्सिंग कोड और हल करने के लिए जिम्मेदार है । दुर्भाग्य से, जिस समय यह परियोजना शुरू हुई थी, रोसलिन अभी तक उपलब्ध नहीं थी, हालांकि इसके लिए प्रवास, निश्चित रूप से, हमारी योजनाओं में है।

पोर्टर एएसटी लकड़ी के पैदल मार्ग का उपयोग करता हैजानकारी एकत्र करने और C ++ आउटपुट कोड उत्पन्न करने के लिए। जब C ++ कोड उत्पन्न होता है, तो AST प्रतिनिधित्व नहीं बनता है, और सभी कोड को सादे पाठ के रूप में सहेजा जाता है।

कई मामलों में, ठीक ट्यूनिंग के लिए कुली को अतिरिक्त जानकारी की आवश्यकता होती है। इस तरह की जानकारी उसे विकल्प और विशेषताओं के रूप में प्रेषित की जाती है। विकल्प पूरी परियोजना पर तुरंत लागू होते हैं और आपको सेट करने की अनुमति देते हैं, उदाहरण के लिए, कोड विश्लेषण में उपयोग किए जाने वाले वर्गों या सी # प्रीप्रोसेसर परिभाषाओं के निर्यात मैक्रो सदस्यों के नाम। विशेषताएँ प्रकार और संस्थाओं पर लटका दी जाती हैं और उनके लिए विशिष्ट प्रसंस्करण निर्धारित करती हैं (उदाहरण के लिए, वर्ग सदस्यों के लिए कीवर्ड "कॉन्स्टेबल" या "म्यूटेबल" उत्पन्न करने या उन्हें पोर्टिंग से बाहर करने की आवश्यकता)।

C # कक्षाएं और संरचनाएं C ++ कक्षाओं में अनुवादित की जाती हैं, उनके सदस्यों और निष्पादन योग्य कोड को निकटतम समकक्षों में अनुवादित किया जाता है। सामान्य प्रकार और विधियाँ C ++ टेम्प्लेट में मैप करती हैं। लाइब्रेरी में परिभाषित सी # लिंक स्मार्ट पॉइंटर्स (मजबूत या कमजोर) में अनुवादित हैं। कुली के सिद्धांतों के बारे में अधिक जानकारी एक अलग लेख में चर्चा की जाएगी।

इस प्रकार, मूल C # असेंबली C ++ प्रोजेक्ट में बदल जाती है, जिसके बजाय .Net लाइब्रेरीज़ हमारी साझा लाइब्रेरी पर निर्भर करती हैं। यह निम्नलिखित आरेख में दिखाया गया है:

लाइब्रेरी और पोर्ट किए गए प्रोजेक्ट के निर्माण के लिए cmake का उपयोग किया जाता है। संकलक वीएस 2017 और 2019 (विंडोज), जीसीसी और क्लैंग (लिनक्स) वर्तमान में समर्थित हैं।

जैसा कि ऊपर उल्लेख किया गया है, हमारे अधिकांश .नेट कार्यान्वयन तीसरे पक्ष के पुस्तकालयों की पतली परतें हैं जो काम का थोक काम करते हैं। उसमे समाविष्ट हैं:

स्किया - ग्राफिक्स के साथ काम करने के लिए;
बोटन - एन्क्रिप्शन कार्यों का समर्थन करने के लिए;
आईसीयू - स्ट्रिंग्स, एन्कोडिंग और संस्कृतियों के साथ काम करने के लिए;
Libxml2 - एक्सएमएल के साथ काम करने के लिए;
PCRE2 - नियमित अभिव्यक्तियों के साथ काम करने के लिए;
zlib - संपीड़न कार्यों को लागू करने के लिए;
बूस्ट - विभिन्न प्रयोजनों के लिए;
कई अन्य पुस्तकालय।

कुली और पुस्तकालय दोनों कई परीक्षणों में शामिल हैं। लाइब्रेरी टेस्ट gtest फ्रेमवर्क का उपयोग करते हैं। कुली परीक्षण मुख्य रूप से NUnit / xUnit में लिखे गए हैं और इन्हें प्रमाणित करते हुए कई श्रेणियों में बांटा गया है:

इन इनपुट फ़ाइलों पर पोर्टर आउटपुट लक्ष्य से मेल खाता है;
संकलन और लॉन्च के बाद पोर्ट किए गए कार्यक्रमों का आउटपुट लक्ष्य के साथ मेल खाता है;
इनपुट प्रोजेक्ट्स से NUnit परीक्षण सफलतापूर्वक पोर्ट की गई परियोजनाओं में gtest परीक्षणों में परिवर्तित हो जाते हैं और पास हो जाते हैं;
पोर्ट प्रोजेक्ट्स API C ++ में सफलतापूर्वक काम करता है;
अनुवाद प्रक्रिया पर व्यक्तिगत विकल्पों और विशेषताओं का प्रभाव अपेक्षित है।

हम सोर्स कोड को स्टोर करने के लिए GitLab का उपयोग करते हैं । जेनकिंस को सीआई वातावरण के रूप में चुना गया था । पोर्ट किए गए उत्पाद Nuget पैकेज और डाउनलोड अभिलेखागार के रूप में उपलब्ध हैं।

समस्या

परियोजना पर काम करते समय, हमें कई समस्याओं का सामना करना पड़ा। उनमें से कुछ की उम्मीद थी, जबकि अन्य पहले से ही इस प्रक्रिया में दिखाई दिए। हम मुख्य रूप से सूची देते हैं।

.Net C++.
, C++ Object, RTTI. .Net STL.
.
, , . , C# , C++ — .
.
— . , . , .
.
C++ , , .
C#.
C# , C++. , :
- , ;
- , (, yeild);
- , (, , , C#);
- , C++ (, C# foreground-).
.
, .Net , .
.
- , , «» , . , , , , using, -. . , .
.
, , , , , / - .
.
. , . , , , .
बौद्धिक संपदा के संरक्षण में कठिनाइयाँ।
यदि C # कोड बॉक्सिंग सॉल्यूशंस द्वारा आसानी से बाधित है, तो C ++ में आपको अतिरिक्त प्रयास करने होंगे, क्योंकि कई वर्ग के सदस्यों को बिना परिणामों के हेडर फ़ाइलों से हटाया नहीं जा सकता है। टेम्प्लेट में जेनेरिक कक्षाओं और विधियों का अनुवाद एल्गोरिदम को उजागर करके कमजोरियों को भी पैदा करता है।

इसके बावजूद, तकनीकी दृष्टिकोण से यह परियोजना बहुत दिलचस्प है। इस पर काम करने से आप बहुत कुछ सीख सकते हैं और बहुत कुछ सीख सकते हैं। कार्य की शैक्षणिक प्रकृति भी इसमें योगदान करती है।

सारांश

परियोजना के हिस्से के रूप में, हम एक ऐसी प्रणाली को लागू करने में सक्षम थे जो अपने प्रत्यक्ष व्यावहारिक अनुप्रयोग के लिए एक दिलचस्प शैक्षणिक समस्या को हल करती है। हमने कंपनी के पुस्तकालयों का एक मासिक मुद्दा एक भाषा में आयोजित किया, जिसके लिए वे मूल रूप से अभिप्रेत नहीं थे। यह पता चला कि अधिकांश समस्याएं पूरी तरह से हल करने योग्य हैं, और परिणामस्वरूप समाधान विश्वसनीय और व्यावहारिक है।

जल्द ही इसे दो और लेख प्रकाशित करने की योजना है। उनमें से एक विस्तार से वर्णन करेगा, उदाहरण के लिए, एक कुली कैसे काम करता है और C ++ में C # निर्माण कैसे प्रदर्शित होते हैं। एक अन्य भाषण में, हम इस बारे में बात करेंगे कि हम दो भाषाओं के मेमोरी मॉडल की संगतता सुनिश्चित करने में कैसे कामयाब रहे।

मैं टिप्पणियों में सवालों के जवाब देने की कोशिश करूंगा। यदि पाठक हमारे विकास के अन्य पहलुओं में रुचि दिखाते हैं और उत्तर टिप्पणियों में पत्राचार से परे जाने लगते हैं, तो हम नए लेखों को प्रकाशित करने की संभावना पर विचार करेंगे।

हम C # से C ++ तक के पोर्टिंग उत्पादों को कैसे स्वचालित करते हैं