C ++ से C पर जाना


83

कुछ वर्षों के बाद C ++ में कोडिंग की, मुझे हाल ही में एम्बेडेड क्षेत्र में C में नौकरी कोडिंग की पेशकश की गई थी।

एम्बेडेड फ़ील्ड में C ++ को खारिज करना सही है या गलत, इस सवाल को एक तरफ रखते हुए, C ++ में कुछ विशेषताएं / मुहावरे हैं जो मुझे बहुत याद आएंगे। कुछ लोगों का नाम बताने के लिए:

  • सामान्य, प्रकार-सुरक्षित डेटा संरचनाएं (टेम्प्लेट का उपयोग करके)।
  • आरए II। विशेष रूप से कई वापसी बिंदुओं वाले कार्यों में, उदाहरण के लिए प्रत्येक रिटर्न बिंदु पर म्यूटेक्स जारी करने के लिए याद नहीं रखना।
  • सामान्य रूप से विनाशकारी। यानी आप MyClass के लिए एक बार एक D'tor लिखते हैं, तो यदि MyClass का एक उदाहरण MyOtherClass का सदस्य है, MyOtherClass को MyClass उदाहरण को स्पष्ट रूप से विचलित नहीं करना है - इसके d'tor को स्वचालित रूप से कहा जाता है।
  • नेमस्पेस।

आपके अनुभव C ++ से बढ़ रहे हैं?
आपके पसंदीदा सी ++ फीचर्स / मुहावरों के लिए आपको कौन से सी विकल्प मिले? क्या आप किसी भी सी सुविधाओं की खोज करते हैं जो आप चाहते हैं कि सी ++ था?


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

6
आपको Prog.SE में दिलचस्पी हो सकती है ।

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

4
क्या यह प्रश्न प्रोग्रामर पर अधिक अनुकूल नहीं होगा। चूंकि यह निश्चित रूप से एक "वास्तविक" प्रश्न है, मैं कहता हूं कि हम इसे फिर से खोलते हैं और इसके बजाय इसे स्थानांतरित करने के लिए मतदान करते हैं। और यह संभव नहीं है। ठीक है।
लास वी। कार्लसन

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

जवाबों:


68

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

C ++ में कोड जैसा दिखता था:

if(uart[0]->Send(pktQueue.Top(), sizeof(Packet)))
    pktQueue.Dequeue(1);

में बदल जाता है:

if(UART_uchar_SendBlock(uart[0], Queue_Packet_Top(pktQueue), sizeof(Packet)))
    Queue_Packet_Dequeue(pktQueue, 1);

जो बहुत से लोग शायद कहेंगे कि ठीक है, लेकिन हास्यास्पद हो जाता है यदि आपको एक पंक्ति में एक जोड़े "विधि" से अधिक कॉल करना पड़ता है। C ++ की दो लाइनें C के पांच में बदल जाती हैं (80-चार लाइन की लंबाई सीमा के कारण)। दोनों एक ही कोड जेनरेट करेंगे, इसलिए यह ध्यान रखने वाले लक्ष्य प्रोसेसर की तरह नहीं है!

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

मुझे देने से पहले मुझे लगभग एक महीने का समय मिला, मैंने cfront की एक प्रति पाई , और इसे मेकफ़ाइल्स में हैक कर लिया ताकि मैं अन्य ++ का उपयोग कर सकूं । Cfront ने भी टेम्पलेट्स का समर्थन नहीं किया, लेकिन C ++ कोड बहुत अधिक स्पष्ट था।

सामान्य, प्रकार-सुरक्षित डेटा संरचनाएं (टेम्प्लेट का उपयोग करके)।

C को टेम्प्लेट करने के लिए सबसे पास की चीज़ है, बहुत सी कोड वाली हेडर फ़ाइल की घोषणा करना जो दिखता है:

TYPE * Queue_##TYPE##_Top(Queue_##TYPE##* const this)
{ /* ... */ }

फिर इसे कुछ इस तरह से खींचें:

#define TYPE Packet
#include "Queue.h"
#undef TYPE

ध्यान दें कि यह यौगिक प्रकारों (जैसे कोई कतार नहीं unsigned char) के लिए काम नहीं करेगा जब तक कि आप typedefपहले न करें।

