क्या सी ++ एम्बेडेड सिस्टम के लिए उपयुक्त है?

Question

एक सामान्य सवाल, यहाँ और कहीं। क्या सी ++ एम्बेडेड सिस्टम के लिए उपयुक्त है?

माइक्रोकंट्रोलर्स? RTOSes? टोस्टर? एंबेडेड पीसी?

क्या OOP माइक्रोकंट्रोलर पर उपयोगी है?

क्या C ++ प्रोग्रामर को हार्डवेयर से बहुत अधिक दूर करता है कुशल होने के लिए?

क्या Arduino के C ++ (बिना डायनामिक मेमोरी मैनेजमेंट, टेम्प्लेट, अपवाद) के साथ "वास्तविक C ++" माना जाना चाहिए?

(उम्मीद है, यह विकी इस संभावित पवित्र युद्ध को शामिल करने के लिए एक जगह के रूप में काम करेगा)

Comments

त्वरित प्रश्न: जब आप कहते हैं कि एम्बेडेड है , तो क्या आपका मतलब माइक्रोकंट्रोलर है? माइक्रोप्रोसेसर? एम्बेडेड x86 / एम्बेडेड पीसी?

— जे। पोलर

मैं एक पवित्र युद्ध का कारण नहीं था; इरादा यह जानने का था कि आपके तर्क इसके खिलाफ क्या थे।

— जे। पोलर

यह पहले कई सवालों में आया है, इसलिए मुझे लगा कि एक केंद्रीय स्थान अच्छा होगा।

— टॉबी जाफनी

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

— टॉबी जाफनी

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

— ओलिन लेट्रोप

Answer 1

हां, C ++ अभी भी एम्बेडेड सिस्टम में उपयोगी है। जैसा कि बाकी सभी ने कहा है, यह अभी भी सिस्टम पर ही निर्भर करता है, जैसे 8-बिट यूसी शायद मेरी किताब में नंबर-नो होगा, भले ही वहां एक कंपाइलर हो और कुछ लोग इसे (कंपकंपी) करते हैं। C ++ का उपयोग करने के लिए अभी भी एक फायदा है, जब आप इसे 8-बिट माइक्रो वर्ल्ड में भी "C +" जैसी चीज़ के लिए स्केल करते हैं। मुझे "C +" से क्या मतलब है? मेरा मतलब है कि नए / हटाएं का उपयोग न करें, अपवादों से बचें, वंशानुक्रम के साथ आभासी कक्षाओं से बचें, संभवतः सभी एक साथ विरासत से बचें, टेम्पलेट्स के साथ बहुत सावधान रहें, मैक्रोज़ के बजाय इनलाइन फ़ंक्शन का उपयोग करें, और constइसके बजाय चर का उपयोग करें #defines।

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

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

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

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

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

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

Comments

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

— कोरटुक

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

— कोरटुक

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

— जे। एटकिंसन

यूएमएल और राज्यमंच। आपको वास्तव में राज्य- machine.com पर Miro Samek के सामान को देखना होगा । उन्होंने एक कुशल प्रणाली का निर्माण किया है जो रिफ्लेक्टर और बदलने में आसान है, लेकिन इसे ग्रो करने में कुछ समय लगता है।

— जे। एटकिंसन

यह वास्तव में आपके सिस्टम पर निर्भर करता है और आपके पास कितनी मेमोरी उपलब्ध है। क्या आप बहुत कम रैम के साथ 8-बिट माइक्रो पर कोड लिख रहे हैं? फिर आप अमूर्त इंटरफेस पर पागल होने से बचने के लिए बेहतर हो सकते हैं। यदि आप मेमोरी के स्लैब के साथ 32-बिट एम्बेडेड सिस्टम जैसा कुछ लिख रहे हैं, तो इसके लिए जाएं। आपको वास्तव में इसे तौलना होगा। उदाहरण के लिए, हर बार जब आप दुनिया को उस वर्ग पर "वर्चुअल" चिपकाते हैं, तो आपको एक अतिरिक्त पॉइंटर मिलता है, जो सिस्टम के आधार पर 8-बिट, 16 बिट या 32 बिट हो सकता है, हर एक उदाहरण के लिए जिसे आप उस वस्तु की घोषणा करते हैं। आपको एहसास भी नहीं होगा, और आदमी,

— जे एटकिंसन

Answer 2

C ++ एम्बेडेड सिस्टम के लिए बिल्कुल उपयुक्त है। अब मैं किसी विशेष माइक्रोप्रोसेसर का उपयोग करने या न करने के लिए मेरी प्राथमिक कसौटी के रूप में अच्छे विकास साधनों (या इसके अभाव) की उपस्थिति / अनुपस्थिति का उपयोग करता हूं।

C ++ के क्षेत्र जो एम्बेडेड सिस्टम पर उपयोग करने के लिए अच्छे हैं क्योंकि उनके पास कम संसाधन लागत है:

• वर्गों / संरचनाओं के अच्छे उपयोग द्वारा लाया गया प्रतिरूपकता
• टेम्पलेट्स यदि कंपाइलर उन्हें कुशलतापूर्वक संकलित करने का अच्छा काम करता है। विभिन्न डेटा प्रकारों के लिए एल्गोरिदम का पुन: उपयोग करने के लिए टेम्पलेट एक अच्छा उपकरण है।

ठीक क्षेत्र:

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

उन क्षेत्रों का उपयोग न करना, जो ज्यादातर रन-टाइम ओवरहेड के कारण होते हैं जो छोटे सिस्टम पर अस्वीकार्य हैं:

