OOP की आयु में C इतना लोकप्रिय क्या है? [बन्द है]


91

मैं C और C ++ दोनों में बहुत कुछ कोड करता हूं, लेकिन उम्मीद नहीं की थी कि C दूसरी सबसे लोकप्रिय भाषा होगी, जावा से थोड़ा पीछे।

TIOBE प्रोग्रामिंग सामुदायिक सूचकांक

मैं इस बात से उत्सुक हूं कि OOP के इस युग में, C अभी भी इतना लोकप्रिय है? ध्यान दें कि शीर्ष 5 लोकप्रिय प्रोग्रामिंग भाषाओं में से 4 "आधुनिक", ऑब्जेक्ट-ओरिएंटेड सक्षम भाषाएं हैं।

अब, मैं इस बात से सहमत हूं कि आप कुछ हद तक C में OOP का उपयोग कर सकते हैं, लेकिन यह दर्दनाक और अशुभ (कम से कम C ++ की तुलना में अच्छी तरह से लगता है)। तो, क्या C इतना लोकप्रिय बनाता है? क्या यह दक्षता है; निम्न स्तर का; पुस्तकालयों का विशाल बहुमत जो पहले से मौजूद है या कुछ और है?


18
वीडियोगेम, एम्बेडेड सिस्टम, हार्डवेयर प्रोग्रामिंग (फर्मवेयर), ऑपरेटिंग सिस्टम, आदि

25
ध्यान दें कि आपको केवल वही मिलता है जो आप मापते हैं - TIOBE के मामले में, +"<language> programming"लोकप्रिय खोज इंजन पर हिट की संख्या । एक ब्लॉग पोस्ट "क्यों कोई भी सी प्रोग्रामिंग नहीं करता है" इस सूचकांक में सी के लिए गिना जाता है। बिल्ली, यहां तक ​​कि यह सवाल भी हो सकता है जैसे ही Google इसे उठाता है।

40
OOP की उम्र? यह एक बहुत ही साहसिक कथन है।
महमूद होसाम

57
आपको भ्रम है कि ओओपी एक चांदी की गोली है, आपको जल्दी से हारना चाहिए, ओओपी के बारे में कुछ विशेष या "अच्छा" नहीं है, यह कई कोड संगठन रणनीतियों में से एक है।
रेयानोस

23
@ डेडएमजी: पॉट, केतली से मिलते हैं। TIOBE का डेटा विश्वसनीय नहीं हो सकता है, लेकिन आपके गंजेपन का दावा है कि "यह लोकप्रिय नहीं है" जिसका कोई स्रोत या उद्धरण नहीं है। यदि आप प्रश्न के पीछे की धारणा को चुनौती देने जा रहे हैं, तो कम से कम इसे वापस लेने के लिए कुछ सबूत प्रदान करें।
डैनियल प्रेडेन

जवाबों:


143

