कुछ भाषा सुविधाएँ, भले ही वे परिवर्धन हैं, पूरे तरीके को बदल सकती हैं, जिस भाषा को व्यावहारिक रूप से उपयोग करने की आवश्यकता है। जैसा कि एक उदाहरण इस मामले पर विचार करता है:
lock_mutex(&mutex);
// call some functions
...
unlock_mutex(&mutex);
अगर C ++ में लागू किए गए उपरोक्त कोड में कॉलिंग फ़ंक्शन शामिल हैं, तो हम परेशानी की दुनिया के लिए हो सकते हैं, क्योंकि उन फ़ंक्शन कॉल में से कोई भी एक फेंक सकता है और हम उन असाधारण पथों में म्यूटेक्स को कभी भी अनलॉक नहीं करेंगे।
विध्वंसक अब उस सुविधा के दायरे में नहीं हैं जो प्रोग्रामर को उस बिंदु पर जारी / मुक्त संसाधनों को भूलने से बचाने में मदद करें। RAII एक व्यावहारिक आवश्यकता बन जाती है क्योंकि यह कोड की हर एक पंक्ति का अनुमान लगाने के लिए मानवीय रूप से संभव नहीं है जो गैर-तुच्छ उदाहरणों में फेंक सकती है (यह उल्लेख नहीं करने के लिए कि वे लाइनें अब नहीं फेंक सकती हैं लेकिन बाद में परिवर्तनों के साथ हो सकती हैं)। एक और उदाहरण लें:
void f(const Foo* f1)
{
Foo f2;
memcpy(&f2, f1, sizeof f2);
...
}
इस तरह के कोड, जबकि आम तौर पर सी में अहानिकर होते हैं, सी ++ में नरकंकाल के कहर की तरह है, क्योंकि memcpyइन वस्तुओं के बिट्स और बाइट्स पर बुलडोजर और कॉपी कंस्ट्रक्टर जैसी चीजों को बायपास करते हैं। इस तरह के कार्यों की तरह memset, realloc, memcpy, आदि, सी डेवलपर्स के बीच दैनिक उपकरण बिट्स की एक नहीं बल्कि सजातीय तरीके से काम को देख करने के लिए इस्तेमाल और स्मृति में बाइट्स जबकि, सी के और अधिक जटिल और अमीर प्रकार प्रणाली ++ के साथ सौहार्दपूर्ण नहीं हैं। C ++ उपयोगकर्ता-परिभाषित प्रकारों के बहुत अधिक सार दृश्य को प्रोत्साहित करता है।
इसलिए इस प्रकार की चीजें अब C ++ के लिए अनुमति नहीं देती हैं, कोई भी इसे सही ढंग से उपयोग करने के लिए, इसे सी के एक "सुपरसेट" के रूप में देखने के लिए। इन भाषाओं को बहुत प्रभावी ढंग से उपयोग करने के लिए एक बहुत अलग मानसिकता, अनुशासन और सोचने के तरीके की आवश्यकता होती है ।
मैं उस शिविर में नहीं हूं जो सी ++ को हर तरह से बेहतर रूप में देखता है, और वास्तव में मेरे पसंदीदा तीसरे पक्ष के अधिकांश लोग किसी कारण से सी लाइब्रेरी हैं। मैं नहीं जानता कि वास्तव में क्यों लेकिन सी लिबास प्रकृति में अधिक न्यूनतम होते हैं (शायद इसलिए कि इस तरह की समृद्ध प्रकार की व्यवस्था डेवलपर्स को कुछ बड़े और स्तरित सेट के निर्माण के बिना आवश्यक न्यूनतम कार्यक्षमता प्रदान करने पर अधिक ध्यान केंद्रित करती है), हालांकि मैं अक्सर अपने उद्देश्यों के लिए उनके उपयोग को सरल और दर्जी करने के लिए उनके चारों ओर सी ++ रैपर लगाता हूं, लेकिन न्यूनतम प्रकृति भी मेरे लिए बेहतर होती है। मैं वास्तव में अतिसूक्ष्मवाद को एक पुस्तकालय की एक आकर्षक विशेषता के रूप में पसंद करता हूं, जो ऐसे गुणों की तलाश करने के लिए अतिरिक्त समय लेते हैं, और शायद सी को प्रोत्साहित करने के लिए जाता है,
मैं C ++ का अधिक से अधिक बार एहसान करता हूं, लेकिन मुझे वास्तव में व्यापक रूप से द्विआधारी संगतता (और FFIs) के लिए C API का उपयोग करने की आवश्यकता है, हालांकि मैं अक्सर हेडर के लिए C का उपयोग करने के बावजूद उन्हें C ++ में कार्यान्वित करता हूं। लेकिन कभी-कभी जब आप वास्तव में निम्न-स्तर पर जाते हैं, जैसे मेमोरी एलोकेटर के स्तर या बहुत कम-स्तरीय डेटा संरचना (और मुझे यकीन है कि एम्बेडेड प्रोग्रामिंग करने वालों के बीच और उदाहरण हैं), तो यह कभी-कभी मददगार हो सकता है यह मानने में सक्षम है कि आप जिस प्रकार और डेटा के साथ काम कर रहे हैं वे vtables, costructors, और destructors जैसी कुछ विशेषताओं से अनुपस्थित हैं, ताकि हम उन्हें बिट्स और बाइट्स के रूप में चारों ओर फेरबदल करने, कॉपी करने, मुक्त करने, वास्तविक बनाने के लिए व्यवहार कर सकें। विशेष रूप से निम्न-स्तरीय समस्याओं के लिए, यह कभी-कभी बहुत सरल प्रकार की प्रणाली के साथ काम करने में सहायक हो सकता है जो C प्रदान करता है,
एक स्पष्टता
यहाँ एक दिलचस्प टिप्पणी मैं गहराई से थोड़ा और जवाब देना चाहता था (मुझे लगता है कि यहाँ टिप्पणियाँ वर्ण सीमा पर इतनी सख्त हैं):
memcpy(&f2, f1, sizeof f2); अगर सी में फू का अपना कोई संकेत है, या उससे भी बदतर है, तो सी में "नरकंकाल शासनकाल" भी है, क्योंकि आपके पास इससे निपटने के लिए उपकरणों की भी कमी है।
यह एक उचित बिंदु है लेकिन मैं जिस चीज पर ध्यान केंद्रित कर रहा हूं वह मुख्य रूप से C ++ की टाइप प्रणाली पर ध्यान केंद्रित करने के साथ-साथ RAII के संबंध में है। कारणों में से एक ऐसे एक्स-रेईश बाइट-कॉपीिंग memcpyया qsortफ़ंक्शन के प्रकार सी में व्यावहारिक खतरे को कम करते हैं, यह है कि ऊपर f1और f2ऊपर का विनाश स्पष्ट है (यदि उन्हें गैर-तुच्छ विनाश की आवश्यकता है), जबकि जब विनाशकारी तस्वीर में चले जाते हैं , वे अंतर्निहित और स्वचालित हो जाते हैं (अक्सर डेवलपर्स के लिए महान मूल्य के साथ)। यह भी vptrs की तरह छिपे हुए राज्य का उल्लेख नहीं है और आगे जो इस तरह के कार्यों सही पर बुलडोज़र होगा। यदि f1सूचक औरf2उथले उन्हें कुछ अस्थायी संदर्भ में कॉपी करते हैं, तो यह कोई समस्या नहीं है अगर हम दूसरी बार उन मालिक बिंदुओं को स्पष्ट रूप से मुक्त करने की कोशिश नहीं करते हैं। C ++ के साथ यह कुछ ऐसा है जो कंपाइलर स्वचालित रूप से करना चाहेगा।
और अगर सी में "आम तौर पर" अगर फू के पास पॉइंटर्स होते हैं , तो यह अधिक बड़ा हो जाता है , क्योंकि संसाधन प्रबंधन के साथ जरूरी गवाह अक्सर ऐसा बनाते हैं कि आमतौर पर अनदेखी करने के लिए कुछ और अधिक कठिन होता है जबकि सी ++ में, हम एक यूडीटी को लंबे समय तक बना सकते हैं। constructible / ध्वंसशील केवल यह किसी भी सदस्य चर जो trivially constructible / ध्वंसशील नहीं है की दुकान बनाने (एक तरह से आम तौर पर बहुत उपयोगी है कि, फिर से, लेकिन नहीं हम की तरह उपयोग कार्यों के लिए परीक्षा रहे हैं द्वारा memcpyया realloc)।
मेरा मुख्य बिंदु इस खोजकर्ता के किसी भी लाभ पर बहस करने की कोशिश नहीं करना है (मैं कहूंगा कि यदि कोई हो, तो वे लगभग हमेशा मानव त्रुटि की बढ़ती संभावना के विपक्ष द्वारा तौला जाता है जो इसके साथ आता है), लेकिन केवल यह कहने के लिए कि कार्यों की तरह memcpyऔर memmoveऔर qsortऔर memsetऔरreallocऔर इसके बाद UDTs के साथ एक भाषा में कोई जगह नहीं है जो C ++ जैसी सुविधाओं और क्षमताओं में समृद्ध है। हालांकि वे परवाह किए बिना मौजूद हैं, मुझे लगता है कि यह कहना भी बहुत मुश्किल नहीं होगा कि सी ++ डेवलपर्स के विशाल, विशाल बहुमत प्लेग जैसे कार्यों से बचने के लिए बुद्धिमान होंगे, जबकि ये सी में बहुत दैनिक प्रकार के कार्य हैं, और मैं ' डी का तर्क है कि वे सी में कम समस्याओं को सरल कारण से बताते हैं कि इसकी प्रकार प्रणाली बहुत अधिक बुनियादी है और, शायद "डम्बर"। एक्स-रे सी प्रकार और उन्हें बिट्स और बाइट्स के रूप में व्यवहार करना त्रुटि-प्रवण है। C ++ में ऐसा करना यकीनन सिर्फ एक दम गलत है क्योंकि इस तरह के कार्य भाषा की बहुत बुनियादी विशेषताओं के खिलाफ लड़ रहे हैं और यह किस प्रकार की प्रणाली को प्रोत्साहित करता है।
यह वास्तव में सी की मेरे लिए सबसे बड़ी अपील है, हालांकि, विशेष रूप से यह भाषा अंतर के साथ कैसे संबंधित है। यह बहुत ज्यादा मुश्किल होगा, सी # एफएफआई की तरह कुछ और बनाना मुश्किल है। फुल-ब्लो टाइप टाइप सिस्टम और लैंग्वेज फीचर्स ऑफ सी ++ डाउन टू कंस्ट्रक्टर्स, डिस्ट्रक्टर्स, अपवाद, वर्चुअल फंक्शन, फंक्शन / मेथड ओवरलोडिंग, ऑपरेटर ओवरलोडिंग, सभी विभिन्न प्रकार के उत्तराधिकार, आदि सी के साथ यह एक अपेक्षाकृत कमज़ोर भाषा है जो एपीआई के रूप में मानक के रूप में दूर हो गई है क्योंकि कई अलग-अलग भाषाएं एफएफआई के माध्यम से सीधे आयात कर सकती हैं, या अप्रत्यक्ष रूप से कुछ सी एपीआई निर्यात कार्यों के माध्यम से वांछित रूप में कर सकते हैं (उदाहरण: जावा एनएआरआई इंटरफ़ेस) )। और यही वह जगह है जहां मैं ज्यादातर कोई विकल्प नहीं छोड़ता हूं लेकिन सी का उपयोग करता हूं, क्योंकि हमारे मामले में भाषा की व्यावहारिकता एक व्यावहारिक आवश्यकता है (हालांकि अक्सर मैं)
लेकिन आप जानते हैं, मैं एक व्यावहारिक (या कम से कम मैं प्रयास करता हूं)। यदि C यह सबसे बेईमानी और ईश्वरीय, त्रुटि-प्रवण, गंदी भाषा थी, तो मेरे C ++ उत्साही साथियों में से कुछ ने इसका दावा किया (और मैं अपने आप को C ++ उत्साही मानूंगा, सिवाय इसके कि किसी भी तरह इस हिस्से पर C की घृणा न हो। ; इसके विपरीत इसका मुझ पर विपरीत प्रभाव पड़ा, जिससे मुझे दोनों भाषाओं को अपने-अपने मामलों में और मतभेदों से बेहतर तरीके से सराहना मिली), तो मैं उम्मीद करूंगा कि वास्तविक दुनिया में कुछ बुग्गीस्ट और लीकस्टी के रूप में दिखाने के लिए और अविश्वसनीय उत्पाद और पुस्तकालय सी में लिखे जा रहे हैं और मुझे वह नहीं मिलता है। मुझे लिनक्स पसंद है, मुझे Apache, Lua, zlib पसंद है, मैं इस तरह की शिफ्टिंग हार्डवेयर आवश्यकताओं, Gimp, libpng, Cairo, इत्यादि के खिलाफ अपनी लंबी विरासत के लिए OpenGL सहनीय पाता हूं। कम से कम जो कुछ भी भाषा की बाधा बनती है, वह यह प्रतीत नहीं होती है कि जहां तक सक्षम हाथों में कुछ शांत पुस्तकालयों और उत्पादों को लिखने की बात है, और यही वास्तव में मेरी दिलचस्पी है। इसलिए मैं कभी भी इस प्रकार नहीं हूं जो सबसे अधिक भावुक है। भाषा की लड़ाई, एक व्यावहारिक अपील करने के अलावा और कहते हैं, "अरे, वहाँ शांत सामान है! आइए जानें कि उन्होंने इसे कैसे बनाया और शायद शांत पाठ हैं, भाषा के मुहावरे की प्रकृति के लिए इतना विशिष्ट नहीं है कि हम वापस ला सकें। हम जिस भी भाषा (भाषाओं) का उपयोग कर रहे हैं। " :-D