• डायनेमिक मेमोरी एलोकेशन - दूसरों ने इसका उल्लेख किया है, लेकिन डायनामिक मेमोरी एलोकेशन का उपयोग न करने का एक और महत्वपूर्ण कारण यह है कि यह समय में अनिश्चितता का प्रतिनिधित्व करता है; एम्बेडेड सिस्टम का उपयोग करने के कई कारण वास्तविक समय के अनुप्रयोगों के लिए हैं।
• RTTI (रन टाइम टाइप की जानकारी) - मेमोरी कॉस्ट बड़ी नहीं है
• अपवाद - निष्पादन की गति की वजह से एक निश्चित संख्या नहीं

Comments

इनपुट के लिए धन्यवाद। दिलचस्प और बहुत कुछ जैसा मैंने पढ़ा है।

— कोर्तुक

वास्तव में गतिशील मेमोरी आवंटन ठीक है, और कभी-कभी अपरिहार्य है। यह डायनेमिक मेमोरी डीआलोकेशन (और बाद में फिर से उपयोग) है जो समस्या है। RTTI मेमोरी हॉग है, मैं उस पर सहमत हूं। लेकिन अपवादों से क्या समस्या है?

— राउटर वैन ऊइजेन सेप

@WoutervanOoijen: अपवादों के साथ समस्या यह है कि यदि / a ब्लॉक के भीतर fooकॉल करता है , और कुछ ऑब्जेक्ट्स और कॉल बनाता है , जो एक अपवाद को फेंकता है, तो सिस्टम को नियंत्रण वापस करने से पहले बनाई गई वस्तुओं के लिए विध्वंसक को किसी तरह कॉल करना होगा । जब तक अपवाद पूरी तरह से अक्षम नहीं हो जाते , तब तक यह जानने का कोई तरीका नहीं होगा कि क्या कोई भी फेंक सकता है, और इस तरह उस संभावना के लिए अतिरिक्त कोड शामिल करना चाहिए। मैं उससे निपटने के लिए "जाँच किए गए अपवाद" के साथ C ++ का एक भिन्नता देखना चाहूंगा; अगर रूटीन अपवादों को भागने की अनुमति दे सकते हैं ...bartrycatchbarbozbarfoobarboz

— सुपरकैट

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

— सुपरकैट

: स्वाभाविक रूप से तब होता है जब कॉलर 16-बिट शब्द के साथ कॉल निर्देश का पालन करता है)। कहा जाता है कि दिनचर्या add r15,r14,#2इसके बजाय सामान्य रूप से बाहर निकल जाएगी mov r15,r14; , अपवाद के माध्यम से बाहर निकलने के लिए ldrhs r0,[r14] / add r15,r14,r0। सामान्य निकास के लिए शून्य चक्र लागत, और स्टैक-फ्रेम प्रतिबंध नहीं।

— सुपरकैट

Answer 3

हां, सी ++ निश्चित रूप से एम्बेडेड सिस्टम के लिए उपयुक्त है। पहले C और C ++ के बीच के अंतर के बारे में गलत धारणाओं को स्पष्ट करते हैं:

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

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

उन चर की प्रकृति के आधार पर निर्देशों के लगभग 4 पृष्ठ उत्पन्न कर सकते हैं।

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

सी एम्बेडेड MCUs के लिए उपयुक्त है? हां, जब तक आप उत्पन्न कोड पर नजर रखते हैं।
क्या C ++ एम्बेडेड MCU के लिए उपयुक्त है? हां, जब तक आप उत्पन्न कोड पर नजर रखते हैं।

यहाँ मुझे लगता है कि C ++ 8-बिट MCU पर भी C से बेहतर है: C ++ इसके लिए बेहतर समर्थन प्रदान करता है:

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

इन विशेषताओं में से कोई भी सी की विशिष्ट विशेषताओं की तुलना में कोई भारी नहीं है।

जब आप 16 या 32 बिट MCU तक बढ़ते हैं, तो यह सी (ढेर, ढेर, संकेत, सरणियां, प्रिंटफ, आदि) की भारी सुविधाओं का उपयोग करने के लिए समझ में आने लगता है। उसी तरह, एक अधिक शक्तिशाली एमसीयू उपयुक्त हो जाता है। सी ++ (ढेर, ढेर, संदर्भ, एसटीएल, नया / हटाएं) की भारी सुविधाओं का उपयोग करने के लिए।

तो, वहाँ एक PIC16 पर C ++ के विचार से कंपकंपी की जरूरत नहीं है। यदि आप अपनी भाषा और अपने MCU को ठीक से जानते हैं, तो आपको पता होगा कि इन दोनों को प्रभावी रूप से एक साथ कैसे उपयोग किया जाए।

Comments

यह सवाल का एक बहुत अच्छी तरह से व्यक्त और उचित जवाब है। +1 चियर्स!

— vicatcu

" a[i] = b[j] * c[k];उन चर की प्रकृति के आधार पर निर्देशों के लगभग 4 पृष्ठ उत्पन्न कर सकते हैं।" यदि आपका MCU / कंपाइलर ऐसा करता है, तो ऐसा इसलिए है क्योंकि आप 80 के दशक से कुछ गैराज हॉबीस्ट CPU का उपयोग कर रहे हैं।

— लंडिन

@ लुंडिन - आहें। नहीं, इसका मतलब है कि आप एक सस्ते छोटे MCU का उपयोग कर रहे हैं जिसे छोटे और जितना संभव हो उतना सस्ता होने के लिए डिज़ाइन किया गया है, स्टैकिंग जैसी जटिल चीजें नहीं हैं।

— रॉकेटमग्नेट

