ऑपरेटिंग सिस्टम C और C ++ में निम्न स्तर का सामान क्यों करते हैं? सिर्फ C ++ क्यों नहीं?


20

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

IIRC, आप extern "C"'d' ब्लॉक से C ++ फ़ंक्शन को कॉल कर सकते हैं । मैं कर्नेल फ़ंक्शंस के लिए C का उपयोग कर सकता हूं, इसलिए शुद्ध C एप्लिकेशन उनका उपयोग कर सकते हैं (जैसे printfऔर ऐसे), लेकिन अगर वे सिर्फ एक extern "C "ब्लॉक में लपेटे जा सकते हैं , तो सी में कोड क्यों?


10
क्या आपने देखा है कि "C ++ होने पर C का उपयोग क्यों करें?" यहाँ सवाल? यह आवश्यक रूप से उनमें से किसी का डुप्लिकेट नहीं है, लेकिन वे कर रहे हैं संबंधित।

1
"आप C ++ फ़ंक्शन को बाहरी" C "डी ब्लॉक से C ++ कह सकते हैं" क्या आपका मतलब है कि आप C फ़ंक्शन को कॉल कर सकते हैं ...?
संहिता-गुरु

@ कोड-गुरु नहीं, क्योंकि निर्यात किए गए C और C ++ फ़ंक्शंस के बीच एकमात्र अंतर नाम सजावट और C ++ में है, thisचर के अलावा
कोल जॉनसन

2
एक ISR में एक अपवाद को फेंक दें और देखें कि क्या होता है
जेम्स

फिर भी एक और सी बनाम सी ++ सवाल।
माचादो 12

जवाबों:


31

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


+1, मुझे लगता है कि यह सबसे यथार्थवादी उत्तर है (इस तथ्य के अलावा कि कुछ विंडोज कर्नेल देव हो सकते हैं जो सिर्फ C ++ को पसंद नहीं करते हैं या उस निम्न-स्तरीय सामान के लिए C ++ कंपाइलर पर भरोसा नहीं करते हैं)। उदाहरण के लिए, यहां देखें stackoverflow.com/questions/520068/… , लिनक्स कर्नेल को C. में क्यों लिखा गया है
Doc Brown

@ back2dos - जबकि उनके C कोड को फेंका नहीं जाएगा, इसका मतलब यह नहीं है कि इसका उपयोग किया जाएगा या अपडेट नहीं किया जाएगा। मैं आपको गारंटी देता हूं कि कम से कम एक तरीका है जो कुछ ऐसा करता है जो मूल रूप से सी लाइब्रेरी के भीतर लिखा और समाहित किया गया था जिसे विंडोज 8 में सी ++ लाइब्रेरी में पोर्ट किया गया है
रामहाउंड

8
मेरा मानना ​​है कि विंडोज के किसी भी हाल के रिलीज में विंडोज 1.0 कोड है। विंडोज एमई आखिरी विंडोज रिलीज थी जो विंडोज एनटी कोड बेस पर आधारित नहीं थी। और यहां तक ​​कि बड़े पैमाने पर नए आरटी कर्नेल द्वारा प्रतिस्थापित किया गया है (जो, जैसा कि मैं इसे समझता हूं, पीछे की ओर संगतता के तरीके में बहुत वादा नहीं करता है)।
टीएमएन

@ टीएमएन: यह तर्क शायद सबसे सही है या नहीं - मुझे विन 1.0 से सड़क पर बहुत यकीन है अब तक सी में बहुत सारे पुस्तकालय लिखे गए थे जो अभी भी मौजूदा Win8 कोड बेस का हिस्सा हैं, और एमएस में कोई भी किसी को नहीं देखता है C ++ में उन्हें फिर से लिखने के लिए लाभ।
डॉक ब्राउन

1
शायद ही कोई कोड हो जो विंडोज कर्नेल से किसी भी तरह बात करता हो। असल में, केवल ड्राइवर करते हैं। अनुप्रयोग आमतौर पर Win32 API या संभवतः POSIX API से बात करते हैं।
MSalters