योगदान करने वाले कुछ कारक:

  • C सर्वव्यापी है। प्लेटफ़ॉर्म जो भी हो, सी शायद उपलब्ध है।
  • C पोर्टेबल है। स्वच्छ सी का एक टुकड़ा लिखें, और यह अन्य प्लेटफार्मों पर न्यूनतम संशोधनों के साथ संकलित करता है - कभी-कभी यह बॉक्स से बाहर भी काम करता है।
  • C थोड़ी देर के लिए आसपास रहा है। उन दिनों में जब UNIX ने दुनिया पर विजय प्राप्त की, C (पसंद की UNIX प्रोग्रामिंग भाषा) ने अपने विश्व प्रभुत्व में साझा किया, और प्रोग्रामिंग दुनिया का लिंगुआ फ्रेंका बन गया । किसी भी गंभीर प्रोग्रामर से उम्मीद की जा सकती है कि वह कम से कम सी के कुछ समझ में न आए; अधिकांश अन्य भाषाओं के बारे में नहीं कहा जा सकता है।
  • C अभी भी UNIX और UNIX- फ्लेवर्ड सिस्टम के लिए डिफ़ॉल्ट भाषा है। यदि आप चाहते हैं कि एक पुस्तकालय ओपन-सोर्स भूमि में सफल हो, तो आपको सी का उपयोग नहीं करने के लिए काफी अच्छे कारणों की आवश्यकता है । यह आंशिक रूप से परंपरा के कारण है, लेकिन अधिक इसलिए कि सी एकमात्र ऐसी भाषा है जिसे आप सुरक्षित रूप से किसी भी यूनिक्स जैसे समर्थन पर मान सकते हैं। प्रणाली। C में अपनी लाइब्रेरी लिखने का मतलब है कि आप निर्भरता कम कर सकते हैं।
  • सी सरल है। इसमें परिष्कृत ओओपी या कार्यात्मक भाषाओं की अभिव्यक्ति की कमी है, लेकिन इसकी सरलता का मतलब है कि इसे जल्दी से उठाया जा सकता है।
  • C बहुमुखी है। यह एम्बेडेड सिस्टम, डिवाइस ड्राइवर, ओएस कर्नेल, छोटी कमांड-लाइन उपयोगिताओं, बड़े डेस्कटॉप एप्लिकेशन, DBMS's, अन्य प्रोग्रामिंग भाषाओं को लागू करने के लिए उपयुक्त है, और बहुत कुछ और जो आप सोच सकते हैं।
  • C तेज है। अधिकांश सी कार्यान्वयन मशीन कोड के लिए सीधे संकलित करते हैं, और मशीन स्तर पर क्या होता है, इस पर प्रोग्रामर को पूरी शक्ति है। कोई दुभाषिया नहीं है, कोई जेआईटी कंपाइलर, कोई वीएम या रनटाइम नहीं है - बस कोड, एक कंपाइलर, एक लिंकर और नंगे धातु।
  • C 'मुक्त' है (बीयर और भाषण दोनों अर्थों में)। मानक का मालिक और नियंत्रण करने वाली कोई एकल कंपनी नहीं है, चुनने के लिए कई कार्यान्वयन हैं, सी का उपयोग करने के लिए कोई कॉपीराइट, पेटेंट या ट्रेडमार्क मुद्दे नहीं हैं और कुछ सर्वोत्तम कार्यान्वयन खुले-स्रोत हैं।
  • C की बहुत गति है। भाषा दशकों से लोकप्रिय रही है, इसलिए भाषा का समर्थन करने के लिए अनुप्रयोगों, पुस्तकालयों, औजारों और अधिकांश सभी समुदायों की एक बड़ी मात्रा है।
  • C परिपक्व है। अंतिम मानक जिसने बड़े बदलाव पेश किए, वह है C99, और यह पिछले मानकों के साथ ज्यादातर पीछे की ओर संगत है। नई भाषाओं (कहें, पायथन) के विपरीत, आपको जल्द ही कभी भी परिवर्तनों को तोड़ने के बारे में चिंता करने की आवश्यकता नहीं है।
  • सी संगत है। अधिकांश भाषाओं में सी। से बात करने के लिए बाइंडिंग है। इसका मतलब है कि कोई मानक कॉलिंग सम्मेलनों का उपयोग करके सी में एक पुस्तकालय विकसित कर सकता है, और आश्वस्त महसूस करता है कि लगभग कोई अन्य भाषा उस लाइब्रेरी के खिलाफ लिंक कर सकती है। व्यापक उपयोग में कुछ लोकप्रिय भाषाओं के नाम के लिए: C #, जावा, पर्ल, पायथन, PHP सभी पुस्तकालयों के खिलाफ बिना किसी परेशानी के लिंक कर सकते हैं।
  • सी शक्तिशाली है: यदि भाषा कुछ नहीं कर सकती है, तो सभी लोकप्रिय कंपाइलर कोडांतरक कोड को एम्बेड करने की अनुमति देते हैं जो हार्डवेयर कुछ भी कर सकता है। अनुकूलता के बारे में उपरोक्त बिंदु के साथ संचरित, इसका मतलब है कि सी उच्च स्तर की भाषाओं और असेंबली के "नंगे धातु" के बीच संपर्क के रूप में कार्य कर सकता है।

9
मुझे लगता है कि आपके सभी तर्क सही नहीं हैं। 1) C सर्वव्यापी है। C ++ उबिकिटोस C के समान है, क्योंकि C ++ से C कंपाइलर हैं। 2) C पोर्टेबल है। C ++ के साथ भी ऐसा ही है। 3)। C थोड़ी देर के लिए आसपास रहा है। C ++ के साथ भी ऐसा ही है। 4)। C बहुमुखी है। C ++ के साथ भी ऐसा ही है। 5) C तेज है। C ++ के साथ भी ऐसा ही है। 6)। सी 'फ्री' है। C ++ के साथ भी ऐसा ही है। 7)। C की बहुत गति है। C ++ के साथ फिर से वही। 8) C परिपक्व है। C ++ के साथ भी ऐसा ही है। तो आप वास्तव में इस सवाल का जवाब नहीं देते।
कोन्स्टेंटिन सोलोमेटोव