1990 में @Rocketmagnet ठीक है? आजकल गंदे 8 बिटर्स 32 बिटर्स के समान कीमत पर आते हैं। पूर्व लेने के लिए केवल कारण ही वर्तमान खपत है। और बिना स्टैक वाले उन अतिरिक्त-भद्दे 8-बिटर्स के बारे में: यदि आप इस तरह के सीमित एमसीयू के लिए कोडांतरक के बजाय सी लिख रहे हैं, तो आप संभवतः इसे गलत कर रहे हैं। उत्पन्न 4 पृष्ठ तो सीपीयू के लिए बहुत जटिल कार्यक्रम लिखने के लिए आपकी अपनी गलती है, और अनिवार्य रूप से सी कार्य के लिए गलत उपकरण है। (मैंने पिछले दिनों फ्रीस्केल RS08 पर ऐसा किया है, यह बहुत ही बेवकूफी भरा विचार था।)

— लुंडिन

@ लुंडिन 32-बिट प्रोसेसर 16-बिट की तुलना में किसी भी तेजी से आवश्यक नहीं है। यह उस दिन से स्पष्ट था जब पीसी की दुनिया में 16-टू-32 बिट प्रोग्राम संक्रमण चल रहा था।

— बार्लीमैन

Answer 4

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

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

मैंने अक्सर लोगों को इन तर्कों को शुरू करने के लिए कहा, "मैं भाषा एक्स और ब्ला ब्ला में एक विशेषज्ञ हूं" मैं ईमानदारी से इन लोगों को तुरंत बदनाम करता हूं, क्योंकि मेरी राय में, वे पहले से ही गलत कोण से समस्या का सामना कर चुके हैं और उसके बाद सब कुछ दागदार है समस्या को हल करने के लिए अपने उपकरण का उपयोग करने की उनकी इच्छा से और यह दिखाने के लिए कि यह 'कूल' कैसे है।

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

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

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

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

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

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

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

इस शेख़ी के साथ थोड़ा सा विषय होने के लिए क्षमा करें, इस विषय पर मेरी काफी मजबूत राय है।

Comments

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

— जे एटकिंसन

और मेरी सुपर लंबी टिप्पणी पर अंतिम ध्यान देने के लिए .. हमें डिजाइन के काम के लिए भाषा विशेषज्ञों की आवश्यकता नहीं है। हमें ऐसे विशेषज्ञ डिजाइनरों की आवश्यकता है जो भाषा का काम कर सकें।

— जे एटकिंसन

PRD = उत्पाद आवश्यकताएँ दस्तावेज़, MRD = विपणन आवश्यकताएँ दस्तावेज़, TRD = तकनीकी आवश्यकताएँ दस्तावेज़। टीडीडी = टेस्ट ड्रिवेन डेवलपमेंट।

— जे एटकिंसन

@ मर्क - मैं आपकी डिज़ाइन-अप-फ्रंट भावनाओं से सहमत हूं, लेकिन केवल एक बिंदु तक। मुझे लगता है कि भारी डिज़ाइन-अप-फ्रंट कार्य बंद हो जाता है यदि a) आपकी आवश्यकताएं काफी स्थिर / ज्ञात हैं, और b) डिज़ाइन करने वाले डेवलपर्स अनुभवी हैं । एक प्रचलित में। नौकरी, मुझे एक डिज़ाइन करने का काम सौंपा गया था और यह मेरी टीम लीड द्वारा बहुत समय-समय पर तय किया गया था, और मैंने सोचा, "क्या गूंगा है? डिजाइन-अप-फ्रंट पैसे बचाता है (cf. कोड कम्प्लीट बुक) ??" लेकिन कोडिंग में मुझे उन चीज़ों के बारे में पता चला, जिनकी मुझे तलाश नहीं थी। अगर मैंने बहुत सारी डिज़ाइन की होती और कोड समय को कम से कम किया होता, तो यह बेकार होता। जेएमई।

— जे। पोलर

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

— मार्क

Answer 5

कोई भी भाषा एक एम्बेडेड सिस्टम के लिए उपयुक्त हो सकती है। एंबेडेड का अर्थ है: फ्री-टू-यूज़ कंप्यूटर के विपरीत, एक बड़े उपकरण का हिस्सा।

(कठिन-) वास्तविक समय या सीमित-संसाधन प्रणाली के लिए पूछे जाने पर प्रश्न की अधिक प्रासंगिकता है।

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

बहुत संसाधन-सीमित प्रणालियों के लिए (8-बिट चिप्स, कुछ Kb से कम RAM, कोई एकसमान स्टैक नहीं) पूर्ण C ++ बीमार-अनुकूल हो सकता है, हालाँकि इसे अभी भी 'बेहतर C' के रूप में उपयोग किया जा सकता है।

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

================================================== ==============

