क्या एम्बेडेड विकास के लिए C ++ के बजाय C का उपयोग करने का कोई कारण है?


82

सवाल

मेरे हार्डवेयर C ++ और C89 में दो कंपाइलर हैं

मैं कक्षाओं के साथ C ++ का उपयोग करने के बारे में सोच रहा हूं, लेकिन बहुरूपता के बिना (vtables से बचने के लिए)। C ++ का उपयोग करने के मुख्य कारण हैं:

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

क्या आपको बहुत सीमित हार्डवेयर (4kb of RAM) के लिए विकसित होने के दौरान C89 से चिपके रहने का कोई कारण दिखाई देता है?

निष्कर्ष

आपके उत्तर के लिए धन्यवाद, वे वास्तव में मददगार थे!

मुझे लगा कि इस विषय के माध्यम से और मैं मुख्य रूप से सी के साथ रहना होगा क्योंकि:

  1. सी में वास्तविक कोड की भविष्यवाणी करना आसान है और यह वास्तव में महत्वपूर्ण है यदि आपके पास केवल 4kb है RAM।
  2. मेरी टीम में मुख्य रूप से C डेवलपर्स हैं, इसलिए उन्नत C ++ सुविधाओं का अक्सर उपयोग नहीं किया जाएगा।
  3. मैंने अपने C कंपाइलर (C89) में इनलाइन फ़ंक्शंस का एक तरीका ढूंढ लिया है।

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


11
एक बात: हमेशा पूरी तरह से स्पष्ट होना चाहिए कि आप किस भाषा में लिख रहे हैं। "C / C ++" में प्रोग्राम लिखने की कोशिश न करें। C में लिखें, या C ++ में लिखें, यह जानते हुए कि आप कौन सी भाषा का उपयोग करेंगे और जो आप नहीं करेंगे।
डेविड थॉर्नले

1
यह भी देखें stackoverflow.com/questions/649789/...
सुमा

"एम्बेडेड विकास" को परिभाषित करें
मार्को वैन डे वोर्ट

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

भोजन के लिए सोचा, यहाँ एक शानदार लेख है जहाँ ZeroMQ के डिजाइनर और लेखक चर्चा करते हैं कि वह सी। के बजाय C ++ में कोड बेस लिखने के लिए पछतावा क्यों नहीं करता है, जिसकी मुझे उम्मीद थी और इस पृष्ठ पर कहीं और नहीं मिला। 250bpm.com/blog:4
user2548100

जवाबों:


48

C + C का उपयोग करने के दो कारण:

  1. बहुत सारे एम्बेडेड प्रोसेसर के लिए, या तो कोई C ++ कंपाइलर नहीं है, या आपको इसके लिए अतिरिक्त भुगतान करना होगा।
  2. मेरा अनुभव यह है कि एम्बेडेड सॉफ्टवेयर इंजीनियरों के एक सांकेतिक अनुपात में सी ++ का बहुत कम या कोई अनुभव नहीं है - या तो (1) के कारण, या क्योंकि यह इलेक्ट्रॉनिक इंजीनियर डिग्री पर पढ़ाया नहीं जाता है - और इसलिए इसके साथ रहना बेहतर होगा वे क्या जानते हैं।

इसके अलावा, मूल प्रश्न और कई टिप्पणियों में, 4 के RAM का उल्लेख है । एक विशिष्ट एम्बेडेड प्रोसेसर के लिए, रैम की मात्रा कोड के आकार से असंबंधित होती है, क्योंकि कोड संग्रहीत होता है, और फ्लैश से चलता है।

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

एम्बेडेड सिस्टम के साथ उपयोग के लिए C ++ के सबसेट के उपयोग पर: अब MISRA C ++ मानक है, जो देखने लायक हो सकता है।

EDIT: यह प्रश्न भी देखें , जिसके कारण एम्बेडेड सिस्टम के लिए C बनाम C ++ के बारे में बहस हुई।


2
नीचे मेरा लंबा जवाब देखें: C ++ को FLASH में निरंतर डेटा डालना बहुत मुश्किल है।
जकाबोन्गब्लोम 2

3
C ++ के बजाय C का उपयोग करने का संभावित अच्छा कारण C का मानक ABI है। सिर्फ पूर्णता के लिए।
क्रिस लुत्ज़

66

एक बहुत ही सीमित लक्ष्य जैसे कि 4KB RAM के लिए, मैं बहुत अधिक प्रयास करने से पहले कुछ नमूनों के साथ पानी का परीक्षण करूँगा, जिन्हें आसानी से शुद्ध ANSI C कार्यान्वयन में वापस नहीं लाया जा सकता है।

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

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

जब तक वे पर्याप्त बड़े नहीं हो जाते हैं, तब तक इनलाइन फ़ंक्शन बहुत समस्या पैदा नहीं करेंगे, क्योंकि उन्हें पहली बार में ही सही कार्य करने चाहिए थे। बेशक मैक्रों ने उनकी जगह उसी मुद्दे को ले लिया था।

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

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

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

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