19
C11 नवीनतम मानक है, C99 नहीं। ऐसा नहीं है कि यह वास्तव में मायने रखता है क्योंकि सभी लोग '89 का उपयोग करते हैं।
पबबी

53
@KonstantinSolomatov: यदि आप एक पुस्तकालय लिख रहे हैं जिसका उपभोग अन्य लोग करेंगे, तो कृपया दुनिया का पक्ष लें और इसे C ++ के बजाय C में लिखें। यदि आप ऐसा नहीं कर सकते, तो कम से कम एक C API लिखिए। ब्रह्मांड में सब कुछ सी कोड से किसी न किसी तरह से लिंक किया जा सकता है, आमतौर पर न्यूनतम प्रयास के साथ। इसके विपरीत, जब आप C ++ कोड को अन्य C ++ कोड से कॉल करने का प्रयास करते हैं, तो आपको अक्सर ABI के प्रमुख मुद्दे होंगे , अन्य भाषाओं से अकेले रहने दें।
डेनियल प्रेडेन

37
@KonstantinSolomatov - तथ्य यह है कि सी ++ से सी संकलक के लिए एक सी की जरूरत है साबित होता है कि सी एक है जो सर्वव्यापी है।
detly

11
@KonstantinSolomatov: कृपया सोचना बंद कर दें कि C C ++ है। C में क्लोजर नहीं है। C do के कुछ एक्सटेंशन (जैसे कि संकलक के gcc परिवार द्वारा कार्यान्वित) लेकिन C स्वयं नहीं है (यानी, यह मूल K & R कल्पना या अंतिम C मानकों में से कोई भी नहीं है)।
फेलो

88

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

मुझे यह उल्लेख करना चाहिए कि जब ओओपी प्रोग्रामिंग पाठ्यक्रमों में "अंतिम मॉडल" के रूप में प्रस्तुत किया जाता है तो मुझे हमेशा थोड़ा आश्चर्य होता है कि यह अच्छी प्रोग्रामिंग के लिए एकमात्र संभव समापन बिंदु है। प्रोग्रामिंग के कई अन्य पहलुओं की तरह, OOP का मूल्य कई प्रतिस्पर्धी कारकों के बीच एक समझौता है, जिसमें मानव दिमाग की जानकारी का आयोजन, सामाजिक समूह लंबी अवधि में सॉफ्टवेयर का समर्थन कैसे करते हैं, और वस्तु-उन्मुख प्रोग्रामिंग के मामले में, कुछ बहुत ही गहरे पहलू ब्रह्मांड कैसे काम करता है।

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

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

ध्वनि भी सार? यह वास्तव में नहीं है। उदाहरण के लिए कल्पना कीजिए कि आपके दोस्त के घर तक सड़क को नेविगेट करने की कोशिश कर रहा है अगर कारों के बजाय आप तेजी से दोलन क्षेत्रों का सामना कर रहे हैं और वेग के विशाल रेंज के साथ चलती पदार्थ के क्षणिक संघनन। ऐसा परिदृश्य सामाजिककरण के अवसरों में गहराई से कटौती कर सकता है, हाँ? हम वस्तुओं की जरूरत है हम, कर रहे हैं , वस्तुओं और वस्तुओं के अस्तित्व हमारे आसपास के माहौल के सरलीकरण का एक विशाल और अत्यंत महत्वपूर्ण स्तर के साथ हमें प्रदान करता है।

तो चलो सॉफ्टवेयर के चारों ओर वापस खींचते हैं। वास्तविक दुनिया में वस्तुओं को प्रोग्रामिंग के संदर्भ में वस्तुओं के बारे में क्या कहना है?

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