संपादित करें: मैं नए प्रश्न का उत्तर टाइप कर रहा था ("जब हम माइक्रोकंट्रोलर की प्रोग्रामिंग कर रहे हैं, तब कौन से मामलों में C ++ आवश्यक है?"

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

• C ++ कंपाइलर C कंपाइलर से अधिक दुर्लभ हैं; कुछ लक्ष्यों के लिए (उदाहरण के लिए 12 और 14 बिट कोर PIC) कोई C ++ कंपाइलर नहीं हैं।
• (अच्छा) सी ++ प्रोग्रामर (अच्छे) सी प्रोग्रामर की तुलना में अधिक दुर्लभ हैं, खासकर उन लोगों के बीच जो इलेक्ट्रॉनिक्स में भी (कुछ) जानकार हैं।
• C ++ में C की तुलना में अधिक निर्माण हैं जो छोटे सिस्टम (जैसे अपवाद, RTTI, ढेर का लगातार उपयोग) के लिए उपयुक्त नहीं हैं।
• C ++ में C की तुलना में (मानक) पुस्तकालयों का एक समृद्ध सेट है, लेकिन पिछले बिंदु का एक परिणाम यह है कि C ++ लाइब्रेरी अक्सर ऐसी विशेषताओं का उपयोग करते हैं जो छोटे सिस्टम के लिए अनुपयुक्त हैं और इसलिए छोटे सिस्टम पर उपयोग करने योग्य नहीं हैं।
• C ++ में C की तुलना में अधिक निर्माण हैं जो आपको पैर में खुद को शूट करने की अनुमति देते हैं।
• C ++ में C की तुलना में अधिक निर्माण हैं जो आपको अपने आप को पैर में शूटिंग करने से रोकने के लिए अनुमति देते हैं (हाँ, IMO यह और पिछले दोनों सच हैं)।
• C ++ में अमूर्त तंत्र का एक समृद्ध सेट है, इसलिए यह प्रोग्रामिंग के बेहतर तरीकों को सक्षम करता है, खासकर पुस्तकालयों के लिए।
• C ++ लैंग्वेज फीचर्स (उदाहरण के लिए कंस्ट्रक्टर्स / डिस्ट्रक्टर्स, कन्वर्ज़न फंक्शन्स) जनरेट मशीन को देखने के लिए कोड के माध्यम से इसे और अधिक कठिन बना देते हैं और इस प्रकार भाषा निर्माण की जगह और समय में खर्च होता है।
• C ++ लैंग्वेज का निर्माण कम से कम इस बात से अवगत होना आवश्यक है कि मशीन कोड का अनुवाद कैसे किया जाता है क्योंकि वे अधिक सार तरीके से 'सही काम' करते हैं।
• C ++ लैंग्वेज स्टैंडर्ड तेजी से विकसित हो रहा है और बड़े कंपाइलर्स (gcc, clang, microsoft) द्वारा तेजी से अपनाया जाता है। सी, बल्कि स्पष्ट रूप से विकसित हो रहा है, और कुछ नई विशेषताओं (संस्करण सरणियों) को अपनाने से डर लगता है और यहां तक ​​कि बाद के मानक में भी वापस कर दिया गया है। विशेष रूप से यह बिंदु दिलचस्प है कि विभिन्न लोग इसका उपयोग विपरीत पदों का समर्थन करने के लिए करते हैं।
• सी ++ निस्संदेह सी की तुलना में एक तेज उपकरण है। क्या आप अपने प्रोग्रामर्स (या अपने आप पर) को एक सुंदर मूर्तिकला बनाने के लिए इस तरह के उपकरण का उपयोग करने पर भरोसा करते हैं, या क्या आप उन्हें खुद को चोट पहुंचाने का डर है और क्या आप कम सुंदर लेकिन कम जोखिम वाले उत्पाद के लिए व्यवस्थित होंगे ? (मुझे याद है कि मेरे मूर्तिकला शिक्षक ने एक बार मुझसे कहा था कि कुंद उपकरण कुछ स्थितियों में तेज से अधिक खतरनाक हो सकते हैं।)

मेरे ब्लॉग में छोटे सिस्टम (= माइक्रो-कंट्रोलर) पर C ++ का उपयोग करने पर कुछ लेख हैं।

Answer 6

मेरे अनुभव में, C ++ आमतौर पर छोटे एम्बेडेड सिस्टम के लिए बीमार है। जिससे मेरा मतलब है, माइक्रोकंट्रोलर और ओएस-कम डिवाइस।

कई सी ++ ओओपी तकनीक गतिशील मेमोरी आवंटन पर निर्भर करती हैं। यह अक्सर छोटी प्रणालियों में गायब होता है।

एसटीएल और बूस्ट वास्तव में सी ++ की शक्ति को प्रदर्शित करते हैं, दोनों पदचिह्न में विशाल हैं।

C ++ प्रोग्रामर को मशीन को दूर करने के लिए प्रोत्साहित करता है, जहाँ विवश प्रणालियों में उसे गले लगाना पड़ता है।

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

Comments

मैं छोटी प्रणालियों के संदर्भ में सहमत हूं, लेकिन मुझे लगता है कि हमारे पास छोटी प्रणालियों की अलग परिभाषा है। जब आपके पास ROM का 1kB और अच्छी तरह से लिखा गया C कोड ROM के सभी 1 बाइट लेता है, तो यह एक छोटा सिस्टम है।

— कोर्तुक

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

— कोर्तुक

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

— मार्क

"भाषाओं पर अधिकांश पवित्र युद्ध भाषाओं की क्षमताओं का परिणाम नहीं हैं, लेकिन एक तर्क यह है कि एक बेवकूफ के लिए यह कितना आसान है कि वह मूर्खतापूर्ण चीजें करता है, जो वास्तव में एक मूर्खतापूर्ण तर्क है।" बहुत ही सुखद वाक्य था। मुझे आपके अंतिम नाम की आवश्यकता है ताकि मैं उस एक को उद्धृत कर सकूं।

— कोरटुक

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

— कोर्तुक

Answer 7

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

C ++ में समस्याएं:

• अपवाद विशेष रूप से आवश्यक "आपातकालीन बफर" के रूप में एक रैम समस्या है (जहां स्मृति अपवाद बाहर उदाहरण के लिए जाता है) उपलब्ध रैम की तुलना में बड़ा हो सकता है और निश्चित रूप से माइक्रोकंट्रोलर पर एक बेकार है। अधिक जानकारी के लिए n4049 और n4234 देखें । उन्हें बंद कर दिया जाना चाहिए (जो वर्तमान में अनिर्दिष्ट व्यवहार है इसलिए सुनिश्चित करें और कभी भी फेंक न दें)। SG14 वर्तमान में ऐसा करने के बेहतर तरीकों पर काम कर रहा है।

• RTTI शायद ओवरहेड के लायक नहीं है, इसे बंद कर दिया जाना चाहिए

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

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

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

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

निष्कर्ष में C ++ में कुछ समस्याएं हैं लेकिन वे अनिवार्य रूप से सभी निश्चित या परिहार्य हैं।

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

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

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

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

सी ++ में विशेषज्ञों द्वारा इनकैप्सुलेट किया जा सकता है और कई वातावरणों में उपयोग किया जाता है जहां संकलन समय विशिष्ट कार्य के लिए कोड जनरेट करता है और स्टैटिक चेकिंग उपयोगकर्ताओं को शून्य लागत पर बेवकूफ चीजें करने से रोकता है। यहाँ हमारे पास जेनेरिक होने और तेज़ होने के बीच बहुत कम व्यापार है और इस तरह अंततः एक लागत बनाम लाभ के दृष्टिकोण से अधिक प्रदर्शनकारी, सुरक्षित और अधिक उत्पादक भाषा है।

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

Comments

मेरे उत्तर के अलावा अच्छा है :) यह रहस्यमय C ++ प्रेमी कौन होगा? उनकी प्रोफ़ाइल में कहा गया है "जाहिर है, यह उपयोगकर्ता उनके बारे में रहस्य की एक हवा रखना पसंद करते हैं।" (बुरा अंग्रेजी, बीटीडब्ल्यू) लेकिन अहा स्थान "बोचुम, जर्मनी" है ..... आप सम्मेलन में देखें!

