2010-02-24 15 views
8

संभव डुप्लिकेट:
Why artificially limit your code to C?कोई C++ के बजाय सी का उपयोग क्यों करेगा?

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

+0

http://stackoverflow.com/questions/649789/why-artificially-limit-your-code-to-c –

+16

कोई खाद्य प्रोसेसर की बजाय चाकू का उपयोग क्यों करेगा? –

+0

@ नील बटरवर्थ कूल, धन्यवाद। –

उत्तर

3

यह बस हो सकता है कि वे मंच के साथ वे काम कर रहे हैं के लिए एक सी ++ संकलक नहीं है ... व्यक्तिगत तौर पर मैं हमेशा सी ++ वरीयता में सी के लिए प्रयोग करेंगे

3

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

4

सी स्ट्रिंग हैंडलिंग बहुत सी ++ ठेठ स्ट्रिंग कोड से अलग है। निश्चित रूप से मैं अपने ड्राइवरों के पास कोई सी ++ स्ट्रिंग नहीं चाहता!

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

हां, सी ++ में अच्छे ड्राइवर लिखना संभव है; लेकिन सी ++ वास्तव में कुछ अतिरिक्त सुविधाओं के साथ सी की तरह दिखता है। अधिकांश सी ++ पुस्तकालय में देवता में कोई जगह नहीं है।

1

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

-1

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

संबंधित मुद्दे