परिभाषा के साथ, OOP के सबसे आसान रूपों को पहचानना आसान है। वे वे हैं जो केवल पहले से ही "संलग्न" या कुछ वास्तविक दुनिया द्वारा परिभाषित, केवल एक व्यक्ति, घर, या कार जैसी भौतिक वस्तु द्वारा उपयोग किए जाने वाले डेटा से थोड़ा बाहर निकलते हैं। आज भी, यह अभी भी अक्सर वस्तुओं की एकमात्र परिभाषा है जो लोग सॉफ़्टवेयर पाठ्यक्रमों में प्राप्त करते हैं। यह बहुत बुरा है, क्योंकि यहां तक ​​कि तुच्छ वस्तु-उन्मुख कार्यक्रमों की तुलना में व्यापक परिभाषा की आवश्यकता है।

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

लेकिन कंप्यूटर और नेटवर्क का उपयोग करके, हम इस तरह के क्षणिक संगोष्ठी को एक दीर्घकालिक वस्तु की तरह प्रतीत कर सकते हैं जो कि एक सॉफ्टवेयर ऑब्जेक्ट के रूप में इसकी मेमोरी को कैप्चर और बनाए रखता है। कंप्यूटर और डेटाबेस के साथ बहुत सी बातें हम क्षणिक घटनाओं के इस तरह के अमरत्व की मात्रा में करते हैं, जिसमें हम अपने वास्तविक ब्रह्मांड को कैप्चर करके और इसे उन तरीकों से बढ़ाकर समृद्ध बनाने का प्रयास करते हैं जो संभवतः भौतिक रूप से मौजूद नहीं हो सकते। जैसे, क्या आपने हाल ही में एक असली पेंडोरा देखा है? वास्तविक दुनिया के टुकड़ों के ऐसे कैप्चर और एक्सटेंशन हमारे अपने जीवन, अर्थव्यवस्थाओं और विकल्पों को उल्लेखनीय तरीके से समृद्ध और विस्तारित करने में मदद करते हैं। यह मेरे लिए ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग का दिल का मैदान है, जहां यह पड़ा है, और सबसे उल्लेखनीय प्रभाव पड़ता है।

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

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

अन्य क्षेत्र जहां ओआरओपी जा सकता है, पुरानी वस्तु अवधारणाओं पर बहुत अधिक ध्यान केंद्रित कर रहा है ।

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

और OOP के मेरे "समालोचक" के लिए बहुत कुछ! फिर भी, मुझे आशा है कि मैंने बताया है कि क्यों एक अमीर साइबरवर्ल्ड बनाने का मतलब है कि प्रोग्रामिंग शैलियों की विविधता को शामिल करना, बजाय यह मानने के कि "बस एक" वह सब है जिसकी आवश्यकता है। मेरी भावना यह है कि वास्तव में दिलचस्प सामान अभी आना बाकी है, फिर चाहे हम जो भी करते हों, वह बहुत अधिक सांसारिक हो!


18
मुझे यकीन है कि कुछ लोग "आगे पढ़ें केवल तभी यदि आप भौतिक-स्तर की खोज में रुचि रखते हैं" भाग में हैं। मुझे खुशी है कि मैंने ऐसा नहीं किया। यह उस तरह की सोच है जो हमारी समझ की नींव को हिलाती है, और शायद एकमात्र तरीका जिससे हम उल्लेखनीय प्रगति करने जा रहे हैं। पढ़ने का मौका देने के लिए धन्यवाद।
मैट एश

@Raynos, $ MattEsch, आप दोनों के लिए आपकी तरह के शब्दों के लिए धन्यवाद, और मुझे खुशी है कि आपने इसे दिलचस्प पाया!
टेरी बोलिंगर ने

1
साइट पर साइन अप करने के लिए साइन अप करने में सक्षम होने के लिए-यह गहन-विचार, शानदार उत्तर। =)
sgorozco

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

2
यह जवाब भी है कि हमें अभी भी SQL की आवश्यकता क्यों है!
एचएलजीईएम

25

सबसे पहले, आपको हर चीज के लिए OOP की जरूरत नहीं है, इसके बावजूद जो भी हठधर्मिता लोकप्रिय हुई है। जावा के विपरीत, C फंक्शन पॉइंटर्स और यहां तक ​​कि क्लोजर को भी अनुमति देता है जो कार्यात्मक प्रोग्रामिंग के लिए द्वार खोलता है और समस्या के काफी हिस्से को OOP हैंडल करता है, क्योंकि यह निर्भरता इंजेक्शन के साधन प्रदान करता है। इसके अलावा सतर्क मैक्रोज़ के प्रयोग वास्तव में, कुछ बहुत अच्छी चीजें बना सकते हैं के रूप में sglib साबित होता है।

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