— राउटर वैन ओइजेन

आह हाँ मेरी प्रोफ़ाइल अपडेट की गई;) अपने ईएमबीओ पर आने को जानकर अच्छा लगा ++ यह एक अच्छी भीड़ होगी

— ओडिन्थेनरड

Answer 8

मेरी पृष्ठभूमि: पुराने बेल लैब्स प्रोग्रामर के तहत स्कूल प्रशिक्षण से बाहर; 3 साल से काम कर रहा है, 2 अंडरगार्मेंट रिसर्च प्रोजेक्ट पर; VB.NET में डेटा अधिग्रहण / प्रक्रिया नियंत्रण। VB6 में एंटरप्राइज़ डेटाबेस एप्लिकेशन पर काम करते हुए 1.5 साल का समय लगा। वर्तमान में 2GB स्टोरेज के साथ एम्बेडेड पीसी के लिए प्रोजेक्ट पर काम कर रहा है , 512MB RAM, 500MHz x86 CPU; बीच में एक IPC तंत्र के साथ C ++ में समवर्ती रूप से लिखे जाने वाले कई ऐप। हां, मैं युवा हूं।

मेरी राय: मुझे लगता है कि C ++ प्रभावी ढंग से काम कर सकता है जो मैंने ऊपर लिखा माहौल दिया है । निश्चित रूप से, कठिन वास्तविक समय के प्रदर्शन के लिए ऐप की आवश्यकता नहीं है, जो मैं चालू हूं, और कुछ एम्बेडेड अनुप्रयोगों में, यह एक मुद्दा हो सकता है। लेकिन यहाँ चीजें हैं जो मैंने सीखा है:

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

• C ++ ऑब्जेक्ट-ओरिएंटेड डेवलपमेंट के रूप में अतिरिक्त सुविधाएँ प्रदान करता है जो कोड को सरल बनाने का एक तरीका प्रदान कर सकता है जिससे इसे पढ़ने / बनाए रखने में आसानी हो । ईमानदारी से, मुझे नहीं लगता कि OOP करने में प्रदर्शन / अंतरिक्ष दक्षता में सुधार के रास्ते में बहुत कुछ है। लेकिन मुझे लगता है कि ओओपी एक ऐसी तकनीक है जो जटिल समस्या को बहुत कम टुकड़ों में विभाजित करने में मदद कर सकती है। और यह कोड पर काम करने वाले लोगों के लिए सहायक है, इस प्रक्रिया का एक तत्व जिसे अनदेखा नहीं किया जाना चाहिए।

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

संपादित करें:

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

Comments

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

— कोर्तुक

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

— मार्क

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

— कोर्तुक

@ मर्क - मैं सहमत हूं। यह मेरे लिए सीखने की प्रक्रिया रही है।

— जे। पोलर

Answer 9

हां, C ++ के साथ समस्या कोड का बढ़ा हुआ पदचिह्न है।

कुछ प्रणालियों में आप बाइट्स की गिनती कर रहे हैं, और उस स्थिति में आपको चलाने की लागत को स्वीकार करना होगा कि आपके सिस्टम की सीमा के करीब सी की विकास लागत में वृद्धि हुई है।

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

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

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

Comments

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

— राउटर वैन ओइजेन सेप

गतिशील मेमोरी पर तर्क आईएमओ अधिक महत्वपूर्ण है। मैंने ऐसी औद्योगिक प्रणालियाँ देखी हैं जो हफ्तों तक रुक सकती थीं, लेकिन डायग्नोस्टिक लेयर (C ++ में लिखी गई) समय को कुछ 12 घंटों के लिए फिर से शुरू करेगी।

— दिमित्री ग्रिगोरीव

Answer 10

मुझे लगा कि लिनुस टॉर्वाल्ड्स द्वारा यह एंटी-सी ++ रेंट दिलचस्प था।

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

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

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

Comments

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

— कोरटुक

पूरी तरह से एनकैप्सुलेशन और कक्षाओं पर सहमत हुए। ऑपरेटर ओवरलोडिंग और विरासत, इतना नहीं।

— पिंगस्वैप