ओह, और याद रखें, यदि यह कोड वास्तव में कहीं भी उपयोग नहीं किया गया है, तो आपको यह भी नहीं पता है कि क्या यह वाक्यविन्यास रूप से सही है।

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

ऐसा करने के लिए, आपको अपनी शीर्षक फ़ाइल में "कार्यान्वयन" अनुभाग में गैर-इनलाइन किया गया सामान रखना होगा:

#ifdef implementation_##TYPE

/* Non-inlines, "static members", global definitions, etc. go here. */

#endif

और फिर, आपके सभी कोड प्रति टेम्पलेट वैरिएंट में एक स्थान पर , आपको निम्न करना होगा:

#define TYPE Packet
#define implementation_Packet
#include "Queue.h"
#undef TYPE

इसके अलावा, इस कार्यान्वयन अनुभाग को मानक / / लिटनी के बाहर होना चाहिए , क्योंकि आप किसी अन्य हेडर फ़ाइल में टेम्प्लेट हेडर फ़ाइल को शामिल कर सकते हैं, लेकिन बाद में किसी फ़ाइल में तत्काल करने की आवश्यकता है ।#ifndef#define#endif.c

हाँ, यह बदसूरत तेज़ हो जाता है। यही कारण है कि ज्यादातर सी प्रोग्रामर भी कोशिश नहीं करते हैं।

आरए II।

विशेष रूप से कई वापसी बिंदुओं वाले कार्यों में, उदाहरण के लिए प्रत्येक वापसी बिंदु पर म्यूटेक्स जारी करने के लिए याद नहीं रखना।

ठीक है, अपने सुंदर कोड को भूल जाइए और अपने सभी रिटर्न पॉइंट (फंक्शन के अंत को छोड़कर) के लिए उपयोग हो gotoजाइए:

TYPE * Queue_##TYPE##_Top(Queue_##TYPE##* const this)
{
    TYPE * result;
    Mutex_Lock(this->lock);
    if(this->head == this->tail)
    {
        result = 0;
        goto Queue_##TYPE##_Top_exit:;
    }

    /* Figure out `result` for real, then fall through to... */

Queue_##TYPE##_Top_exit:
    Mutex_Lock(this->lock);
    return result;
}

सामान्य रूप से विनाशकारी।

यानी आप MyClass के लिए एक बार एक D'tor लिखते हैं, तो यदि MyClass का एक उदाहरण MyOtherClass का सदस्य है, MyOtherClass को MyClass उदाहरण को स्पष्ट रूप से विचलित नहीं करना है - इसके d'tor को स्वचालित रूप से कहा जाता है।

ऑब्जेक्ट निर्माण को उसी तरह से स्पष्ट रूप से नियंत्रित किया जाना है।

नेमस्पेस।

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

YMMV


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

गोटो के बजाय-आरएआई तकनीक के बारे में: क्या यह रखरखाव बुरा सपना नहीं है? यानी जब भी आप एक कोड पथ जोड़ते हैं, जिसमें सफाई की आवश्यकता होती है, या यहां तक ​​कि फ़ंक्शन के अंदर चीजों के क्रम को बदलते हैं, तो आपको अंत में गोटो लेबल पर जाना होगा और उन्हें भी बदलना होगा। मैं एक ऐसी तकनीक देखना चाहता हूं जो किसी भी तरह से सफाई कोड को पंजीकृत करती है, जिसे साफ करने की आवश्यकता है।
जॉर्ज

2
@george: मैं इसे कहने से नफरत करता हूं, लेकिन मैंने देखा सबसे अधिक सी कोड सी मानकों द्वारा बहुत बुरा है। उदाहरण के लिए, मैं अभी Atmel के at91lib के साथ काम कर रहा हूं, और इसके लिए आपको एक "board.h" फ़ाइल लिखने की आवश्यकता है, जो कि अधिकांश कोड एक निर्भरता के रूप में खींचती है। (उनके डेमो बोर्ड के लिए, यह हेडर 792 लाइन लंबा है।) इसके अलावा, एक "लोवेलवेलइनिट ()" फंक्शन जिसे आपको अपने बोर्ड के लिए कस्टमाइज़ करना है, लगभग पूरी तरह से रजिस्टर एक्सेस का उपयोग करता है, जैसेAT91C_BASE_PMC->PMC_MOR = (0x37 << 16) | BOARD_OSCOUNT | AT91C_CKGR_MOSCRCEN | AT91C_CKGR_MOSCXTEN | AT91C_CKGR_MOSCSEL;
माइक डेसिमोन