यह एक पुरानी भाषा है, जो विश्वसनीय और सुसंगत हो गई है, जबकि वास्तव में अधिक जटिल नहीं है। और वह सब एक तरफ, इसमें एक विशाल इको-सिस्टम है और यह बस हर जगह चलता है।


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

7
बिना कचरा कलेक्टर के कार्यात्मक शैली में कार्यक्रम करना बहुत कठिन है।
कॉन्सटेंटिन सोलोमेटोव

@KonstantinSolomatov: सबसे पहले, यह बहुत व्यक्तिपरक है। दूसरी बात, आप आवश्यकता पड़ने पर C में कचरा संग्रहण जोड़ सकते हैं।
202

यदि आप जावा और C ++ के बीच समझौता चाहते हैं, तो Obj-C :) कोशिश करें निश्चित रूप से हर C / C ++ प्रोग्रामर को कुछ करना चाहिए।
सुल्तान

21

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

मूल रूप से यह C की भूमिका को पूरा करने के लिए उबलता है जो C ++ के लिए अनुपयुक्त है।


2
मम्म .. एक सी, टमाटर, और पनीर रोल!
डेडएमजी

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

12

C ++ या Java जैसी भाषाओं पर C का उपयोग करने का एक फायदा यह है कि इसमें हुड के नीचे बहुत सारा जादू नहीं होता है। जब आइटम आबंटित किए जाते हैं, तो कोई भी कंस्ट्रक्टर नहीं चलाया जाता है, और जब ऑब्जेक्ट स्कोप से बाहर जाते हैं तो कोई डिस्ट्रक्टर नहीं चलाया जाता है। कोई नाम नहीं है और कोई vtables नहीं है। प्रदर्शन की भविष्यवाणी करना आसान है; आपको एक कूड़ा उठाने वाले को नियमित करने और उसके समय को गिराने के बारे में चिंता करने की ज़रूरत नहीं है।

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

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


2
रन-टाइम की पेनल्टी बकवास है। C ++ स्ट्रिंग्स की तुलना में C- स्ट्रिंग्स (शून्य समाप्त) बहुत कम कुशल हैं। इसके अलावा, एक स्ट्रिंग क्लास सिर्फ C के समान कॉम्पैक्ट हो सकती है, जब तक कि आप पूरे को stdअंदर नहीं खींचते ।
Pubby

1
एक टूलकिन जो उस अप्रयुक्त कार्यों को नहीं हटाता है, stringयदि आप वैधानिक रूप से लिंक को सीआरटी से लिंक नहीं करते हैं तो इसका उपयोग नहीं किया जाता है।
बिली ओनेल

10
मूर्खतापूर्ण बात यह है, मैं एक पुस्तकालय के साथ काम करता हूं जहां पर्याप्तstd::string परिष्कृत नहीं है । यदि आप वास्तव में स्ट्रिंग्स के बारे में गंभीर हैं, तो प्रदर्शन और क्षमताओं दोनों के मामले में, आप C का उपयोग करने के लिए वापस आ गए हैं और यह सब अपने आप फिर से कर रहे हैं, हालांकि यह char*सुनिश्चित करने के लिए सादे पुराने एस का उपयोग नहीं कर रहे हैं। (स्ट्रिंग्स आश्चर्यजनक रूप से जटिल हैं, भले ही आप उनसे जटिल होने की उम्मीद कर रहे हों।)
डोनल फेलो

1
@DonalFellow दिलचस्प। यही कारण है कि सी मानक ने हमेशा तार और हैश टेबल जैसी चीजों को आगे बढ़ाया है, जितना कि उनकी अनुपस्थिति कभी-कभी मुझे परेशान करती है।
इंजीनियर

@ArcaneEngineer: C में मूलभूत गुम डेटा प्रकार "T [] का एक स्लाइस है" जो एक T * और size_t को मिलाएगा, एक सरणी की तरह अनुक्रमित किया जा सकता है, T * में विघटित हो सकता है, और इसे अंतर्निहित रूप से परिवर्तित किया जा सकता है। कोई भी T [n] प्रकार (संकलक द्वारा स्वचालित रूप से आपूर्ति की जा रही आकार के साथ)। इस तरह का एक प्रकार कई मामलों में स्वचालित सीमा की जाँच की अनुमति दे सकता है, जहाँ यह बहुत असंभव है, जबकि कई प्रकार के कोड बहुत सारे क्लीनर और अधिक सुपाठ्य बनाते हैं।
सुपरकैट