Haha, हाँ, ऑपरेटर ओवरलोडिंग का उपयोग कोड के कार्य को बाधित करने के लिए किया जा सकता है। यदि कोई ऑपरेटर ओवरलोडिंग कर रहा है तो उसे स्पष्ट कारणों के लिए होना चाहिए या बिल्कुल नहीं किया जाना चाहिए। वंशानुक्रम का उपयोग केवल उन विशिष्ट मामलों में किया जाना चाहिए, जहां आप वास्तव में कुछ ऐसा कर रहे हैं, जो कुछ जोड़ के साथ माता-पिता की तरह है। मुझे लगता है कि मैं ओओपी में प्रत्येक कार्य का उपयोग नहीं करूंगा। मैंने दोनों का उपयोग किया है, लेकिन एक एम्बेडेड सिस्टम में एक केस के बारे में नहीं सोचा जा सकता है। जिस तरह मुझे लगता है कि चर नामों पर एक 80 अक्षर की सीमा के साथ एक कंपाइलर को तुरंत हटा दिया जाना चाहिए।

— कोरटुक

मैं सिर्फ पायथन में एक MCU प्रोग्रामिंग के बारे में सोचा था कि मेरे मुंह में एक छोटे से फेंक दिया ...

— vicatcu

आप केवल एक ही नहीं हैं, लेकिन अगर यह अच्छी तरह से काम करता है और कुशल है, तो मैं माफ कर सकता हूं।

— कोरटुक

Answer 11

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

छोटे माइक्रोकंट्रोलर्स (8-बिट) के लिए, कोई रास्ता नहीं। आप बस अपने आप को चोट पहुंचाने के लिए कह रहे हैं, कोई फायदा नहीं है और आप बहुत अधिक संसाधन छोड़ देंगे।

उच्च अंत माइक्रोकंट्रोलर्स (उदाहरण के लिए रैम और स्टोरेज के लिए 32-बिट, 10 या 100 एमबी) जो कि एक सभ्य ओएस है यह पूरी तरह से ठीक है और, मैं कहने की हिम्मत भी करूंगा।

तो सवाल यह है: सीमा कहां है?

मुझे यकीन नहीं है, लेकिन एक बार मैंने C ++ में 1 एमबी रैम और 1 एमबी स्टोरेज के साथ 16-बिट यूसी के लिए एक सिस्टम विकसित किया, केवल बाद में पछताने के लिए। हाँ, यह काम किया है, लेकिन अतिरिक्त काम मैं इसके लायक नहीं था। मुझे इसे फिट करना था, सुनिश्चित करें कि अपवाद जैसी चीजें लीक का उत्पादन नहीं करेंगी (ओएस + आरटीएल समर्थन बहुत छोटी और अविश्वसनीय था)। इसके अलावा, एक OO ऐप आमतौर पर बहुत से छोटे आवंटन करता है, और उन लोगों के लिए ढेर ओवरहेड एक और बुरा सपना था।

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

Comments

मुझे यहाँ असहमत होना है, कोई अचानक बिंदु नहीं है जहाँ C ++ सिस्टम संसाधनों के कारण स्वीकार्य हो जाता है, अच्छा डिज़ाइन अभ्यास C ++ के पदचिह्न को रख सकता है जहाँ C का पदचिह्न है। यह OOP डिजाइनों के साथ कोड में परिणाम देता है जो समान स्थान लेते हैं। खराब लिखा हुआ C उतना ही बुरा हो सकता है।

— कोरटुक

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

— fceconel

Answer 12

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

यदि मेरे पास मेरे शराबी होते, तो एक लोकप्रिय भाषा होती जो दोनों दुनिया के सर्वश्रेष्ठ को जोड़ती थी, और इसमें कुछ विशेषताएं शामिल थीं, जिनकी दोनों भाषाओं में कमी है; कुछ विक्रेताओं में ऐसी कुछ विशेषताएं शामिल हैं, लेकिन कोई मानक नहीं हैं। कुछ चीजें जो मैं देखना चाहता हूं:

