ओओपी भाषा के साथ पक्षपात के बाद एक सी प्रोग्रामर के रूप में कैसे सोचा जाए? [बन्द है]

Question

पहले, मैंने केवल ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग लैंग्वेज (C ++, Ruby, Python, PHP) का उपयोग किया है, और अब C सीख रहा हूं। मुझे भाषा में चीजों को करने का उचित तरीका पता लगाना मुश्किल हो रहा है, जिसमें कोई कॉन्सेप्ट नहीं है। 'वस्तु'। मुझे लगता है कि C में OOP प्रतिमानों का उपयोग करना संभव है, लेकिन मैं C-idiomatic तरीका सीखना चाहूंगा।

एक प्रोग्रामिंग समस्या को हल करते समय, पहली चीज जो मैं करता हूं वह एक ऐसी वस्तु की कल्पना करना है जो समस्या को हल करेगी। एक गैर-ओओपी इंपीरियल प्रोग्रामिंग प्रतिमान का उपयोग करते समय मैं इसके साथ क्या कदम उठाता हूं?

Comments

मुझे अभी तक एक ऐसी भाषा मिल गई है जो मेरे सोचने के तरीके से मेल खाती है, इसलिए मुझे किसी भी भाषा के लिए अपने विचारों को "संकलित" करना होगा जो मैं उपयोग कर रहा हूं। एक अवधारणा जो मुझे उपयोगी लगी है वह एक "कोड यूनिट" की है, चाहे वह एक लेबल, सबरूटीन, फंक्शन, ऑब्जेक्ट, मॉड्यूल या फ्रेमवर्क हो: उनमें से हर एक को संक्षिप्त किया जाना चाहिए और एक अच्छी तरह से परिभाषित इंटरफ़ेस को उजागर करना चाहिए। यदि आप सी-डाउन ऑब्जेक्ट-लेवल अप्रोच का उपयोग करते हैं, तो C में आप उन फ़ंक्शन का एक सेट बनाकर शुरू कर सकते हैं जो व्यवहार करते हैं जैसे कि समस्या हल हो गई थी। अक्सर, अच्छी तरह से डिज़ाइन किए गए सी एपीआई ओओपी की तरह दिखते हैं, लेकिन qux = foo.bar(baz)बन जाते हैं qux = Foo_bar(foo, baz)।

— आमोन

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

— rwong

LibTiff (github पर स्रोत कोड) बड़े C कार्यक्रमों को व्यवस्थित करने के तरीके का एक उदाहरण है।

— rwong

एक C # प्रोग्रामर के रूप में मैं डेलिगेट (एक बाउंड पैरामीटर के साथ फंक्शन पॉइंटर्स) को याद करूँगा, जितना मैं ऑब्जेक्ट्स को मिस करूँगा।

— कोडइन्चोस

मैंने व्यक्तिगत रूप से पूर्व प्रोसेसर के उल्लेखनीय अपवाद के साथ, सी के अधिकांश को आसान और सीधा पाया। अगर मुझे C को फिर से सीखना है, तो वह एक ऐसा क्षेत्र होगा जिस पर मैं अपने प्रयास को केंद्रित करूंगा।

— बिजिकलोप

Answer 1

• एसी प्रोग्राम फ़ंक्शंस का एक संग्रह है।
• एक फ़ंक्शन स्टेटमेंट का एक संग्रह है।
• आप एक के साथ डेटा encapsulate कर सकते हैं struct।

बस।

आपने कक्षा कैसे लिखी? यह बहुत ज्यादा है कि आप एक .C फ़ाइल कैसे लिखते हैं। दी, आपको विधि बहुरूपता और वंशानुक्रम जैसी चीजें नहीं मिलती हैं, लेकिन आप विभिन्न फ़ंक्शन नामों और रचनाओं के साथ वैसे भी अनुकरण कर सकते हैं ।

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

एएनएसआई सी में आगे पढ़ना
ऑब्जेक्ट-ओरिएंटेशन

Comments

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

— रॉबर्ट ब्रिस्टो-जॉनसन

जैसा कि किसी की पहली भाषा सी थी / है, मैं यह कहने के लिए उद्यम करूंगा । a lot of things actually work better without the overhead of classes

— हनीफमुबारक

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

— edmz