11

एंबेडेड सिस्टम और ड्राइवर आमतौर पर सी में क्रमादेशित होते हैं। इसके अलावा वहाँ से बाहर विरासत प्रणाली के टन हैं जो अभी भी बनाए हुए हैं और विस्तारित हैं।


2
हां, C हर चीज पर चलता है। और भाषा सीखना बहुत आसान है (सी ++ की तुलना में)।
बेंजामिन

10

वही चीज जो न्युमेटिक हथौड़ों (एयर हथौड़ों) के युग में एक मैनुअल हथौड़ा को लोकप्रिय बनाती है: सी कुछ नौकरियों के लिए अभी भी सही उपकरण है।


6

सादगी, स्थिरता और सटीक।

यह सरल है - आपको एक जटिल विकास वातावरण, व्यापक पुस्तकालयों या एक आभासी मशीन की आवश्यकता नहीं है।

यह सुसंगत है - 10 साल पहले लिखा गया अधिकांश सी आज संकलित कर सकता है।

परिशुद्धता - यह है कि आप मशीन के स्तर पर उतरते हैं, आवश्यकतानुसार स्मृति स्थानों को जानते हैं। यह प्रदर्शन और एम्बेडेड हार्डवेयर के लिए बहुत अच्छा है।

यह सब कुछ के लिए नहीं है, बिट यह अभी भी एक उपयोगी उपकरण है।


5
बेहतर अभी तक, एक उचित मौका है कि 10 साल पहले संकलित कोड आज निष्पादित हो सकता है।
डोनाल्ड फेलो

: अभी तक बनाया गया है।
सुपरकैट

6

मैं एक और उत्तर से दो बिंदुओं का हवाला देता हूं, क्योंकि वे ठीक-ठीक उन कारणों को पकड़ते हैं जिनके कारण मैं समय-समय पर सी का उपयोग करता हूं (यह मेरी पसंद की मुख्य भाषा नहीं है, हालांकि):

  • सी सरल है। इसमें परिष्कृत ओओपी या कार्यात्मक भाषाओं की अभिव्यक्ति की कमी है, लेकिन इसकी सरलता का मतलब है कि इसे जल्दी से उठाया जा सकता है।
  • C परिपक्व है। अंतिम मानक जिसने बड़े बदलाव पेश किए, वह है C99, और यह पिछले मानकों के साथ ज्यादातर पीछे की ओर संगत है। नई भाषाओं के विपरीत (कहते हैं, पायथन), आपको जल्द ही किसी भी समय परिवर्तनों को तोड़ने के बारे में चिंता करने की आवश्यकता नहीं है।

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

C ++ के साथ मुझे एक अलग अनुभव था। मैंने इसे १ ९९ ५ के आसपास सीखा और इसका मतलब था कि अपारदर्शी से OOP तक एक बड़ा प्रतिमान स्विच। महान! मैंने इसे 1999 तक कई परियोजनाओं के लिए उपयोग किया। कुछ वर्षों तक मैंने C ++ का उपयोग नहीं किया और जब मैंने इसे फिर से उठाया (2008) तो मुझे बहुत सारी नई सुविधाएँ पहले से ही भाषा में मिलीं, और इससे भी अधिक योजनाबद्ध (इस बीच C ++ में पेश किया गया) 1 1)। मुझे यह अहसास हुआ कि मुझे फिर से भाषा सीखनी है।

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

IMHO, एक प्रोग्रामिंग भाषा में एक स्पष्ट, सुसंगत और स्थिर डिजाइन होना चाहिए। मुझे निकलस विर्थ जैसे डिजाइनरों का दृष्टिकोण पसंद है: हर बार जब उन्हें एक अलग भाषा की आवश्यकता महसूस होती है, तो उन्होंने एक नया (पास्कल, मोडुला -2, मोडुला -3, ओबेरॉन) डिजाइन किया। मुझे ऐसी भाषाएँ पसंद नहीं हैं जो हर 5-10 साल में महत्वपूर्ण बदलावों से गुजरती हैं: वे बढ़ते लक्ष्य की तरह हैं और मुझे कभी नहीं लगता कि उन्हें गहराई से जानने के लिए अपना समय निवेश करना उचित है, क्योंकि अब मैं जो संस्करण सीख रही हूं, वह शायद कुछ ही में अप्रचलित होगा वैसे भी साल।