इसके अलावा, एक एम्बेडेड वातावरण में, अक्सर उपयोग किए जाने से पहले हार्डवेयर उपकरणों को इनिशियलाइज़ करना आवश्यक होता है, और अगर कोई OS और कोई बूट लोडर नहीं है, तो यह आपका कोड है जो ऐसा करता है। आपको याद रखना होगा कि वैश्विक ऑब्जेक्ट्स के लिए कंस्ट्रक्टर्स को चलाने से पहले main() कहा जाता है इसलिए आपको अपने स्थानीय CRT0.S (या इसके समतुल्य) को संशोधित करने की आवश्यकता होगी ताकि वैश्विक कंस्ट्रक्टर्स द्वारा खुद को कॉल किए जाने से पहले हार्डवेयर इनिशियलाइज़ेशन किया जा सके। जाहिर है, main()रास्ता बहुत देर से है।


1
यह एक से अधिक upvotes की जरूरत है कि मैं यह दे सकता है! बहुत बढ़िया जवाब।
हार्पर शेल्बी

+1, बढ़िया जवाब। लेकिन मैं एकमात्र टेम्पलेट तात्कालिकता पर विश्वास करता हूं जिसके बारे में आपको वास्तव में चिंता करने की ज़रूरत है (अपेक्षाकृत दुर्लभ) पुनरावर्ती प्रकार - "नियमित" गैर-पुनरावर्ती प्रकार के लिए, तात्कालिकता मात्रा को कोड करने के लिए आप मैन्युअल रूप से वैसे भी टाइप करेंगे।
j_random_hacker

2
@j_random_hacker, सच। लेकिन जब दूसरी (या तीसरी) तात्कालिकता दिखाई देती है, तो उपयोग की बात पर उचित प्रकार का जोर लगने से रोका जा सकता है, जब टेम्पलेट्स की आदत कभी-कभी आश्चर्य का कारण बन सकती है। यह सिर्फ कुछ के लिए बाहर देखने के लिए है।
RBerteig

@RBteteig: अच्छा बिंदु, टेम्पलेट कम प्रकार की जबरदस्ती की संभावनाएं प्रदान करते हैं => संभवत: गैर-टेम्पलेट कोड की तुलना में अधिक विशिष्ट तात्कालिकताएं उत्पन्न होती हैं।
j_random_hacker

26

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


20

सी ++ प्रदर्शन पर तकनीकी रिपोर्ट बात की इस तरह के लिए एक महान गाइड है। ध्यान दें कि इसमें एम्बेडेड प्रोग्रामिंग चिंताओं पर एक अनुभाग है!

इसके अलावा, उत्तर में एंबेडेड सी ++ के उल्लेख पर ++। मानक मेरे स्वाद के लिए 100% नहीं है, लेकिन सी ++ के किन हिस्सों को आप छोड़ सकते हैं यह तय करते समय यह संदर्भ का एक अच्छा सा है।

छोटे प्लेटफार्मों के लिए प्रोग्रामिंग करते समय, हम अपवादों और आरटीटीआई को अक्षम करते हैं, आभासी विरासत से बचते हैं, और हमारे आसपास झूठ बोलने वाले आभासी कार्यों की संख्या पर ध्यान देते हैं।

आपका मित्र लिंकर मैप है, हालांकि: इसे अक्सर जांचें, और आप कोड और स्थिर मेमोरी ब्लॉट के स्रोतों को जल्दी से देख लेंगे।

उसके बाद, मानक डायनामिक मेमोरी उपयोग विचार लागू होते हैं: आपके द्वारा उल्लिखित के रूप में प्रतिबंधित वातावरण में, आप डायनेमिक आवंटन का उपयोग नहीं करना चाह सकते हैं। कभी-कभी आप छोटे गतिशील allocs, या "फ्रेम-आधारित" आवंटन के लिए मेमोरी पूल के साथ दूर हो सकते हैं जहां आप एक ब्लॉक का प्रचार करते हैं और बाद में पूरी चीज को बाहर फेंक देते हैं।


16

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

आप आगे जा सकते हैं और सी ++ कक्षाओं आदि का उपयोग कर सकते हैं, बस

  • आभासी कार्यों के अपने उपयोग को सीमित करें (जैसा कि आपने कहा है)
  • टेम्पलेट्स के अपने उपयोग को सीमित करें
  • एक एम्बेडेड प्लेटफ़ॉर्म के लिए, आप ऑपरेटर नए को ओवरराइड करना चाहते हैं और / या मेमोरी आवंटन के लिए प्लेसमेंट नए का उपयोग करेंगे।

8
बेशक, यदि आप पहले से ही मूल रूप से सी लिख रहे हैं, तो आप इसे आधिकारिक बना सकते हैं।
चक

6
आप टेम्प्लेट के उपयोग को सीमित क्यों करते हैं? मैंने सोचा है कि टेम्पलेट फ़ंक्शंस वास्तव में एम्बेडेड सिस्टम में सहायक हो सकते हैं उदाहरण के लिए छोरों को अनियंत्रित करना।
पियोट्र कजपला

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

14

एक फर्मवेयर / एम्बेडेड सिस्टम इंजीनियर के रूप में, मैं आप लोगों को कुछ कारण बता सकता हूं कि C अभी भी C ++ पर # 1 पसंद क्यों है और हां, मैं उन दोनों में धाराप्रवाह हूं।

1) हमारे द्वारा विकसित किए गए कुछ लक्ष्य में कोड और डेटा दोनों के लिए 64kB RAM है, इसलिए आपको हर बाइट की गिनती सुनिश्चित करनी होगी, और हां, मैंने 4 बाइट्स को बचाने के लिए कोड ऑप्टिमाइज़ेशन से निपटा है, जिसकी कीमत मुझे 2 घंटे है, और इसमें 2008।