1
ओह, और वहां कुछ भी नहीं बताता है कि BOARD_OSCOUNT(जो घड़ी को स्विच करने के लिए इंतजार करने का समय का मूल्य है; स्पष्ट, हुह?) वास्तव में एक #defineहै board.h। उस फ़ंक्शन में भी, बहुत सारे कॉपी-और-पेस्ट किए गए स्पिन लूप कोड हैं, जिन्हें दो-पंक्ति में बदल दिया जाना चाहिए #define(और, जब मैंने ऐसा किया था, तो इसने कोड के कुछ बाइट्स को बचाया और बनाया रजिस्टर सेट और स्पिन छोरों को अधिक विशिष्ट बनाकर अधिक पठनीय कार्य करें)। C का उपयोग करने का एक बड़ा कारण यह है कि यह आपको micromanage और सब कुछ ऑप्टिमाइज़ करने देता है, लेकिन अधिकांश कोड जो मैंने देखा है वह परेशान नहीं करता है।
माइक डेसिओन

5
@ माड्स से सहमत। उन सभी सुविधाओं से गुजरने का कोई कारण नहीं जिनकी आपको वास्तव में आवश्यकता नहीं है। मुझे लगता है कि मुझे जीटीके लाइब्रेरी के समान शैली का आनंद मिला है। अपनी "कक्षाओं" को संरचना के रूप में परिभाषित करें और फिर my_class_new () जैसे सुसंगत तरीके बनाएं और फिर इसे "विधियों" में पास करें: my_class_do_this (my_class_instance)
Max

17

मैं एक अलग कारण (कुछ प्रकार की एलर्जी प्रतिक्रिया;) के लिए सी ++ से सी में चला गया और केवल कुछ चीजें हैं जो मुझे याद आती हैं और कुछ चीजें जो मैंने प्राप्त की हैं। यदि आप C99 से चिपके रहते हैं, यदि आप कर सकते हैं, तो ऐसे निर्माण हैं जो आपको विशेष रूप से अच्छी तरह से और सुरक्षित रूप से प्रोग्राम करने देते हैं

  • नामित इनिशियलाइज़र (अंततः मैक्रोज़ के साथ संयुक्त) निर्माणकर्ताओं के रूप में सरल कक्षाओं को दर्द रहित बनाते हैं
  • अस्थायी चर के लिए यौगिक शाब्दिक
  • for-शुक्रिया चर आपको प्रारंभिक संसाधन रिटर्न के तहत विशेष रूप से unlockम्यूटेक्स या freeसरणियों को सुनिश्चित करने के लिए बाध्य बाध्य प्रबंधन प्रबंधन करने में मदद कर सकता है।
  • __VA_ARGS__ मैक्रोज़ का उपयोग फ़ंक्शंस में डिफ़ॉल्ट तर्क रखने और कोड अनरोल करने के लिए किया जा सकता है
  • inline फ़ंक्शंस और मैक्रोज़ जो ओवरलोड किए गए फ़ंक्शंस को बदलने के लिए अच्छी तरह से संयोजित होते हैं

2
@ माइक: किस भाग के लिए विशेष रूप से? यदि आप forस्कोप के लिए मेरे द्वारा दिए गए लिंक का पालन करते हैं , तो आप P99 पर उतरेंगे, जहाँ आप अन्य हिस्सों के उदाहरणों और विवरणों के लिए भी देख सकते हैं।
जेन्स गुस्तेद


@ जॉर्ज: धन्यवाद! @ जैन: अन्य चार के उदाहरण। मैं अपने सी पर पीछे गिर गया हूं; पिछले मैंने सुना है कि वे रन-आकार के स्वचालित-आबंटित (यानी स्टैक) सरणियों (जैसे void DoSomething(unsigned char* buf, size_t bufSize) { unsigned char temp[bufSize]; ... }) और फ़ील्ड नामों (जैसे struct Foo bar = { .field1 = 5, .field2 = 10 };) से संरचना आरंभीकरण जोड़ते हैं , बाद में जिसे मैं सी ++ में देखना पसंद करूंगा, विशेष रूप से गैर-पीओडी ऑब्जेक्ट्स (जैसे UART uart[2] = { UART(0x378), UART(0x278) };) के साथ ।
माइक डेसिओन