इस अर्थ में C IMO का विजेता है: यह कुछ अनुप्रयोगों के लिए अच्छा है और दूसरों के लिए कम उपयुक्त है, लेकिन इसका लाभ यह है कि यह सरल और अपेक्षाकृत स्थिर है।


4

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


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

1

आप शायद यह पूछना चाहते थे कि लोग सी ++ के बजाय सी का उपयोग क्यों करते हैं, इस तथ्य के बावजूद कि जब आपके पास सी कंपाइलर होता है, तो आपके पास आमतौर पर सी + डायलर भी होता है।

  • C ++ की तुलना में C भाषा बहुत सरल है। मैं किसी भी कंपनी को नहीं जानता जो उनके कोडिंग सम्मेलन में पूर्ण C ++ मानक का उपयोग करती है। उदाहरण के लिए Google की C ++ कोड शैली पर एक नज़र डालें: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
  • C संकलन करने के लिए बहुत तेज़ है। निर्माणों को संकलित करने के लिए कड़ी मेहनत की कमी के लिए धन्यवाद।

यह लिंक टूट गया है।
ar2015

0

कुछ भी तो नहीं। TIOBE एक बेकार इंडेक्स है। यदि आप वास्तव में उनके माप को देखते हैं, तो यह एक पूर्ण अनुमान है- सबसे अच्छा।


10
यह तथ्य कि TIOBE बेकार है इसका मतलब यह नहीं है कि C लोकप्रिय नहीं है
Raynos

हालांकि, यह निश्चित रूप से ओपी में प्रस्तुत तर्क को हरा देता है- कि सी लोकप्रिय है और इसलिए इसका कुछ उपयोग होना चाहिए।
डेडएमजी

2
C की लोकप्रियता का एक बेहतर उपाय यह है कि लगभग हर प्लेटफ़ॉर्म पर C कंपाइलर है
Raynos

@ रेयानोस: यह एक माप नहीं है। केवल एक चीज जिसका मतलब है कि इसे लागू करना आसान है। यह इस बारे में कुछ नहीं कहता कि कितने लोग इसका उपयोग करते हैं, या क्यों।
डेडएमजी

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

0

बहुत सारे लिगेसी सॉफ्टवेयर

बहुत सी कंपनियाँ बदल नहीं सकती हैं, तुरंत उनके सभी कोड C ++ या इसी तरह के हैं।

कई कंपनियां अपना कोड बदलने का जोखिम नहीं उठा सकती हैं।

कई कंपनियां अपने कोड को बदल सकती हैं, लेकिन परवाह नहीं करती हैं, या "सस्ते" हैं।

कई कंपनियां पलायन की प्रक्रिया में हैं, लेकिन, अभी तक समाप्त नहीं हुई हैं।

हिडन ऑब्जेक्ट ओरिएंटेशन

(नॉन ऑब्जेक्ट ओरिएंटेड) सी सोर्स कोड को ऑब्जेक्ट ओरिएंटेड सी सोर्स कोड के रूप में डिज़ाइन किया गया है, जो एप्लिकेशन ऑब्जेक्ट ओरिएंटेशन के साथ मॉडलिंग करते हैं, और "शुद्ध सी", या "सी ++" या अन्य ओओ प्रोग से अनुवाद करने वाले टूल के साथ कोडित हैं। C में लंग।

मैंने सुना है कि कुछ वीडियो गेम इस तरह से किए जाते हैं। कुछ क्रॉस प्लेटफ़ॉर्म टूल भी, और GNK लिनक्स OS वितरण के लिए GTK (GObject, GLibrary) विज़ुअल इंटरफ़ेस लाइब्रेरी।


3
इस उत्तर के उत्तरार्द्ध को हटा दिया जाना चाहिए।
अरामिस

@aramis। दूसरे भाग का अर्थ है: कई कोड सीधे "सी" में डोंड प्रतीत होते हैं, लेकिन, वास्तव में अन्य भाषा में, और "सी" के लिए
traslated

0