मुकाबला: a lot of things actually work better with addition of class-based OOP। स्रोत: टाइपस्क्रिप्ट, डार्ट, कॉफीस्क्रिप्ट और अन्य सभी तरीके उद्योग एक कार्यात्मक / प्रोटोटाइप ओओपी भाषा से दूर होने की कोशिश कर रहे हैं।

— डेन

विस्तार करने के लिए, बहुत सी चीजों को ओओपी के साथ विकसित किया गया है : बाकी सब कुछ। मनुष्य स्वाभाविक रूप से वस्तुओं के संदर्भ में सोचते हैं और अन्य मनुष्यों को पढ़ने और समझने के लिए कार्यक्रम लिखे जाते हैं।

— डेन

Answer 2

SICP पढ़ें और स्कीम जानें, और अमूर्त डेटा प्रकारों का व्यावहारिक विचार । तब C में कोडिंग आसान है (चूंकि SICP, C का थोड़ा सा हिस्सा, और PHP, Ruby, आदि का एक सा ... आपकी सोच काफी चौड़ी हो जाएगी, और आप समझ जाएंगे कि ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग सबसे अच्छी शैली नहीं हो सकती है सभी मामले, लेकिन केवल कुछ प्रकार के कार्यक्रमों के लिए)। सी गतिशील मेमोरी आवंटन के बारे में सावधान रहें , जो शायद सबसे कठिन हिस्सा है। C99 या C11 प्रोग्रामिंग भाषा मानक और उसके सी मानक पुस्तकालय वास्तव में काफी गरीब है (यह टीसीपी या निर्देशिका के बारे में पता नहीं है!), और आप अक्सर कुछ बाहरी पुस्तकालयों की आवश्यकता होगी या इंटरफेस (जैसेPOSIX , libcurl HTTP क्लाइंट लाइब्रेरी के लिए, libonion HTTP सर्वर पुस्तकालय के लिए, GMPlib bignums के लिए, जैसे कुछ पुस्तकालय libunistring , आदि UTF-8 के लिए ...)।

आपकी "वस्तुएं" अक्सर सी से संबंधित कुछ में होती हैं struct, और आप उन पर काम करने वाले कार्यों के सेट को परिभाषित करते हैं। छोटे या बहुत ही सरल कार्यों के लिए, उन्हें प्रासंगिक के साथ परिभाषित करने पर विचार करें struct, जैसा static inlineकि कुछ हेडर फ़ाइल में कहीं और foo.hहोना चाहिए #include।

ध्यान दें कि ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग केवल प्रोग्रामिंग प्रतिमान नहीं है । कुछ अवसरों में, अन्य प्रतिमान सार्थक होते हैं ( कार्यात्मक प्रोग्रामिंग आ ला ओकेमेल या हास्केल या यहां तक ​​कि योजना या कॉमोन लिस्प, तर्क प्रोग्रामिंग आ ला प्रोलॉग , आदि ... आदि भी पढ़ें । घोषणा पत्र कृत्रिम बुद्धिमत्ता के बारे में जे.पत्रा का ब्लॉग )। स्कॉट की पुस्तक देखें: प्रोग्रामिंग भाषा व्यावहारिक

^{दरअसल, सी में एक प्रोग्रामर, या ओकेमेल में, आमतौर पर ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग स्टाइल में कोड नहीं करना चाहता है। अपने आप को वस्तुओं के बारे में सोचने के लिए मजबूर करने का कोई कारण नहीं है जब यह उपयोगी नहीं है।}

आप कुछ structऔर उन पर काम करने वाले कार्यों को परिभाषित करेंगे (अक्सर संकेत के माध्यम से)। आपको कुछ टैग किए गए यूनियनों की आवश्यकता हो सकती है (अक्सर, structटैग सदस्य के साथ, अक्सर कुछ enum, और कुछ unionअंदर), और आपको अपने कुछ के अंत में एक लचीली सरणी सदस्य रखने के लिए उपयोगी हो सकता है struct।

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

मत भूलना सभी चेतावनियों और डिबग जानकारी, जैसे के साथ संकलित करने के लिए gcc -Wall -Wextra -g-notably विकास और डिबगिंग phases- दौरान और कुछ उपकरण, जैसे उपयोग करना सीखना valgrind शिकार करने के लिए मेमोरी लीक , gdbडिबगर, आदि के लिए ध्यान रखना समझ में अच्छी तरह से क्या है अपरिभाषित व्यवहार और दृढ़ता से इसे से बचें (याद रखें कि एक कार्यक्रम कुछ यूबी हो सकता है और कभी-कभी "काम" लगता है)।