2) हर सी लाइब्रेरी फंक्शन की समीक्षा की जाती है, इससे पहले कि हम उन्हें आकार की सीमा के कारण अंतिम कोड में दें, इसलिए हम लोगों को डिवाइड (कोई हार्डवेयर डिवाइडर, इसलिए एक बड़ी लाइब्रेरी की आवश्यकता नहीं है) का उपयोग करने के लिए पसंद करते हैं, मॉलॉक (क्योंकि हमारे पास कोई ढेर नहीं है , सभी मेमोरी को 512 बाइट चंक में डेटा बफर से आवंटित किया गया है और कोड की समीक्षा की जानी चाहिए), या अन्य वस्तु उन्मुख अभ्यास जो बड़े जुर्माना लगाते हैं। याद रखें, प्रत्येक पुस्तकालय फ़ंक्शन जिसे आप गिनती का उपयोग करते हैं।

3) ओवरले शब्द कभी सुना है? आपके पास इतना कम कोड स्थान है कि कभी-कभी आपको कोड के दूसरे सेट के साथ चीजों को स्वैप करना होगा। अगर आप लाइब्रेरी फंक्शन कहते हैं तो लाइब्रेरी फंक्शन रेजिडेंट होना चाहिए। यदि आप इसे केवल एक ओवरले फ़ंक्शन में उपयोग करते हैं, तो आप बहुत सारे ऑब्जेक्ट ओरिएंटेड तरीकों पर भरोसा करते हुए बहुत सारे स्थान बर्बाद कर रहे हैं। इसलिए, किसी भी C लाइब्रेरी फ़ंक्शन को न मानें, अकेले C ++ को स्वीकार किया जाए।

4) सीमित हार्डवेयर डिजाइन (यानी एक ECC इंजन जिसे एक निश्चित तरीके से वायर्ड किया जाता है) या हार्डवेयर बग से निपटने के लिए कास्टिंग और यहां तक ​​कि पैकिंग (जहां अनलगनेटेड डेटा स्ट्रक्चर क्रॉस शब्द सीमा) की आवश्यकता होती है। आप बहुत अधिक अप्रिय नहीं मान सकते हैं, इसलिए ऑब्जेक्ट को बहुत अधिक उन्मुख क्यों करें?

5) सबसे खराब स्थिति: वस्तु उन्मुख तरीकों में से कुछ को खत्म करने से पहले वे संसाधनों का उपयोग करने के लिए सोचने के लिए विकसित होंगे जो विस्फोट कर सकते हैं (यानी डेटा बफर के बजाय स्टैक पर 512bytes आवंटित करना), और संभावित सबसे खराब स्थिति में से कुछ को रोकें पूरे कोड पथ को एक साथ पूरा करने या समाप्त करने के लिए परीक्षण नहीं किया गया है।

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

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

BTW, हर फर्मवेयर काम मैं स्रोत नियंत्रण का उपयोग करता है, मुझे नहीं पता कि आपको यह विचार कहां से मिला है।

सैनडिस्क से कुछ फर्मवेयर फर्मवेयर।


90 के
दशक

शुभ अंक शिंग। C ++ परियोजनाओं पर एक फोन बूथ में सूमो पहलवान की तरह महसूस करता है जहां कार्यक्षमता सीमित है, और संसाधन और भी अधिक सीमित हैं।

4
मेरा मानना ​​है कि यह उत्तर बहुत व्यक्तिपरक है और ठोस तर्क प्रदान नहीं करता है।
वेनमो

1
C ++ का अर्थ जरूरी नहीं है कि "ऑब्जेक्ट ओरिएंटेड" हो।
मार्टिन बोनर

1
यह केवल सच नहीं है कि एम्बेडेड सिस्टम का कार्य प्रकृति द्वारा अमूर्त नहीं है। आपने इसे अपने आप को बिंदु 6 में कहा है): "हम hw को sw से बनाए रखने के लिए बहुत अधिक अमूर्त का उपयोग करते हैं और कोड को यथासंभव पोर्टेबल बनाते हैं" :-) BTW: "अमूर्त" का अर्थ "बहुरूपता" नहीं है।
डेनियल पल्लास्त्रेली

9

मेरी व्यक्तिगत प्राथमिकता सी है क्योंकि:

  • मुझे पता है कि कोड की हर पंक्ति क्या कर रही है (और लागत)
  • मुझे पता नहीं है कि C ++ इतनी अच्छी तरह से जानता है कि कोड की हर पंक्ति क्या कर रही है (और लागत)

लोग ऐसा क्यों कहते हैं? तुम नहीं जब तक आप एएसएम उत्पादन जाँच पता है कि सी के हर लाइन कर रही है। वही C ++ के लिए जाता है।

उदाहरण के लिए, क्या यह निर्दोष बयान का उत्पादन करता है:

a[i] = b[j] * c[k];

यह काफी निर्दोष दिखता है, लेकिन एक जीसीसी आधारित कंपाइलर 8-बिट माइक्रो के लिए इस एएसएम का उत्पादन करता है