मुझे लगता है कि कुछ उत्तर देने वाले बताते हैं कि सी सबसे लोकप्रिय क्यों है, यह लंबे समय से आसपास है, यह अधिकांश प्लेटफार्मों, मुफ्त आदि में उपलब्ध है।

लेकिन अन्य भाषाओं के बारे में भी यही कहा जा सकता है, उदाहरण के लिए नि: शुल्क पास्कल - यह मुफ़्त है, और केवल सभी प्लेटफार्मों के लिए समर्थित है।

पास्कल का आविष्कार 1970 के आसपास किया गया था, सी का आविष्कार 1972 के आसपास किया गया था, इसलिए मुझे लगता है कि पास्कल सी के आसपास ही रहा है।

व्यक्तिगत रूप से मुझे लगता है कि सी सबसे लोकप्रिय भाषा है क्योंकि किसी भी व्यक्ति द्वारा पुन: उपयोग किए जाने के लिए अभी और अधिक खुला स्रोत कोड उपलब्ध है। और हाँ यह पास्कल की तुलना में निचला स्तर है, इसलिए यह विधानसभा के करीब हो रहा है लेकिन विधानसभा की तुलना में यह बहुत अधिक पठनीय है।

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

सी वह वैश्विक भाषा लगती है, लेकिन मुझे लगता है कि यह ऑब्जेक्ट पास्कल जैसा होगा। क्यों ऑब्जेक्ट पास्कल, यह एक अधिक पठनीय प्रोग्रामिंग भाषा है, OOP कोड C की तुलना में अधिक पुन: प्रयोज्य और कम बग प्रवण (मेरी राय में) है।

C / C ++ की तुलना में ऑब्जेक्ट पास्कल के साथ प्रबंधन करने के लिए बहुत बड़े अनुप्रयोग आसान हैं।

प्रोग्रामिंग भाषा के रूप में '70 के बाद से कुछ है, और हर 5 या 10 साल में बदलने वाली भाषाओं को पसंद नहीं करते हैं। जैसे-जैसे समय आगे बढ़ता है और प्रोग्रामिंग के तरीकों में सुधार होता है। अगर हर साल कुछ भाषाओं में भारी बदलाव आता है, तो शायद इसके डिजाइनर द्वारा अच्छी तरह से सोचा नहीं गया था। लेकिन 1970 से 2012 लगभग आधी सदी है, सॉफ्टवेयर विकास में उपयोग किए जाने वाले अग्रिमों को शामिल करने के लिए उस समय की भाषा में बदलाव करना ठीक है।

सी खुद को कई बार संशोधित किया गया है। तो, यह अन्य भाषाओं की तुलना में बेहतर नहीं है जो देखने का बिंदु है।


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

0

क्योंकि C का एक बहुत बड़ा उपयोगकर्ता आधार है। हाँ, यह एक पकड़ -22 का एक सा है, लेकिन जब मैं स्टैकऑवरफ्लो पर सी ओवर के बारे में एक सवाल पूछता हूं, तो मुझे तुरंत जवाब मिल जाता है। अजगर के बारे में एक ही सवाल जवाब पाने के लिए घंटों लग सकता है।

C ++ के संबंध में, यह सीखने के लिए IMO अधिक जटिल है। इसके अलावा, 10 वर्षों के लिए OOP की कोशिश करने के बाद, मुझे लगता है कि यह हमेशा उपयोगी नहीं है, और अक्सर कई बार इसके बजाय प्रक्रियात्मक प्रोग्रामिंग का उपयोग करना आसान होता है।


क्या आपने C # या Java के लिए SO प्रश्न पूछने की तुलना की थी?
gnat

@ वागट यह सी वी पायथन का एक अलग उदाहरण था (जिस तरह से अधिक सवाल पूछे गए हैं!)। मुझे C # के साथ कोई अनुभव नहीं है (क्या आपने मेरे लिए C # या jav के लिए SO प्रश्न नहीं पूछा है?)
puk

हे, मुझे लगता है कि StackOverflow पर #python समुदाय लगभग हमेशा सुपर फास्ट है। हालांकि मुझे आश्चर्य होगा कि अगर सी समुदाय ने जवाब की गति के लिए जावास्क्रिप्ट समुदाय को पछाड़ दिया। (अधिकतर मात्रा के कारण)
थोरसुमोनर
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.