1. एक्सेप्शन को जावा की तरह थोड़ा अधिक संभालना, जहां फ़ंक्शन जो अपवादों को फेंक या लीक कर सकते हैं उन्हें इस तरह घोषित किया जाना चाहिए। हालांकि इस तरह की घोषणाओं की आवश्यकता प्रोग्रामिंग के नजरिए से कुछ हद तक कष्टप्रद हो सकती है, लेकिन यह उन मामलों में कोड की स्पष्टता को बेहतर बनाता है जहां कोई फ़ंक्शन एक मनमाना पूर्णांक लौटा सकता है यदि वह सफल होता है, लेकिन विफल भी हो सकता है। कई प्लेटफ़ॉर्म इसे कोड में सस्ते में संभाल सकते हैं, जैसे रजिस्टर में रिटर्न वैल्यू और कैरी फ़्लैग में सफलता / विफलता संकेत।
2. केवल स्थैतिक और इनलाइन कार्यों का ओवरलोडिंग; मेरी समझ यह है कि C के लिए मानक निकाय ने फ़ंक्शन ओवरलोडिंग से बचा लिया है ताकि नाम की आवश्यकता के लिए मैलिंग न हो। स्थैतिक और इनलाइन कार्यों के अधिभार के कारण केवल उस समस्या से बचना होगा, और बाहरी कार्यों को ओवरलोडिंग के लाभ का 99.9% देगा (क्योंकि .h फाइलें इनलाइन ओवरलोड को अलग-अलग बाहरी कार्यों के संदर्भ में परिभाषित कर सकती हैं)
3. मनमाने ढंग से या विशिष्ट संकलन-समय-resolvable निरंतर पैरामीटर मूल्यों के लिए अधिभार। कुछ कार्य किसी भी निरंतर मान के साथ पारित होने पर बहुत कुशलता से इनलाइन कर सकते हैं, लेकिन एक चर पारित होने पर बहुत खराब तरीके से इनलाइन। यदि कोई मान स्थिर है, तो अन्य बार कोड एक अनुकूलन हो सकता है अगर यह नहीं है। उदाहरण के लिए:

   इनलाइन शून्य copy_uint32s (uint32_t * dest, const uint32_t * src, __is_const int n)
   {
     if (n <= 0) वापसी;
     और अगर (n == 1) {भाग्य [0] = src [0] ;;
     और अगर (n == 2) {भाग्य [0] = src [0]; भाग्य [1] = src [1];}
     और अगर (n == 3) {भाग्य [0] = src [0]; भाग्य [1] = src [1]; भाग्य [2] = src [2];}
     और अगर (n == 4) {भाग्य [0] = src [0]; भाग्य [1] = src [1]; भाग्य [2] = src [2]; भाग्य [3] = src [3];}
     और यादगार ((शून्य *) भाग्य, (कॉन्स्टेबल शून्य *) src, n * sizeof (* src));
   }
   

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

मुझे पता है कि C ++ का पिता C ++ के केवल-एम्बेडेड संस्करण पर बहुत उत्सुक नहीं है, लेकिन मुझे लगता है कि यह केवल C का उपयोग करने पर कुछ महत्वपूर्ण सुधारों की पेशकश कर सकता है।

किसी को भी पता है कि क्या ऊपर की तरह किसी भी प्रकार के मानक के लिए विचार किया जा रहा है?

Comments

en.wikipedia.org/wiki/Embedded_C%2B%2B

— Toby Jaffey

@ जॉबी टैफी: मुझे लगता है कि मैंने अपनी पोस्ट को यह उल्लेख करने के लिए संपादित किया कि सी ++ का निर्माता एक एम्बेडेड लॉकेट के लिए उत्सुक नहीं था; मुझे पता है कि वहाँ प्रयास थे, लेकिन मेरी समझ से वे वास्तव में अभी तक नहीं मिल पाए हैं। मुझे लगता है कि एक मानकीकृत भाषा के लिए निश्चित उपयोग होगा जो 8-बिट प्रोसेसर के लिए उत्तरदायी होगा, और जैसा कि मैंने ऊपर वर्णित सुविधाओं को किसी भी मंच पर उपयोगी लगेगा। क्या आपने किसी भाषा को # 3 से ऊपर की चीज़ों की पेशकश करते हुए सुना है? यह बहुत उपयोगी प्रतीत होता है, लेकिन मैंने कभी किसी भाषा की पेशकश नहीं देखी।

— सुपरकैट

"C ++ के पिता" को एम्बेडेड सिस्टम प्रोग्रामिंग का शून्य अनुभव है, तो कोई भी उनकी राय के बारे में क्यों ध्यान रखेगा?

— लंडिन

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

— सुपरकैट

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

— सुपरकैट

Answer 13

C ++ अधिक है कि एक प्रोग्रामिंग भाषा:

a) यह "बेहतर" C b है) यह एक वस्तु उन्मुख भाषा है c) यह एक ऐसी भाषा है जो हमें जेनेरिक प्रोग्राम लिखने की अनुमति देती है

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

a) यह "बेहतर" C है

सी ++ एक मजबूत टाइप की गई भाषा है; C. से अधिक मजबूत। आपके कार्यक्रम इस सुविधा से लाभान्वित होंगे।

कुछ लोग पॉइंटर्स से डरते हैं। C ++ में संदर्भ शामिल हैं। अतिभारित कार्य।

और कहने लायक: बड़े या धीमे कार्यक्रमों में इनमें से कोई भी विशेषता नहीं है।

b) यह एक वस्तु उन्मुख भाषा है

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

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

/ * TICKRATE_HZ * पर मिलान और व्यवधान के लिए टाइमर सेटअप

Chip_TIMER_Reset (LPC_TIMER32_0);

Chip_TIMER_MatchEnableInt (LPC_TIMER32_0, 1);

Chip_TIMER_SetMatch (LPC_TIMER32_0, 1, (टाइमरफ़्रेक / TICKRATE_HZ2));

Chip_TIMER_ResetOnMatchEnable (LPC_TIMER32_0, 1);

Chip_TIMER_Enable (LPC_TIMER32_0);

क्या आपको अमूर्तता दिखाई देती है? इसलिए, जब C ++ का उपयोग एक ही उद्देश्य के लिए किया जाता है, तो अमूर्त को शून्य लागत पर C ++ के एब्स्ट्रैक्शन और एनकैप्सुलेशन तंत्र के माध्यम से अगले स्तर पर लाया जाता है!

ग) यह एक ऐसी भाषा है जो हमें सामान्य कार्यक्रम लिखने की अनुमति देती है

जेनेरिक प्रोग्राम टेम्प्लेट के माध्यम से प्राप्त किए जाते हैं, और टेम्प्लेट की भी हमारे कार्यक्रमों के लिए कोई कीमत नहीं होती है।

इसके अलावा, स्थैतिक बहुरूपता को टेम्पलेट्स के साथ हासिल किया जाता है।

वर्चुअल तरीके, RTTI और अपवाद।

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

अंत में, RTTI और अपवादों के बारे में एक सलाह: एम्बेडेड सिस्टम में उपयोग न करें। हर कीमत पर इनसे बचें !!

Answer 14

मेरी पृष्ठभूमि, एम्बेडेड (एमसीयू, पीसी, यूनिक्स, अन्य), रीयलटाइम। सुरक्षा महत्वपूर्ण। मैंने एसटीएल में पिछले नियोक्ता को पेश किया। मैं अब ऐसा नहीं करता।

कुछ लौ सामग्री

क्या सी ++ एम्बेडेड सिस्टम के लिए उपयुक्त है?

भावहीन। C ++ लिखने के लिए एक दर्द है और बनाए रखने के लिए एक दर्द है। C + ठीक प्रकार का है (कुछ सुविधाओं का उपयोग न करें)

माइक्रोकंट्रोलर्स में सी ++? RTOSes? टोस्टर? एंबेडेड पीसी?

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