CLRF 0x1f, ACCESS
RLCF 0xfdb, W, ACCESS
ANDLW 0xfe
RLCF 0x1f, F, ACCESS
MOVWF 0x1e, ACCESS
MOVLW 0xf9
MOVF 0xfdb, W, ACCESS
ADDWF 0x1e, W, ACCESS
MOVWF 0xfe9, ACCESS
MOVLW 0xfa
MOVF 0xfdb, W, ACCESS
ADDWFC 0x1f, W, ACCESS
MOVWF 0xfea, ACCESS
MOVFF 0xfee, 0x1c
NOP
MOVFF 0xfef, 0x1d
NOP
MOVLW 0x1
CLRF 0x1b, ACCESS
RLCF 0xfdb, W, ACCESS
ANDLW 0xfe
RLCF 0x1b, F, ACCESS
MOVWF 0x1a, ACCESS
MOVLW 0xfb
MOVF 0xfdb, W, ACCESS
ADDWF 0x1a, W, ACCESS
MOVWF 0xfe9, ACCESS
MOVLW 0xfc
MOVF 0xfdb, W, ACCESS
ADDWFC 0x1b, W, ACCESS
MOVWF 0xfea, ACCESS
MOVFF 0xfee, 0x18
NOP
MOVFF 0xfef, 0x19
NOP
MOVFF 0x18, 0x8
NOP
MOVFF 0x19, 0x9
NOP
MOVFF 0x1c, 0xd
NOP
MOVFF 0x1d, 0xe
NOP
CALL 0x2142, 0
NOP
MOVFF 0x6, 0x16
NOP
MOVFF 0x7, 0x17
NOP
CLRF 0x15, ACCESS
RLCF 0xfdf, W, ACCESS
ANDLW 0xfe
RLCF 0x15, F, ACCESS
MOVWF 0x14, ACCESS
MOVLW 0xfd
MOVF 0xfdb, W, ACCESS
ADDWF 0x14, W, ACCESS
MOVWF 0xfe9, ACCESS
MOVLW 0xfe
MOVF 0xfdb, W, ACCESS
ADDWFC 0x15, W, ACCESS
MOVWF 0xfea, ACCESS
MOVFF 0x16, 0xfee
NOP
MOVFF 0x17, 0xfed
NOP

उत्पादित निर्देशों की संख्या बड़े पैमाने पर निर्भर करती है:

  • ए, बी और सी के आकार।
  • चाहे वे संकेत स्टैक पर संग्रहीत हों या वैश्विक हों
  • क्या मैं, जम्मू और कश्मीर स्टैक पर हैं या वैश्विक हैं

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

ह्यूगो


2
यह भी ध्यान दें कि सभी के बीच में एक कॉल निर्देश है जो वास्तव में बहुक्रिया कॉल करता है। उस कोड के सभी भी अनुदेश गुणा नहीं है!
रॉकेटमेग्नेट

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

8

मैंने सुना है कि कुछ लोग इस तथ्य के कारण एम्बेडेड काम के लिए सी पसंद करते हैं जो सरल है और इसलिए वास्तविक कोड की भविष्यवाणी करना आसान है जो उत्पन्न होगा।

मैं व्यक्तिगत रूप से सोचता हूँ कि C- शैली C ++ (टाइप-सेफ्टी के लिए टेम्प्लेट का उपयोग करना) आपको बहुत सारे फायदे देगा, हालाँकि मैं कोई वास्तविक कारण नहीं देख सकता।


+1, पारदर्शिता हमेशा महत्वपूर्ण होती है, और संभवतया विवश वातावरण के लिए (संभवतः) डिबगिंग टूल के साथ moreso।
j_random_hacker

7

मुझे C ++ के बजाय C का उपयोग करने का कोई कारण नहीं दिखता है। आप C में जो भी कर सकते हैं, आप C ++ में भी कर सकते हैं। यदि आप VMT के ओवरहेड्स से बचना चाहते हैं, तो आभासी तरीकों और बहुरूपता का उपयोग न करें।

हालांकि, C ++ बिना ओवरहेड के साथ कुछ बहुत उपयोगी मुहावरे प्रदान कर सकता है। मेरे पसंदीदा में से एक RAII है। स्मृति या प्रदर्शन के मामले में कक्षाएं आवश्यक नहीं हैं ...


6

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

मुझे पता है, यह सीखना मुश्किल हो सकता है, लेकिन मुझे यह भी यकीन है कि आपके उत्पाद को इस दृष्टिकोण से लाभ होगा।


5

एक अच्छा कारण और कभी-कभी एकमात्र कारण यह है कि विशिष्ट एम्बेडेड सिस्टम के लिए अभी भी कोई C ++ कंपाइलर नहीं है। यह उदाहरण के लिए माइक्रोचिप PIC माइक्रो-नियंत्रक के लिए मामला है । वे लिखने के लिए बहुत आसान हैं और उनके पास एक मुफ्त सी संकलक है (वास्तव में, सी का एक मामूली संस्करण) लेकिन दृष्टि में कोई सी ++ संकलक नहीं है।


1
कॉम्यू कम्प्यूटिंग ( comeaucomputing.com ) एक सी ++ कंपाइलर बेचता है जो सी को संकलित करता है
थॉमस एल होलाडे

3
Eww। उस साइट को puke करना चाहते हैं।
shoosh