24

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

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

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

C को निम्न स्तर की प्रोग्रामिंग में अपनी प्रमुख जगह से C को विस्थापित करने की कोशिश की गई है जो कि बिटकॉइन की तरह इस पर भी बेहतर हैं, लेकिन वे अभी तक सफल नहीं हुए हैं।


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

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

2
@ लुंडिन MISRA दिशानिर्देश एक सुरक्षित उपसमुच्चय नहीं हैं - आपके पास अभी भी कच्चे पॉइंटर्स और अधिकांश अन्य विशेषताएं हैं जो C को असुरक्षित बनाती हैं - वे मुख्य रूप से कार्यान्वयन विशिष्ट व्यवहार का उपयोग या दस्तावेजीकरण नहीं करने पर ध्यान केंद्रित करते हैं।
पीट किरखम

@PeteKirkham MISRA-C सभी सबसे क्लासिक पॉइंटर बग्स को पकड़ेगा और स्थैतिक विश्लेषण को लागू करेगा। उद्योग सुरक्षा मानक (IEC 61508 et al) स्पष्ट रूप से MISRA-C को सी के एक सुरक्षित उप-समूह के रूप में स्वीकार करते हैं। मिशन-क्रिटिकल सॉफ़्टवेयर के लिए कई अन्य उपयोगी विकल्प नहीं हैं, जब तक कि आप SPARK Ada को नहीं चुनते हैं, एक भाषा जो कुछ को सीमित उपकरण के साथ जानती है। सहयोग।

2
यह सही होने पर सर्वश्रेष्ठ उत्तर के रूप में चुना जाना चाहिए था। अन्य लोग जो सी का सुझाव देते हैं, उनका उपयोग केवल ऐतिहासिक कारणों से किया जाता है, यह अपने आप में हिस्टेरिकल है।
रोब

15
  1. C रनटाइम बहुत छोटा है।
  2. सी-लोअर कंस्ट्रक्शन में सी ++ का अनुवाद सी की तुलना में कम पारदर्शी है (दो त्वरित उदाहरणों के लिए संदर्भ और vtables देखें)
  3. C में आमतौर पर एक स्थिर ABI होता है। सी ++ आमतौर पर नहीं होता है। इसका मतलब है कि नंगे न्यूनतम पर, सिस्टम कॉल इंटरफ़ेस सी शैली होना चाहिए। इसके अलावा, यदि आप किसी भी प्रकार के डायनामिक मॉड्यूल चाहते हैं, तो लगातार ABI होने से बहुत मदद मिलती है।

+1 (2) और (3) के लिए। मैं (1) के साथ आश्वस्त नहीं हूं।
थॉमस एडिंग

7
@ थोमस ईडिंग: सी ++ रनटाइम में सी रनटाइम होता है, प्लस सी ++ में एक अपवाद, आरटीटीआई और एक अन्य मेमोरी एलोकेटर जैसी विशेषताएं होती हैं। YMMV के रूप में है कि क्या के रूप में ज्यादा बड़ा मायने रखता है । (और फिर वहाँ मानक पुस्तकालय है ...)
12'12

आह, मैं अपवादों और नए / विलोपन पूलों के बारे में भूल गया। RTTI मैं कभी उपयोग नहीं करता: D
थॉमस Eding

11

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

यहां तक ​​कि हमारे पास सी फ़ाइलों की एक smattering है, ज्यादातर तीसरे पक्ष के कोड के कारण। तृतीय-पक्ष निम्न-स्तरीय कोड लगभग हमेशा C में प्रदान किया जाता है, क्योंकि C कोड को C ++ ऐप में अन्य तरीके से शामिल करना बहुत आसान है।


6

कर्नेल डेवलपर्स अक्सर ऐसे लोग होते हैं, जो खुशी महसूस करते हैं, जब यह स्रोत से तुरंत स्पष्ट होता है, तो कोड वास्तव में क्या करता है।

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

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

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

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

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


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