क्या OOP माइक्रोकंट्रोलर पर उपयोगी है?

यकीन है। UART एक वस्तु है ..... DMAC एक वस्तु है ...

ऑब्जेक्ट स्टेट मशीनें बहुत आसान हैं।

क्या C ++ प्रोग्रामर को हार्डवेयर से बहुत अधिक दूर करता है कुशल होने के लिए?

जब तक यह एक पीडीपी -11 नहीं है, तब तक अपने सीपीयू को सी न करें। सी ++ मूल रूप से सी का एक प्रीप्रोसेसर ऑनर था इसलिए बजरन स्ट्रॉस्ट्रुप एटी एंड टी में धीमी सिमूला सिमुलेशन होने के लिए हंसी को रोकना होगा। C ++ आपके CPU नहीं है।

जाओ एक MCU कि जावा bytecodes चलाता है। जावा में कार्यक्रम। हंसो सी लोगों पर।

क्या Arduino के C ++ (बिना डायनामिक मेमोरी मैनेजमेंट, टेम्प्लेट, अपवाद) के साथ "वास्तविक C ++" माना जाना चाहिए?

नहीं। MCU के लिए सभी bastardised C कंपाइलर की तरह।

फोर्थ, एंबेडेड जावा या एंबेडेड एडीए मानकीकृत (ईश) हैं; बाकी सब दुःख है।

Comments

क्या जावा का समर्थन करने वाले माइक्रोकंट्रोलर्स को ढूंढना आसान है? मुझे लगता है कि यह विकल्पों को काफी सीमित कर देगा। और प्रदर्शन के दंड के बारे में आपके अनुभव क्या हैं (चूंकि यूसीएस में आपके पास आमतौर पर जेआईटी नहीं होता है)? रीयलटाइम प्रणालियों में जीसी अप्रत्याशितता के प्रभाव के बारे में क्या?

— fceconel

क्या MCUs बाहर हैं जो एम्बेडेड Java का समर्थन करते हैं?

— जे। पोलफर

शुरुआत के लिए www.ajile.com।

— टिम विलक्रॉफ्ट

एडा के लिए +1। यह बहुत कुछ मिल रहा है इसके लिए एम्बेडेड है, जिसमें Arduinos भी शामिल है।

— ब्रायन ड्रमंड

सी में लिखे माइक्रो के लिए पोर्टेबल जावा वीएम खुला स्रोत है। dmitry.co/index.php?p=./04.Thoughts/…

— Tim Williscroft

Answer 15

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

Comments

मुझे वास्तव में यकीन नहीं है कि यह चर्चा में क्या जोड़ता है।

— डेव ट्वीड

Answer 16

<शेख़ी>

मुझे लगता है कि C ++ पहले स्थान पर एक भद्दी भाषा है। यदि आप OOP का उपयोग करना चाहते हैं, तो Java प्रोग्राम लिखें। C ++ OOP प्रतिमानों को लागू करने के लिए कुछ भी नहीं करता है, क्योंकि प्रत्यक्ष मेमोरी एक्सेस पूरी तरह से आपकी (ab) उपयोग की शक्ति के भीतर है।

यदि आपके पास MCU है, तो आप फ्लैश मेमोरी के 100kB से कम होने की संभावना के बारे में बात कर रहे हैं। आप एक ऐसी भाषा में प्रोग्रामिंग करना चाहते हैं, जिसकी स्मृति में अमूर्तता है: जब मैं एक चर या सरणी की घोषणा करता हूं, तो यह मेमोरी, अवधि प्राप्त करता है; Malloc (उर्फ "नया" C ++ में कीवर्ड) कमोबेश एम्बेडेड सॉफ़्टवेयर में उपयोग से प्रतिबंधित होना चाहिए, शायद ही कभी दुर्लभ अवसरों में प्रोग्राम स्टार्टअप के दौरान एक कॉल।

नरक, एम्बेडेड प्रोग्रामिंग में ऐसे (अक्सर) बार होते हैं जहां सी काफी निम्न स्तर का नहीं होता है, और आपको रजिस्टरों के लिए वेरिएबल आवंटित करने और अपने इंटरप्रेन सर्विस रूट्स (आईएसआर) को कसने के लिए इनलाइन असेंबली लिखने की आवश्यकता होती है। "अस्थिर" जैसे कीवर्ड समझने के लिए बहुत महत्वपूर्ण हो जाते हैं। आप अपना बहुत समय बिट स्तर पर मेमोरी में हेरफेर करने में बिताते हैं , न कि वस्तु स्तर पर।

आप खुद को यह सोचकर बहकाना क्यों चाहेंगे कि चीजें वास्तव में सरल हैं क्योंकि वे वास्तव में हैं?

</ शेख़ी>

Comments

यहाँ मेरा मुद्दा बस इतना है कि मैं उस चालक की जटिलता को क्यों जानना चाहता हूं जो कि USART1 को नियंत्रित करने के लिए लिखा गया था अगर इसे इंटरफ़ेस को संभालने के लिए पूरी तरह से विकसित किया गया है।

— कोरटुक

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

— कोरटुक

सभी भाषाएं कुछ के लिए अच्छी हैं। C ++ तेज है। OOP, अगर अच्छी तरह से किया जाता है, तो कई डेवलपर्स के लिए समानांतर में काम करना और अज्ञात के लिए कोड करना बहुत आसान हो जाता है। मुझे लगता है यही कारण है कि खेल के विकास में इसका बहुत अधिक कर्षण है।

— टोबी जाफि

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

— कोरटुक

फिर भी एक और व्यक्ति जो C ++ को ठीक से नहीं समझता है। यह हमेशा मुझे आश्चर्यचकित करता है कि कितने हैं।

— Rocketmagnet