@ संतोष: हाँ, साइट का डिज़ाइन बहुत ही भयानक है। हालाँकि संकलक को क्षेत्र में एक नेता माना जाता है, कम से कम मानक अनुरूपता के मामले में (मुझे प्रदर्शन के बारे में कोई जानकारी नहीं है)।
j_random_hacker

वह वेब साइट मुझे ऐसा महसूस कराती है जैसे मैं एक जीवित, सांस लेने और बहुत गुस्से में फलों के सलाद के अंदर फंस गया हूं।
टिम पोस्ट

5

4K के लिए विवश एक प्रणाली के लिए, मैं C का उपयोग करूँगा, न कि C ++ का, ताकि आप यह सुनिश्चित कर सकें कि सब कुछ चल रहा है। C ++ के साथ बात यह है कि कोड पर glancing की तरह दिखने से कहीं अधिक संसाधनों (CPU और मेमोरी दोनों) का उपयोग करना बहुत आसान है। (ओह, मैं ऐसा करने के लिए एक और ब्लरऑफजेक्ट बनाऊंगा ... जो स्मृति से बाहर है!)

आप इसे C ++ में कर सकते हैं, जैसा कि पहले ही उल्लेख किया गया है (कोई RTTI, कोई vtables, आदि, आदि), लेकिन आप यह सुनिश्चित करने में अधिक समय बिताएंगे कि आपका C ++ उपयोग आपसे दूर नहीं होता है क्योंकि आप C के समकक्ष कर रहे हैं। ।


2
आपका अंतिम वाक्य सही है लेकिन अप्रासंगिक है क्योंकि C ++ सी पर अन्य फायदे प्रदान करता है जो (शेष) टिप कर सकता है। पियोट्र ने पहले ही इनमें से कुछ (शून्य-लागत) लाभों का उल्लेख किया है।
कोनराड रुडोल्फ

5

मानव मन जितना संभव हो उतना मूल्यांकन करके जटिलता से निपटता है, और फिर यह निर्णय लेना है कि क्या ध्यान केंद्रित करना महत्वपूर्ण है, और बाकी को त्यागना या ह्रास करना। यह मार्केटिंग में ब्रांडिंग के पीछे का पूरा आधार है, और मोटे तौर पर, आइकन्स।

इस प्रवृत्ति से निपटने के लिए मैं C से C ++ को प्राथमिकता देता हूं, क्योंकि यह आपको अपने कोड के बारे में सोचने के लिए मजबूर करता है, और यह कैसे हार्डवेयर के साथ अधिक निकटता से बातचीत कर रहा है - अथक रूप से करीब।

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

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

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


ZeroMQ के लेखक मार्टिन सिस्ट्रिक ने अपनी चर्चा में लगभग एक ही बिंदु बनाया कि वे क्यों चाहते हैं कि अब वह C ++ के बजाय C में ZeroMQ लिखेंगे। इसे 250bpm.com/blog:8
user2548100

3

व्यक्तिगत रूप से 4kb ऑफ़ मेमोरी के साथ मैं कहूँगा कि आप C ++ से अधिक माइलेज नहीं पा रहे हैं, इसलिए केवल वही चुनें जो नौकरी के लिए सबसे अच्छा कंपाइलर / रनटाइम संयोजन लगता है, क्योंकि भाषा शायद बहुत ज्यादा मायने नहीं रखती है।

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


2

सी पोर्टेबिलिटी पर जीतता है - क्योंकि यह भाषा की कल्पना में कम अस्पष्ट है; इसलिए विभिन्न कंपाइलरों आदि (कम सिरदर्द) में बेहतर पोर्टेबिलिटी और लचीलापन प्रदान करता है।

यदि आप एक आवश्यकता को पूरा करने के लिए C ++ सुविधाओं का लाभ उठाने नहीं जा रहे हैं, तो C के साथ जाएं।