स्पष्टीकरण: गुठली के लिए आपको यह मानकर चलना होगा कि CPU अपना अधिकांश समय उपयोगकर्ता-अंतरिक्ष में बिताता है और कर्नेल कोड का उपयोग छिटपुट रूप से किया जाता है (जैसे जब उपयोगकर्ता-स्पेस कर्नेल एपीआई या कोई व्यवधान होता है); जिसका अर्थ है कि आपको "कोल्ड कैश" मान लेना है। आधुनिक CPU के लिए (जहां RAM CPU की गति के सापेक्ष धीमी है) कैश और TLB की मिसाइलें महंगी होती हैं, इसलिए ("कोल्ड कैश" अपेक्षा के साथ संयुक्त) "कैश लाइनों को छुआ" मीट्रिक प्रदर्शन और / या स्केलेबिलिटी के लिए एक अत्यंत महत्वपूर्ण संकेतक बन जाता है।
22

5

Bjarne Stroustrup, जुलाई 1999 में एक साक्षात्कार में :

इनमें से कोई भी भाषा अन्य समकालीन भाषाओं की तुलना में मौलिक रूप से भिन्न या नाटकीय रूप से बेहतर नहीं थी। हालांकि, वे काफी अच्छे और भाग्य और सामाजिक कारकों के लाभार्थी थे


2
स्वागत है डेविड। जब उद्धृत या उद्धृत करते हैं, तो एक संदर्भ प्रदान करना एक अच्छा विचार है (जोड़ा गया!)
एंड्रयू

3

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

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

दो का संयोजन एक बहुत ही पारंपरिक है; आप कोडबेस के सबसे अधिक प्रदर्शन-महत्वपूर्ण, मेमोरी-कुशल क्षेत्रों को लिखने के लिए C का उपयोग करते हैं, जिसे आप C ++ कोड से विधि कॉल के माध्यम से अधिक अमूर्त फैशन के साथ काम कर सकते हैं, जिसे uber-performant की तुलना में अधिक सुरुचिपूर्ण ढंग से व्यवस्थित और डिज़ाइन किया जा सकता है , uber-oogly अनुकूलित C कोड।


2
दक्षता के बारे में, मैं खुद को दोहराऊंगा: (1) सी ++ लोग आपको बताएंगे कि वह बकवास है। (२) मैं कह रहा हूँ कि मुझे ऐसा कोई कारण नहीं दिख रहा है, ऐसा होना चाहिए, और ठोस उदाहरण चाहिए। कम कुशल कोड लिखना कितना आसान है, इसके उदाहरण नहीं, लेकिन C के रूप में कुशल होने के उदाहरणों में अनुचित कुरूपता की आवश्यकता होती है।

3
"बदसूरत" को परिभाषित करें; मैं जीवित रहने के लिए C # में कोड करता हूं, और जब भी मैं StackOverflow I में C ++ कोड उदाहरण देखता हूं, तो भाषा के दिन-प्रति-दिन के उपयोग में कितना cruft सामान्य माना जाता है। जब मैंने C ++ में वापस कोड किया था जब, मैंने अक्सर C कोड देखा और cringed; हाथ से पैकिंग संरचना प्रकार, मैनुअल जंप के लिए निष्पादन सूचक गणना, एएसएम एम्बेडेड ... yuck। कुछ लोग जावा / .NET प्रोग्रामर के बीच निम्न-स्तरीय ज्ञान के नुकसान के बारे में सोचते हैं; मैं इसे उत्पादकता का बहुत बड़ा वरदान मानता हूं।
कीथ्स

1
आपने मेरे सवाल का जवाब नहीं दिया;) "बदसूरत" से मेरा मतलब है "सी ++ गुरुओं के मानकों द्वारा बदसूरत"। दूसरे शब्दों में, उदाहरण जहां कोई "आधुनिक सी ++" का उपयोग नहीं कर सकता है और सी के रूप में कुशल हो सकता है