@ माइक: हाँ चर लंबाई सरणियाँ (वीएलए) हैं, लेकिन संभावित स्टैकओवरफ़्लो के कारण उनका उपयोग करना थोड़ा खतरनाक हो सकता है। दूसरा जो आप वर्णन करते हैं, वह "निर्दिष्ट निर्दिष्टकर्ता" है, इसलिए वहां आप अपने स्वयं के उदाहरण के साथ जाते हैं ;-) यदि आप "संबंधित पृष्ठ" पर क्लिक करते हैं तो दूसरों के लिए आपको P99 लिंक पर जानकारी मिल जाएगी।
जेन्स गुस्टेड

8

C. के लिए STL जैसा कुछ भी मौजूद नहीं है।
ऐसे लिबास उपलब्ध हैं जो समान कार्यक्षमता प्रदान करते हैं, लेकिन यह बिल्ट नहीं है।

सोचें कि मेरी सबसे बड़ी समस्याओं में से एक होगी ... यह जानना कि मैं किस उपकरण से समस्या का समाधान कर सकता हूं, लेकिन मेरे पास उस भाषा में उपलब्ध उपकरण नहीं हैं जिनका मुझे उपयोग करना है।


यह सच है। क्या कोई भी विस्तृत वर्णन करता है कि किस कंटेनर-श्रेणी के पुस्तकालयों को सी के लिए उपयोग करना चाहिए? या जवाब "खुद एक लिखें" है?
संदीप

@ संदीप: शुरुआत के लिए, यह उत्तर केवल कंटेनरों के बारे में ही सही है, जो मानक लिबास में नहीं हैं। एसटीएल समकक्ष (सी ++ का सबसे अच्छा हिस्सा) की कमी के अलावा, सी मानक पुस्तकालय कहीं बेहतर है। POSIX में qsort के अलावा tsearch, lsearch, hsearch और bsearch शामिल हैं जो libc में है। ग्लिब सी का निश्चित "बूस्ट" है, एक नज़र इसे अच्छाइयों (कंटेनर शामिल) के साथ पैक करें। library.gnome.org/devel/glib/stable । ग्लिब भी Gtk + के साथ एकीकृत करता है, एक संयोजन जो बूस्ट और क्यूटी से अधिक है। लिबाप्रैप भी है, जो कि तोड़फोड़ और अपाचे जैसे xplatform सामान के लिए लोकप्रिय है।
मैट जॉइनर

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

8

C और C ++ के बीच का अंतर कोड के व्यवहार की भविष्यवाणी है।

बड़ी सटीकता के साथ भविष्यवाणी करना आसान है कि आपका कोड C में क्या करेगा, C ++ में सटीक भविष्यवाणी के साथ आने के लिए थोड़ा और मुश्किल हो सकता है।

C में प्रेडिक्टिबिलिटी से आपको बेहतर नियंत्रण मिलता है कि आपका कोड क्या कर रहा है, लेकिन इसका मतलब यह भी है कि आपको अधिक सामान करना होगा।

C ++ में आप समान काम करने के लिए कम कोड लिख सकते हैं, लेकिन (मेरे लिए leas पर) मुझे कभी-कभी यह जानने में परेशानी होती है कि ऑब्जेक्ट कोड को मेमोरी में कैसे रखा जाता है और यह अपेक्षित व्यवहार है।


4
जब भी मुझे चिंता होती है कि कोड वास्तव में क्या कर रहा है, मैं विधानसभा डंप पाने के लिए -sध्वज जोड़ता हूं gcc, चिंता के कार्य की खोज करता हूं , और पढ़ना शुरू करता हूं । यह किसी भी संकलित भाषा की विचित्रता को सीखने का एक शानदार तरीका है।
माइक डेसिओन

2
यह समय की बर्बादी भी है, क्योंकि सी ++ उत्पन्न विधानसभा को देखकर पर्ल पढ़ने जैसा होगा। वैसे भी देखने के लिए ब्रावो।
मैट जॉइनर