क्या भाषा असंदिग्ध है या नहीं यह इस बात पर निर्भर करता है कि क्या कोई इसे उन चीजों को निर्दिष्ट करने के रूप में मानता है, जिन्हें सामान्य ज्ञान माना जाता था, लेकिन आजकल यह नहीं है [जैसे कि 32-बिट मूक-रैपराउंड दो-पूरक हार्डवेयर के लिए एक कंपाइलर को कुछ इस तरह से संसाधित करना चाहिए जैसे unsigned mul(unsigned short x, unsigned short y) { return x*y;}कि नहीं उत्पाद 2147483647 से अधिक होने पर भी साइड-इफ़ेक्ट, या यह कि void get_float_bits(float *fp, uint32_t n) { *(uint32_t)fp = n; }संभवतः ए के मूल्य में फेरबदल करना चाहिए float
सुपरैट

2

क्या आपको बहुत सीमित हार्डवेयर (4kb of RAM) के लिए विकसित होने के दौरान C89 से चिपके रहने का कोई कारण दिखाई देता है?

निजी तौर पर, जब यह एम्बेडेड अनुप्रयोगों की बात आती है (जब मैं कहता हूं एम्बेडेड, मेरा मतलब नहीं है winCE, iPhone, आदि .. फूला हुआ एम्बेडेड उपकरणों आज)। मेरा मतलब संसाधन सीमित डिवाइस है। मैं सी पसंद करता हूं, हालांकि मैंने सी ++ के साथ भी काम किया है।

उदाहरण के लिए, आप जिस डिवाइस के बारे में बात कर रहे हैं उसमें 4kb है उसमें RAM है, ठीक उसी कारण से मैं C ++ पर विचार नहीं करूंगा। निश्चित रूप से, आप C ++ का उपयोग करके कुछ छोटा डिज़ाइन कर सकते हैं और अपने एप्लिकेशन में इसके उपयोग को सीमित कर सकते हैं जैसे कि अन्य पदों ने सुझाव दिया है लेकिन C ++ "कवर के तहत आपके एप्लिकेशन को जटिल रूप से जटिल / धुंधला कर सकता है"।

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

IMHO, सामान्य तौर पर, एम्बेडेड अनुप्रयोगों में मैं सब कुछ जानना पसंद करता हूं जो चल रहा है। कौन स्मृति / सिस्टम संसाधनों का उपयोग कर रहा है, कितना और क्यों? वे उन्हें कब मुक्त करते हैं?

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


1
मैं दो कंपाइलरों की तुलना जरूर करूंगा। (btw। मैं डायनेमिक रूप से लिंक नहीं कर सकता क्योंकि कोई ऑपरेटिंग सिस्टम नहीं है)
पियोट्र सीज़ापला

2

मेरी पसंद आमतौर पर सी लाइब्रेरी द्वारा निर्धारित की जाती है जिसे हम उपयोग करने का निर्णय लेते हैं, जो कि डिवाइस को क्या करना है, इसके आधार पर चुना जाता है। तो, 9/10 बार .. यह uclibc या newlib और C. होने से समाप्त होता है। जिस कर्नेल का हम उपयोग करते हैं वह इस पर भी एक बड़ा प्रभाव है, या यदि हम अपना कर्नेल लिख रहे हैं।

यह भी आम जमीन का एक विकल्प है। अधिकांश अच्छे C प्रोग्रामर को C ++ का उपयोग करने में कोई समस्या नहीं है (भले ही कई लोग पूरे समय शिकायत करते हैं कि वे इसका उपयोग करते हैं) .. लेकिन मैंने इसके विपरीत (अपने अनुभव में) सही नहीं पाया है।

हम जिस प्रोजेक्ट पर काम कर रहे हैं (जिसमें एक ग्राउंड अप कर्नेल शामिल है), ज्यादातर चीजें C में की जाती हैं, हालांकि C ++ में एक छोटा नेटवर्क स्टैक लागू किया गया था, क्योंकि C ++ का उपयोग करके नेटवर्किंग को लागू करना आसान और कम समस्याग्रस्त था।

अंतिम परिणाम है, डिवाइस या तो काम करेगा और स्वीकृति परीक्षण पास करेगा या यह नहीं होगा। यदि आप xx स्टैक में yoo को कार्यान्वित कर सकते हैं और भाषा z का उपयोग करते हुए yy हीप बाधाओं का सामना कर सकते हैं, तो इसके लिए उपयोग करें, जो भी आपको अधिक उत्पादक बनाता है।

मेरी व्यक्तिगत प्राथमिकता सी है क्योंकि:

  • मुझे पता है कि कोड की हर पंक्ति क्या कर रही है (और लागत)
  • मुझे पता नहीं है कि C ++ इतनी अच्छी तरह से जानता है कि कोड की हर पंक्ति क्या कर रही है (और लागत)

हां, मैं सी ++ के साथ सहज हूं, लेकिन मैं इसे मानक सी के रूप में नहीं जानता।

अब अगर आप इसके विपरीत कह सकते हैं, ठीक है, जो आप जानते हैं उसका उपयोग करें :) अगर यह काम करता है, परीक्षण पास करता है, आदि .. क्या समस्या है?


2
> # मुझे पता है कि कोड की प्रत्येक पंक्ति क्या कर रही है (और लागत) लिखित संकलक होने के नाते, मैं इस बारे में निश्चित नहीं रहूंगा ... एक अच्छा सी संकलक आपके कोड के लिए काफी आश्चर्यजनक चीजें कर सकता है क्योंकि इसमें एक अच्छा वैश्विक अवलोकन है चीजें। यह लाइन-बाय-लाइन संकलित नहीं करता है।
जकाबोन्गब्लोम 2

@ jakobengblom2: एम्बेडेड विकास के लिए, अधिकतम प्रदर्शन होने की तुलना में लगातार प्रदर्शन करना अधिक महत्वपूर्ण है। यदि कोई यह निर्धारित करने की कोशिश कर रहा है कि क्या कोड का एक टुकड़ा समय की आवश्यकताओं को पूरा करेगा, तो संकलक ऐसे अनुकूलन का उपयोग करेगा जो "परीक्षण" फर्मवेयर में प्रयोग करने योग्य होगा जो वास्तविक फर्मवेयर में काम नहीं करेगा सहायक से कम होना उपयुक्त नहीं है।
Supercat

2

आपके पास कितना ROM / FLASH है?

4kB RAM का मतलब अभी भी वास्तविक कोड और स्थिर डेटा को संग्रहीत करने के लिए सैकड़ों किलोबाइट के FLASH हो सकते हैं। इस आकार पर रैम का मतलब केवल चर के लिए होता है, और यदि आप उन लोगों के साथ सावधान हैं तो आप मेमोरी में कोड लाइनों के मामले में काफी बड़े प्रोग्राम को फिट कर सकते हैं।

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