2
यह सच हो सकता है (मैं ईमानदारी से नहीं जानता)। कर्नेल विकास (और कुछ अन्य क्षेत्रों) के लिए, हम औसत प्रोग्रामर के बारे में बात नहीं कर रहे हैं।

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

1

यह हो सकता है कि सी के साथ आप अपना अधिकांश समय हाथ में समस्या के बारे में सोचने और समाधान को कोड करने में बिताएं। C ++ में आप C ++ और इसके असंख्य विशेषताओं, फ़ंक्शंस और अस्पष्ट सिंटैक्स के बारे में सोचते हैं।

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

मेरा अनुभव यह है कि सभी चालाक सुविधाओं और C ++ की OO शुद्धता के लिए, सादे C में कोडिंग से काम जल्दी और अधिक प्रभावी ढंग से हो जाता है।


0

यह संभव है कि C पार्ट्स C ++ कंपाइलर के लिए अच्छी तरह से पोर्टेबल न हो जो C ++ भागों के लिए उपयोग किया जाता है। हो सकता है कि C कोड सी कंपाइलर के साथ सी कोड के साथ टूट गया हो।

यदि आपके पास गुणवत्ता C ++ कंपाइलर है, तो प्रोजेक्ट में C और C ++ को मिलाने का लगभग कोई कारण नहीं है। लगभग।

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


-1

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


-2

प्रोग्रामिंग भाषा के रूप में सी का उपयोग करने वाले विभिन्न प्रकार के एम्बेडेड प्लेटफॉर्म हैं (बेशक यह किसी भी समय विधानसभा भाषा का उपयोग करने की आपकी स्वतंत्रता है)

'स्तर' के लिए मैं सिस्टम के लिए आंतरिक SRAM और ROM संसाधन स्तर के बारे में बात कर रहा हूं।

ये प्लेटफ़ॉर्म कभी-कभी संसाधन के लिए बाध्य होते हैं (जैसे कुछ 8051 प्लेटफ़ॉर्म में केवल उपयोगकर्ता SRAM के 128 बाइट्स हैं)।

रैम के लिए इतनी कम राशि के साथ गतिशील मेमोरी आवंटन का समर्थन करना अर्थहीन है। (new / delete) या सी में भी मॉलोक।

C से C ++ तक मुख्य सुधार में से एक वस्तु-उन्मुख प्रतिमान है। C ++ बड़े मेमोरी फुटप्रिंट वाले सॉफ्टवेयर में उपयुक्त है

लेकिन एम्बेडेड फर्मवेयर में नहीं, जिसका आकार 32KB तक सीमित है। (उदाहरण के लिए 16-बिट MCU प्लेटफॉर्म में)

सी ++ संकलक होने की कोई आवश्यकता नहीं है जो आमतौर पर सी संकलक की तुलना में अधिक जटिल है। (कम से कम एसडीके प्रदाता ऐसा करने के लिए परेशान नहीं करेंगे)।

वास्तव में मैं 32-बिट ARM7 प्लेटफॉर्म पर शायद ही सी ++ संकलक पा सकता हूं।

यह सिर्फ जटिलता के लायक नहीं है

कुछ 8051 में (8 बिट): 1 एमबी रोम, 128 बी रैम

TI MSP430 (16 बिट): 32KB रोम, 4KB रैम

ST माइक्रोइलेक्ट्रॉनिक ARM 32-बिट कॉर्टेक्स ™ -M3 CPU कोर (STM32F103T4): 16 या 32 Kbytes फ़्लैश मेमोरी 6 या 10 Kbytes of SRAM


2
यह पहले से ही यहां पोस्ट किए गए अन्य उत्तरों के लिए कुछ भी नया नहीं है।
मार्टिगन पीटरर्स

एआरएम के लिए एक 32-बिट सी ++ संकलक? यदि आप चाहते हैं, तो आप iOS के लिए C ++ कंपाइलर प्राप्त करने के लिए कुछ संशोधनों के बाद LLVM को स्वयं स्रोत से संकलित कर सकते हैं।
कोल जॉनसन

-4