जब आपको वास्तव में ऑब्जेक्ट ओरिएंटेड कंस्ट्रक्शन (विशेष रूप से विरासत में ) की आवश्यकता होती है, तो आप संबंधित संरचनाओं और कार्यों के लिए पॉइंटर्स का उपयोग कर सकते हैं। आपके पास अपनी स्वयं की व्यवहार्य मशीनरी हो सकती है , प्रत्येक "ऑब्जेक्ट" में एक पॉइंटर के साथ एक structफ़ंक्शन फ़ंक्शन के साथ शुरू हो सकता है । आप एक पॉइंटर प्रकार को दूसरे पॉइंटर प्रकार (और इस तथ्य के साथ कि आप एक struct super_stही फ़ील्ड प्रकारों से शामिल कर सकते हैं, जैसे कि struct sub_stविरासत का अनुकरण शुरू कर सकते हैं) की क्षमता का लाभ उठाते हैं । ध्यान दें कि सी काफी परिष्कृत वस्तु प्रणालियों को लागू करने के लिए पर्याप्त है-विशेष रूप से कुछ सम्मेलनों का पालन ​​करके - जैसे कि GObject (GTK / Gnome से) प्रदर्शित करता है।

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

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

मत भूलो कि कभी-कभी मेटाप्रोग्रामिंग उपयोगी है । काफी बार, C में लिखे गए बड़े सॉफ़्टवेयर में कुछ C कोड उत्पन्न करने के लिए कुछ स्क्रिप्ट या तदर्थ कार्यक्रम होते हैं (और आप कुछ गंदे C प्रीप्रोसेसर चालें भी खेल सकते हैं , जैसे X-macros )। कुछ उपयोगी C प्रोग्राम जनरेटर (जैसे yacc या gnu bison मौजूद है, जो parsers, gperf को सही हैश फंक्शन उत्पन्न करने के लिए उत्पन्न करता है ...)। कुछ सिस्टम (विशेष रूप से लिनक्स और पॉसिक्स) पर, आप generated-001.cफ़ाइल में रनटाइम पर कुछ सी कोड भी उत्पन्न कर सकते हैं , इसे gcc -O -Wall -shared -fPIC generated-001.c -o generated-001.soरनटाइम पर कुछ कमांड (जैसे ) चलाकर एक साझा ऑब्जेक्ट पर संकलित करें , गतिशील रूप से लोड करें जो dlopen का उपयोग करके साझा ऑब्जेक्ट को लोड करता है& dlsym का उपयोग करके नाम से फ़ंक्शन पॉइंटर प्राप्त करें । मैं MELT (एक लिस्प-जैसे डोमेन विशिष्ट भाषा में आपके लिए उपयोगी हो सकता हूं, क्योंकि यह GCC कंपाइलर के अनुकूलन को सक्षम करता है) में ऐसे ट्रिक्स कर रहा हूं ।

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

Comments

ईमानदारी से, इस सवाल से, SICP को पढ़ना निस्संदेह एक अच्छी सलाह है, लेकिन ओपी के लिए यह संभवत: अगला सवाल होगा "SICP के साथ पक्षपात के बाद C प्रोग्रामर के रूप में कैसे सोचें"।

— डॉक ब्राउन

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

— बेसिल स्टायरनेविच 11

SICP एक अजीब सुझाव है। योजना सी। से बहुत अलग है

— ब्रायन गॉर्डन

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

— बेसिल स्टैरनेविच 11

Answer 3

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

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

तो संक्षेप में आप पहले प्रक्रियाओं (कार्यों) के बारे में सोचते हैं फिर आप यह सुनिश्चित करते हैं कि सभी फ़ंक्शन को उन सूचनाओं तक पहुंच है जिनकी उन्हें आवश्यकता है।

Answer 4

सी एपीआई अक्सर - शायद यहां तक ​​कि, आमतौर पर - एक अनिवार्य रूप से ऑब्जेक्ट ओरिएंटेड इंटरफ़ेस होता है यदि आप उन्हें सही तरीके से देखते हैं।