तो एक "छोटे RAM", "बड़े FLASH" प्रकार के वातावरण में मैं किसी भी दिन C के साथ जाऊंगा। ध्यान दें कि एक अच्छा मध्यवर्ती विकल्प I C99 जिसमें गैर-वर्ग-आधारित कोड के लिए अधिकांश अच्छी C ++ विशेषताएँ हैं।


3
क्या कोई कारण है कि उसी संरचना को C में फ़्लैश मेमोरी में डाला जाएगा, वह भी फ़्लैश में C ++ में समाप्त नहीं होगा? आप नहीं करते है सी ++ में अपने struct करने के लिए एक निर्माता जोड़ने के लिए।
जल्फ

1

सामान्य तौर पर C ++, C का एक सुपर सेट है। यह नई परियोजनाओं के लिए विशेष रूप से सच होगा।

आप C ++ कंस्ट्रक्शन से बचने के लिए सही रास्ते पर हैं जो कि सीपीयू टाइम और मेमोरी फुट प्रिंट के लिहाज से महंगा हो सकता है।

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

इसके अलावा, अच्छा (अच्छी तरह से डिज़ाइन किया गया) अपवाद हैंडलिंग आपके एम्बेडेड ऐप को पारंपरिक त्रुटि कोड के साथ चीजों को संभालने वाले ऐप की तुलना में अधिक विश्वसनीय बना सकता है।


2
C ++, कड़ाई से नहीं बोल रहा है, C का एक सख्त सुपरसेट है, लेकिन वह विशेष विवरण इस संदर्भ में विशेष रूप से पर्याप्त नहीं है।
अराफांजियन

1

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

यह उत्पाद C और C ++ दोनों पर चलता है।


1

कुछ का कहना है कि सी कंपाइलर बहुत अधिक कुशल कोड उत्पन्न कर सकते हैं क्योंकि उन्हें उन्नत सी ++ सुविधाओं का समर्थन नहीं करना पड़ता है और इसलिए वे अपने अनुकूलन में अधिक आक्रामक हो सकते हैं।

बेशक, इस मामले में आप परीक्षण के लिए दो विशिष्ट संकलक डाल सकते हैं।


1
संबंधित: प्रतिबंधित कीवर्ड जहां तक ​​मुझे पता है कि C ++ (C C 11) में भी केवल ऑप्टिमाइज़ेशन से संबंधित C निर्माण गायब है।
जोहान लुंडबर्ग

1

C IMHO पसंद करने का एकमात्र कारण यह होगा कि आपके प्लेटफ़ॉर्म के लिए C ++ कंपाइलर अच्छे आकार (छोटी गाड़ी, खराब ऑप्टिमाइज़ेशन आदि) में नहीं है।


स्मृति / संसाधन उपयोग के बारे में क्या?
स्टीव लजारिडिस 19

इसके बारे में क्या है? C ++ कंपाइलर के लिए C C की तुलना में कम कुशल कोड का उत्पादन करने का कोई कारण नहीं है, सिवाय इसके कि कोड RTTI का उपयोग करता है, जो कोई एम्बेडेड सिस्टम पर नहीं करता है।
नेमेनजा ट्रिफ़ुनोविक


1

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