मुझे कुछ संभावित कारण दिखाई देते हैं:

  • यदि C ++ समकक्ष की तुलना में C थोड़ा अधिक कुशल है।
  • कुछ पुस्तकालयों का उपयोग वे सी में लिखे गए हैं।
  • वे लिनक्स कर्नेल के कुछ हिस्सों का उपयोग करते हैं, जो सी में लिखा गया है।

संपादित: जैसा कि यह निकला, तीसरा तर्क सत्य नहीं है (टिप्पणियों को देखें)।


5
(1) C ++ के लोग अलग-अलग होते हैं। और वस्तुतः मुझे लगता है कि ऐसा नहीं होना चाहिए। (2) C ++ केवल C कोड में कॉल कर सकता है (यह बैकवर्ड कम्पैटिबिलिटी का पूरा बिंदु है और extern "C")।

1
यदि MS लिनक्स कर्नेल के कुछ हिस्सों का उपयोग करता है, और लिनक्स कर्नेल GPL है, तो क्या इसका अर्थ यह नहीं होगा कि विंडोज को भी GPL होना चाहिए?
टॉमजे

1
@ टॉम्ज वास्तव में यही कारण है कि उन्हें लिनक्स के साथ-साथ एक जोड़ी हजारों लाइनें दान करने के लिए मजबूर किया गया था। + आपको क्यों लगता है कि वे लिनक्स विकास का समर्थन करते हैं?
१ij:०५ पर पीजूसन

2
@Pius उसकी बात है (और वह सही AFAIK है), अगर विंडोज कर्नेल में GPL का कोड जुड़ा होता, तो पूरे कर्नेल को GPL'd होना चाहिए (बशर्ते कॉपीराइट धारकों के साथ कोई अलग समझौता न हो)।

@ डलेन, विवरण के बारे में निश्चित नहीं है। मैं वकील नहीं हूँ इसलिए मैं उस पर टिप्पणी नहीं कर सकता। लेकिन इस बारे में कुछ साल पहले एक छोटा सा घोटाला हुआ था। यकीन नहीं है, लेकिन मुझे लगता है कि मैं नेटवर्किंग मॉड्यूल हो सकता था सभी पागल सामान के बारे में था।
पीजूस 18

-4

क्योंकि C यकीनन C ++ से बेहतर भाषा है। और क्योंकि C ++ लोकप्रिय होने से पहले कुछ कोड लिखे गए थे और लोगों के पास इसे प्रतिस्थापित करने का कोई कारण नहीं था।

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


C ++ डायनेमिक लाइब्रेरीज़ की अपेक्षा करता है? और गतिशील मेमोरी क्या है?

4
-1 के लिए [stuff] that C++ expects। C ++ C की तुलना में अधिक हीप का उपयोग क्यों करता है? C ++ को C से अधिक dll की आवश्यकता क्यों है? सीधे शब्दों में नहीं
थॉमस एडिंग

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

6
क्या? टेम्प्लेट, अपवाद, ऑब्जेक्ट (जिसमें कंस्ट्रक्टर, डिस्ट्रक्टर्स, ओवरलोड ऑपरेटर शामिल हैं, अब कंस्ट्रक्शन को आगे बढ़ाते हैं, और - प्रैक्टिकली? - बाकी सब कुछ), आदि ठीक से काम करते हैं, भले ही मेमोरी से (स्टैक, स्टैटिक मेमोरी, आपका कस्टम पूल, या जो भी हो) । मानक कंटेनर डिफ़ॉल्ट रूप से हीप आवंटन का उपयोग करते हैं, लेकिन उनके आवंटन को अनुकूलित किया जा सकता है और कर्नेल लोग वैसे भी अपने संग्रह और मेमोरी प्रबंधन लिख सकते हैं। -1

2
FYI करें: मैंने अपना डाउनवोट हटा दिया क्योंकि मुझे नहीं लगता कि आपका उत्तर अब तक सक्रिय रूप से हानिकारक है, लेकिन मैं इसे विशेष रूप से उपयोगी या व्यावहारिक नहीं मानता।
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.