7

मेरे काम की लाइन में - जो एम्बेडेड है, वैसे - मैं लगातार सी और सी ++ के बीच आगे और पीछे स्विच कर रहा हूं।

जब मैं C में होता हूं, तो C ++ से याद करता हूं:

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

  • बहुत शक्तिशाली मानक पुस्तकालय

  • विध्वंसक, जो निश्चित रूप से RAII को संभव बनाते हैं (म्यूटेक्स, इंटरप्ट डिसेबल, ट्रेसिंग, इत्यादि)

  • पहुंच निर्दिष्ट करता है, बेहतर लागू करने के लिए जो उपयोग कर सकते हैं (देखें नहीं) क्या

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

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

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

पसंद को देखते हुए, मैं एक परियोजना पर C ++ का उपयोग करना पसंद करूंगा, लेकिन केवल अगर टीम भाषा पर बहुत ठोस है। यह भी निश्चित रूप से यह एक 8K μC परियोजना नहीं है जहाँ मैं प्रभावी ढंग से "C" लिख रहा हूँ।


2
वह "C ++ कॉन्फिडेंस कर्व" मुझे थोड़ा परेशान करता है। जिस तरह से यह लिखा गया है, और टिप्पणियां, इसका मतलब है कि सी ++ निराशाजनक, एक खो कारण, या जो कुछ भी है। क्या मैं कुछ भूल रहा हूँ?
माइक डीमोन

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

3

टिप्पणियों के जोड़े

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

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

2

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

uint32_t 
ScoreList::FindHighScore(
  uint32_t p_PlayerId)
{
  MutexLock lock(m_Lock); 

  uint32_t highScore = 0; 
  for(int i = 0; i < m_Players.Size(); i++)
  {
    Player& player = m_Players[i]; 
    if(player.m_Score > highScore)
      highScore = player.m_Score; 
  }

  return highScore; 
}

सी में जो दिखता है:

uint32_t 
ScoreList_getHighScore(
  ScoreList* p_ScoreList)
{
  uint32_t highScore = 0; 

  Mutex_Lock(p_ScoreList->m_Lock); 

  for(int i = 0; i < Array_GetSize(p_ScoreList->m_Players); i++)
  {
    Player* player = p_ScoreList->m_Players[i]; 
    if(player->m_Score > highScore)
      highScore = player->m_Score; 
  }

  Mutex_UnLock(p_ScoreList->m_Lock);

  return highScore; 
}

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

वैसे भी मुझे लगता है कि सी ++ मुझे एक सुरक्षित फैशन में और अधिक जटिल चीजें करने की अनुमति देता है।


C में आप ऐसा नहीं कर सकते हैं (int i = 0 "के लिए।
विक्टर

6
विक्टर यह वैध c99 है (या कुछ टाइपिंग इश्यू के लिए c ++ कंपाइलर के साथ संकलित करने के लिए)।
रोमन ए। टेचर

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

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

0

मुझे लगता है कि मुख्य समस्या यह है कि एम्बेडेड वातावरण में c ++ को स्वीकार करना कठिन है क्योंकि इंजीनियरों की कमी के कारण यह समझ में आता है कि c ++ का सही उपयोग कैसे करें।

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

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

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


0

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


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

@exnihilo कन्वेंशन सुपरसेट यहाँ परिभाषित करने के लिए है कि C ++ अधिक सुविधाओं के साथ आता है। यह वाक्य रचना और शब्दार्थ में भी सुधार करता है और त्रुटि अवसरों को कम करता है। कुछ कोड हैं जो C ++ में संकलित नहीं हुए, लेकिन C में, जैसे const int a; यह C ++ में एक त्रुटि देगा क्योंकि यह घोषणा के समय एक निरंतर शुरू करने के लिए आवश्यक है जबकि C संकलित करेगा। इसलिए सुपरसेट गणित (A )B) की तरह कठोर और तेज़ नियम नहीं है, बल्कि यह एक अनुमान है कि C ++ ऑब्जेक्ट ओरिएंटेड अवधारणा जैसी अतिरिक्त सुविधाएँ प्रदान करता है।
कायनात लियाकत
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.