क्रॉस-प्लेटफॉर्म संगतता (C ++) सुनिश्चित करने की तकनीक?


13

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

पहले से मौजूद क्या तकनीकें यह सुनिश्चित करती हैं कि कोड सभी प्लेटफार्मों के साथ संगत है? सभी प्लेटफार्मों को एक साथ विकसित करना, इस प्रकार एक ही समय में हर प्लेटफ़ॉर्म के खिलाफ कोड का परीक्षण करना, जब एक-दूसरे के बाद अलग-अलग प्लेटफ़ॉर्म संस्करणों को विकसित करने के बजाय नई सुविधाएँ जोड़ी जाती हैं? (*)

विशेष रूप से सलाह को देखते हुए कि यह उपकरण पर निर्भर नहीं है, बल्कि "विकास प्रक्रियाएं" हैं जो क्रॉस-प्लेटफ़ॉर्म संगतता की सहायता करती हैं, चाहे जो भी उपकरण का उपयोग किया जाए। ऊपर वाले (*) की तरह।


विशेष रूप से मैं WDL-OL ( https://github.com/olilarkin/wdl-ol ) और कुछ क्रॉस-प्लेटफ़ॉर्म DSP लाइब्रेरीज़ के साथ एक VST प्लग-इन विकसित कर रहा हूं । WDL-OL परियोजनाओं में VS और Xcode दोनों परियोजनाएं हैं, लेकिन मुझे लगता है कि समस्या पुस्तकालयों से आती है और फिर संकलक में अंतर होता है।


1
पोर्टेबिलिटी सुनिश्चित करने का कोई तरीका नहीं है, पोर्टेबिलिटी में सुधार / अधिकतम करने के केवल तरीके हैं
phuclv

और यह डुप्लिकेट क्यों नहीं है? मेरा मानना ​​है कि इसी तरह के बहुत सारे सवाल थे
phuclv

आपका आवेदन क्या कर रहा है? आप इसका उपयोग कैसे करेंगे? कमांड लाइन पर, या कुछ ग्राफिकल इंटरफ़ेस के माध्यम से? कृपया इसे बेहतर बनाने के लिए अपने प्रश्न को संपादित करें
बेसिल स्टारीनेवविच

और आप किस ढांचे का उपयोग कर रहे हैं?
बेसिल स्टारीनेवविच

जवाबों:


15

पोर्टेबल कोड बनाना बहुत चुनौतीपूर्ण हो सकता है।

पहले कुछ स्पष्ट भाषा संबंधी सलाह:

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

तो डिजाइन सिफारिशों के एक जोड़े:

  • समकक्ष ऑपरेटिंग सिस्टम कार्यक्षमता के लिए मानक पुस्तकालय विकल्प को प्राथमिकता दें
  • ऑपरेटिंग सिस्टम निर्भरता का यथासंभव उपयोग करें (उदाहरण के लिए, सशर्त संकलन के साथ नियंत्रित एक आवरण समारोह में)

अंत में नाजुक बिंदु:

  • वर्ण एन्कोडिंग: कई प्रणालियों पर आप utf8 पर भरोसा कर सकते हैं । लेकिन विंडोज के लिए यह अधिक नाजुक है क्योंकि सिस्टम या तो एएनएसआई या utf-16 की उम्मीद करता है। आप निश्चित रूप से (जैसे एक typedef पर भरोसा कर सकते TCHARहैं), लेकिन यह तो मानक पुस्तकालय के साथ संयोजन में चुनौती दे (जैसे हो सकता है coutबनाम wcoutप्रयोग की जाने वाली निर्भर करता है का उपयोग कर यदि charया wchar_t)
  • यदि GUI / ग्राफ़िक्स / उन्नत I / O के लिए आप एक पोर्टेबल लाइब्रेरी नहीं पा सकते हैं जो आपकी अपेक्षाओं / आवश्यकताओं के अनुरूप हो, तो OS- विशिष्ट घटकों को अलग करने के लिए समग्र आर्किटेक्चर डिज़ाइन करें। कई अलग-अलग इंटरैक्शन और अवधारणाओं को शामिल करने के कारण रैपर्स यहां पर्याप्त नहीं हो सकते हैं।
  • इस तरह के उदाहरण के लिए के रूप में कुछ दिलचस्प डिजाइन पैटर्न के लाभ ले लो सार कारखाने या (जैसे ओएस विशिष्ट यूआई में के रूप में संबंधित वस्तुओं के डिजाइन परिवार के लिए आदर्श) मध्यस्थ (संबंधित वस्तुओं के परिवारों के बीच सहयोग को लागू करने के लिए आदर्श) और उन्हें सशर्त संकलन के साथ एक साथ उपयोग ।

लेकिन ये केवल सलाह हैं। इस क्षेत्र में आप निश्चितता हासिल नहीं कर सकते।


-Wall -Wextra -Werror
पाइप

1
@ पिप आपको भी होना चाहिए -pedantic
5gon12eder

@ 5gon12eder इस उत्तर के संदर्भ में एक बहुत अच्छा बिंदु।
पाइप

11

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

निरंतर एकीकरण (CI) इस बोझ को छोटी परियोजनाओं के लिए काफी हद तक कम कर सकता है क्योंकि आप कुछ प्लेटफार्मों (ज्यादातर लिनक्स) के लिए सस्ते या मुफ्त बिल्ड एजेंट प्राप्त कर सकते हैं, विंडोज पर अपना विकास कर सकते हैं, और बस लिनक्स पर वापस लौट सकते हैं जब कोई समस्या होती है।

OSX CI हालांकि बहुत मुश्किल है।


कोई उल्लेख नहीं है, CI क्या है?
माविलज

5
निरंतर एकीकरण- मूल रूप से सर्वरों का एक समूह है जो आपके लिए बिल्ड और परीक्षण चलाते हैं।
डेडएमजी

@DeadMG आप का मतलब है मोज़िला टिंडरबॉक्स?
दामियन येरिक

1
ट्रैविस सीआई मुफ्त ओएसएक्स बिल्ड होस्ट
डेन्थ

बस Cmake का उपयोग करें।
राज

9

यदि आप "विकास प्रक्रियाओं" के लिए पूछ रहे हैं और आप प्राथमिक विकास मंच विजुअल स्टूडियो के साथ विंडोज हैं, तो मैं "windows.h" के बिना आपकी परियोजना के निर्माण की कोशिश करना चाहूंगा। आपको कई संकलन त्रुटियां मिलेंगी जो आपको कई स्थानों पर इंगित करेंगी जहां आपको अपने कोड को फिर से भरना होगा। उदाहरण के लिए, 'DWORD' को # परिभाषित नहीं किया जाएगा और आपको इसे uint32_tहर जगह (Google के लिए stdint.hऔर आपको पूर्णांक प्रकारों और उनकी क्रॉस-प्लेटफ़ॉर्म परिभाषाओं के बारे में उपयोगी जानकारी मिलेगी) को बदलने की आवश्यकता होगी। इसके बाद, आपको सभी कॉल को Win32 API से बदलना होगा, जैसे कि,Sleep()उनके क्रॉस-प्लेटफ़ॉर्म समकक्ष के साथ (फिर से, Google आपका सबसे अच्छा दोस्त है, जो स्टैक * .com साइटों में प्रासंगिक प्रश्न और उत्तर दिखाएगा)। आप शायद अपने कोड के लिए सभी प्रासंगिक क्रॉस-प्लेटफ़ॉर्म रिप्लेसमेंट खोजने में सफल नहीं होंगे और आपको अपना include "windows."निर्देश वापस करना होगा, लेकिन इसे यहाँ#ifdef _WIN32 और भी नीचे रखें -

अधिक ठोस प्रश्न पूछें और उत्तर प्राप्त करें - यह "विकास प्रक्रिया क्या होनी चाहिए" के लिए सामान्य सुझाव है

EDIT 1 मेरा एक और सुझाव है कि आप अपने विंडोज डेवलपमेंट मशीन (दृश्य स्टूडियो के साथ) पर gcc और / या क्लैंग का उपयोग करें।


3

यह आपके द्वारा उल्लिखित "कुछ संकलन त्रुटियों" पर निर्भर करता है। यह जानने के बिना कि वे क्या थे, विशिष्ट होना असंभव है।

मुझे Windows / Linux / iOS / Android / Mac के लिए क्रॉस-प्लेटफ़ॉर्म कोड मिल गया है। प्रत्येक नए प्लेटफ़ॉर्म को पहली बार जोड़े जाने पर कुछ अतिरिक्त त्रुटियाँ और चेतावनियाँ लाईं। आप जल्दी से सीखेंगे कि कौन सी समस्याएं समस्याएं लाती हैं। या तो उनसे बचें, या शीर्षकों के साथ मतभेदों को अमूर्त करें #ifdef#ifdefअपने कोड के भीतर प्लेटफ़ॉर्म के बीच कभी भी प्रयास न करें ।

एक उदाहरण:

void myfunction(MyClass &);
myfunction(MyClass());

एक अस्थायी उदाहरण बनाता है, MyClassजो myfunctionवापस आने के बाद हटा दिया जाता है । मेरे कुछ C ++ कंपाइलरों के साथ, वह उदाहरण पढ़ा / लिखा जाता है (और यह तथ्य कि यह अस्थायी है और जल्द ही नष्ट हो जाएगा, संकलक की चिंता नहीं करता है)। दूसरों के साथ, myfunctionए लेने के लिए पुनर्परिभाषित किया जाना चाहिए const MyClass &, या कंपाइलर शिकायत करता है। इससे कोई फर्क नहीं पड़ता कि C ++ मानक क्या कहता है, या कौन सा संकलक सही है और कौन सा गलत है। एक-दो बार त्रुटि का सामना करने के बाद, मैं (ए) को या तो अस्थायी प्रकार का घोषित करता हूं MyClassऔर पास myfunctionया (बी) के संदर्भ constमें घोषणा करता हूं और यहां और वहां myfunctionउपयोग mutableकरने के लिए डीकोस्टीफाई करता हूं।

निचला रेखा: अनुभव संचित करें और अपने स्वयं के कोडिंग मानकों का विकास करें।


2
यह MSVC की एक गलत विशेषता है। यदि आपकी बात यह है कि 1 सिस्टम पर विकसित होने से ये रेंगने की अनुमति देता है, तो पॉइंट लिया गया। लेकिन वह विशिष्ट चीज वह नहीं है जो आपको करनी चाहिए।
जुल्लुगोज़

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

1
या मैं कहूंगा कि क्रॉस-प्लेटफ़ॉर्म C ++ मानक से अधिक प्रतिबंधात्मक है जो कहता है। दूसरे शब्दों में, भले ही मानक ऐसा कहता है, फिर भी आप उन प्लेटफार्मों के लिए सबसे कम आम भाजक (या, कम से कम विक्रेता क्षमता) के अधीन हैं जिन्हें आपको समर्थन करना है। बहुत सारे ओपन-सोर्स लाइब्रेरी हैं जिन्हें सी ++ 11 को बाहर करना पड़ा क्योंकि उनके घटकों का एक हिस्सा (नागरिकों के रूप में) C ++ 11 में सक्षम नहीं है।
रोंगोंग

3

पोर्टेबिलिटी में मदद करने का एक संभावित तरीका केवल C ++ 11 मानक द्वारा प्रदान की गई घोषणाओं और सुविधाओं पर निर्भर हो सकता है , और POCO & Qt जैसे क्रॉस-प्लेटफॉर्म लाइब्रेरी और फ्रेमवर्क का उपयोग करके ।

लेकिन यह भी फेल-प्रूफ नहीं है। कामोद्दीपन को याद रखें

पोर्टेबल प्रोग्राम जैसी कोई चीज नहीं है, केवल ऐसे प्रोग्राम हैं जिन्हें सफलतापूर्वक पोर्ट किया गया है (कुछ विशेष प्लेटफॉर्म पर)

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


1
एक और सलाह यह है कि, जब पोर्टिंग अलग-अलग लोगों और टीम द्वारा की जाती है, तो कोड में बदलाव को मेनलाइन में फिर से एकीकृत किया जाना चाहिए। अन्यथा, प्लेटफ़ॉर्म अंतर टीम द्वारा किए गए एक ज्ञान हो जाता है जो उसने किया था।
rwong
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.