sizeof 'a' > 1 C में, C ++ में नहीं। सी में आपके पास वीएलए चर लंबाई सरणियाँ हैं। उदाहरण: func (int i) {int [a] । C में आपके पास VAM चर सरणी सदस्य हैं। उदाहरण: संरचना {int b; int m [];}


1
नहीं। मेरा मतलब है कि C में आपके पास (sizeof 'a') == sizeof (int) है। जबकि C ++ में आपके पास 1 == sizeof 'a'
hept

1
"Int * a; ...; (a (int *) malloc (size * sizeof (int));" C और C ++ में काम करने वाली मेमोरी को आवंटित करने का तरीका है, और इसका उपयोग न तो किया जाना चाहिए। "A = malloc (आकार * sizeof (int));" या "वेक्टर <int> (आकार);" या यहां तक ​​कि "int * a = new int [size];" बजाय।
डेविड थॉर्नले

1
मैं डक्टर्स के बारे में आपकी बात नहीं मानता। उनके बारे में पूरी बात यह है कि वे आपके बाकी कोड को बहुत कम गन्दा बनाते हैं ।
jalf

1
+1, निश्चित नहीं कि इस पोस्ट को इतना बुरा रैप क्यों मिला। लेकिन मैं jalf से सहमत हूं, जब सही (RAII) तरीके का उपयोग किया जाता है , तो विध्वंसक कोड को सरलता से सरल बनाते हैं । (आप कह सकते हैं कि वे "पर्दे के पीछे काम करते हैं", लेकिन वे केवल सामान कर रहे हैं जो सही कोड मैन्युअल रूप से वैसे भी कर रहे होंगे।)
j_random_hacker

1
मुझे लगता है कि मेरे द्वारा इंगित किया गया सामान प्रश्न के लिए बहुत प्रासंगिक है। मैं अपने बयान पर भी अड़ा रहा कि डस्टर मुश्किल हो सकता है, और इसका कारण यह है कि यह स्वचालित रूप से होता है। मुझे माइनस पॉइंट्स मिले - वास्तव में हार्श। ऐसा लगता है क्योंकि मैं नहीं कहता "हाँ, जाओ C ++ इसकी महान"।
-09

1

यह कंपाइलर पर निर्भर करता है।

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

लेकिन एक अच्छा संकलक दिया , नहीं, C ++ का उपयोग नहीं करने का कोई कारण नहीं है।


1

केवल यह कहना चाहता हूं कि "UNLIMITED" संसाधनों के साथ कोई प्रणाली नहीं है। इस दुनिया में सब कुछ सीमित है और हर आवेदन को संसाधन उपयोग पर विचार करना चाहिए, चाहे उसका ASM, C, JAVA या जावास्क्रिप्ट। Dummies जो कुछ Mbs "बस सुनिश्चित करने के लिए" आवंटित करती हैं, iPhone 7, Pixel और अन्य डिवाइसों को बेहद लुगदी बनाती हैं। कोई फर्क नहीं पड़ता कि आपके पास 4kb या 40 Gb है।

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

बस एक पक्ष ने सोचा - आपके आउटलेट से बिजली भी असीमित नहीं है। यह शोध करने की कोशिश करें कि इसका प्रभाव कहां से आ रहा है और आप ज्यादातर इसे किसी चीज को जलाने से देखेंगे। ऊर्जा और सामग्री का नियम अभी भी मान्य है: कोई भी सामग्री या ऊर्जा प्रकट या गायब नहीं होती है, बल्कि बदल जाती है।


0

मुझे सिर्फ एक उदाहरण मिला है कि एम्बेडेड विकास के लिए आईएसओ सी ++ का उपयोग कैसे किया जाए, जो किसी ऐसे व्यक्ति के लिए दिलचस्प हो सकता है जो निर्णय ले रहा है जब भी सी ++ या सी का उपयोग करें।

यह उनके होमपेज पर बज़्ने स्ट्रॉस्ट्रुप द्वारा प्रदान किया गया था :

गंभीर एम्बेडेड सिस्टम प्रोग्रामिंग के लिए आईएसओ सी ++ का उपयोग कैसे किया जा सकता है, इस पर एक नज़र के लिए, जेएसएफ वायु वाहन सी ++ कोडिंग मानकों को देखें


खैर, फ्लाइंग चीजों में गीगाबाइट रैम के साथ पीपीसी प्रोसेसर होते हैं। आपका औसत संसाधन-विवश एम्बेडेड सिस्टम नहीं।
जकोबेंगब्लोम 2

0

प्रश्न के एक अलग पहलू पर विभिन्न उत्तर पोस्ट:

"मैलोक"

पिछले कुछ जवाब इस बारे में काफी बात करते हैं। आपको भी क्यों लगता है कि कॉल मौजूद है? वास्तव में एक छोटे से मंच के लिए, मॉलोक अनुपलब्ध है, या निश्चित रूप से वैकल्पिक है। जब आप अपने सिस्टम के निचले भाग में RTOS प्राप्त करते हैं तो गतिशील मेमोरी आवंटन को लागू करना सार्थक हो जाता है - लेकिन तब तक, यह पूरी तरह से खतरनाक है।

आप इसके बिना बहुत दूर निकल सकते हैं। जरा उन सभी पुराने फोरट्रान कार्यक्रमों के बारे में सोचिए जिनके पास स्थानीय चरों के लिए एक उचित स्टैक भी नहीं था ...


0

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


0

मैं सी ++ को सीमाओं और नोटों के साथ सुझाता हूं।

  1. बाजार और स्थिरता के लिए समय। C ++ का विकास आसान और तेज है। इसलिए यदि आप डिजाइनिंग चरण में हैं, तो C ++ का उपयोग करने के लिए एक नियंत्रक को पर्याप्त रूप से चुना। (ध्यान दें, कि कुछ उच्च मात्रा के बाजार में यथासंभव कम लागत की आवश्यकता होती है, जहां आप यह विकल्प नहीं बना सकते।)

  2. गति। C C ++ से तेज हो सकता है, लेकिन सुनिश्चित करें कि यह गति लाभ बड़ा नहीं है। तो आप C ++ के साथ जा सकते हैं। अपने एल्गोरिदम विकसित करें, उनका परीक्षण करें, और यदि आवश्यक हो तो केवल उन्हें तेज करें (!)। अड़चनों का उपयोग करें, अड़चनों को इंगित करने के लिए और बाहरी गति "सी" तरीके से उन्हें फिर से लिखें , सी गति प्राप्त करने के लिए। (यदि यह अभी भी ASM में उस हिस्से को धीमा करता है)

  3. बाइनरी आकार। C ++ कोड बड़ा है, लेकिन यहां एक शानदार उत्तर है जो विवरण बताता है। किसी दिए गए C कोड के संकलित बाइनरी का आकार वही होगा जो C या C ++ कंपाइलर का उपयोग करके संकलित किया गया था। "निष्पादन योग्य आकार शायद ही भाषा से संबंधित है, लेकिन आपके प्रोजेक्ट में शामिल पुस्तकालयों के लिए।" सी के साथ ++ जाओ लेकिन उन्नत कार्यक्षमताओं, से बचने की तरह streams, string, new, virtualकाम करता है, आदि की समीक्षा सभी पुस्तकालय समारोह आकार सीमा की वजह से, अंतिम कोड में उन्हें पहले (के आधार पर इस सवाल का जवाब)

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.