C ++ में:

class foo {
    public:
        foo (int x);
        void bar (int param);
    private:
        int x;
};

// Example use:
foo f(42);
f.bar(23);

सी में:

typedef struct {
    int x;
} foo;

void bar (foo*, int param);

// Example use:
foo f = { .x = 42 };
bar(&f, 23);

जैसा कि आप जानते हैं, सी ++ और विभिन्न अन्य औपचारिक ओओ भाषाओं में, हुड के तहत एक ऑब्जेक्ट विधि एक पहला तर्क लेती है जो ऑब्जेक्ट के लिए एक संकेतक है, bar()ऊपर के सी संस्करण की तरह । उदाहरण के लिए, यह C ++ में सतह पर कहां आता है, इस पर विचार करें कि std::bindहस्ताक्षर करने के लिए ऑब्जेक्ट विधियों को फिट करने के लिए कैसे उपयोग किया जा सकता है:

new function<void(int)> (
    bind(&foo::bar, this, placeholders::_1)
//                  ^^^^ object pointer as first arg
);

जैसा कि अन्य लोगों ने बताया है, वास्तविक अंतर यह है कि औपचारिक OO भाषाएं बहुरूपता, अभिगम नियंत्रण और अन्य निफ्टी सुविधाओं को लागू कर सकती हैं। लेकिन वस्तु उन्मुख प्रोग्रामिंग का सार, असतत, जटिल डेटा संरचनाओं का निर्माण और हेरफेर, सी में पहले से ही एक मौलिक अभ्यास है।

Answer 5

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

Comments

IMHO C एक निम्न स्तर की भाषा है, लेकिन कोडांतरक या मशीन कोड की तुलना में बहुत अधिक है, क्योंकि C कंपाइलर निम्न-स्तरीय अनुकूलन कर सकता है।

— बेसिल स्टारीनेविच 11

सी कंपाइलर भी हैं, "ऑप्टिमाइज़ेशन" के नाम पर, एक अमूर्त मशीन मॉडल की ओर बढ़ रहे हैं, जो इनपुट दिए जाने पर समय और कार्य-कारण के नियमों की अवहेलना कर सकता है जो कि अनिर्धारित व्यवहार का कारण होगा, भले ही मशीन पर कोड का प्राकृतिक व्यवहार जहां यह हो चलाया जाता है अन्यथा आवश्यकताओं को पूरा करेगा। उदाहरण के लिए, फ़ंक्शन uint16_t blah(uint16_t x) {return x*x;}उन मशीनों पर अनौपचारिक रूप से काम करेगा जहां unsigned int16 बिट्स हैं, या जहां यह 33 बिट्स या बड़ा है। मशीनों के लिए कुछ संकलक जहां unsigned int17 से 32 बिट्स हैं, हालांकि, उस विधि के लिए एक कॉल का संबंध हो सकता है ...

— सुपर

... कंपाइलर को अनुमान लगाने की अनुमति देने के रूप में कि घटनाओं की कोई श्रृंखला जिससे 46340 से अधिक मूल्य का तरीका दिया जा सके, संभवतः हो सकता है। हालाँकि, किसी भी प्लेटफ़ॉर्म पर 65533u * 65533u को गुणा करने पर एक वैल्यू निकलेगी, जिसे जब कास्ट किया uint16_tजाएगा, तो 9 की पैदावार होगी, uint16_t17 से 32-बिट प्लेटफ़ॉर्म पर टाइप का मान बढ़ाते समय स्टैंडर्ड ऐसे व्यवहार को अनिवार्य नहीं करता है।

— सुपरकैट

Answer 6

मैं भी OO मूलनिवासी हूं (C ++ आमतौर पर) जिन्हें कभी-कभी C. की दुनिया में जीवित रहना पड़ता है। मेरे लिए मूल रूप से सबसे बड़ी बाधा त्रुटि से निपटने और संसाधन प्रबंधन है।

C ++ में हमने एक एरर पास करने के लिए फेंक दिया है जहाँ से यह शीर्ष स्तर पर वापस होता है जहाँ हम इससे निपट सकते हैं और हमारी मेमोरी और अन्य संसाधनों को स्वचालित रूप से मुक्त करने के लिए हमारे पास विध्वंसक होते हैं।

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

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

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