अगर यह इतना खतरनाक है तो लोग C का उपयोग क्यों करते हैं?

Question

मैं सी सीखने पर विचार कर रहा हूं।

लेकिन लोग C (या C ++) का उपयोग क्यों करते हैं अगर इसे 'खतरनाक तरीके से' इस्तेमाल किया जा सकता है?

खतरनाक रूप से, मेरा मतलब पॉइंटर्स और इसी तरह के अन्य सामानों से है।

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

Comments

शेफ चाकू का उपयोग क्यों करते हैं, अगर उन्हें 'खतरनाक तरीके से' इस्तेमाल किया जा सकता है?

— ऑर्केलेंस

महान शक्ति के साथ महान जिम्मेदारी आती है।

— पीटर बी

जो उड़ा, pontificate ज्यादा?

— मैथ्यू जेम्स ब्रिग्स

क्योंकि "बैक इन द डे" जब सी चॉइस की भाषा बन गई, तो हमें उम्मीद थी कि हम इस तरह से सामान संभाल पाएंगे, क्योंकि हमें करना था। व्याख्या या बाइट-कोडेड भाषाएँ बहुत धीमी थीं क्योंकि दिन के प्रोसेसर इतने धीमे थे। (आज मैं $ 2 के लिए $ 2 के लिए एक 2-गीगाहर्ट्ज मल्टी-कोर सीपीयू और 4 जीबी मेमोरी के साथ एक कम-एंड डेस्कटॉप पीसी खरीद सकता हूं । आपके पास कोई आईडीईए नहीं है जो मेरे जैसे आदमी के लिए बिल्कुल अविश्वसनीय प्रतीत होता है जिनके लिए 4 मेगाहर्ट्ज पीसी है। स्मृति के 640 किलोबाइट के साथ आनंद था ...)। इसका सामना करें - मूर का कानून जीता। खेल। ऊपर!

— बॉब जार्विस

@ याकूब जार्विस: खेल खत्म नहीं हुआ। अगर आपको लगता है कि आपके 2 + GHz, 4GB PC - या उस मामले के लिए, नवीनतम CUDA GPU के साथ कई सौ 4 GHz PC के आपके क्लस्टर, या जो कुछ भी - बहुत तेज़ है, तो आप बस कठिन पर्याप्त समस्याओं पर काम नहीं कर रहे हैं :-)

— jamesqf

Answer 1

1. C अन्य भाषाओं के बारे में सोचता है जिन्हें आप सोच रहे हैं। प्रोग्रामिंग "सुरक्षित" बनाने के तरीके के बारे में अब हम बहुत कुछ जानते हैं जो सी जैसी भाषाओं के साथ अनुभव से आता है।

2. सी के बाद से निकली सुरक्षित भाषाओं में से कई एक बड़े रनटाइम पर भरोसा करते हैं, एक अधिक जटिल सुविधा सेट और / या अपने लक्ष्यों को प्राप्त करने के लिए एक आभासी मशीन। नतीजतन, सी सभी लोकप्रिय / मुख्यधारा की भाषाओं में "सबसे कम आम भाजक" के रूप में बनी हुई है।

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

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

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

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

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

---

इसके अलावा, आप कभी भी एक अस्पष्ट जावा प्रतियोगिता को मनोरंजक सी प्रतियोगिता के रूप में मनोरंजक नहीं बनायेंगे ।

Comments

"सबसे कम आम भाजक" असंगत लगता है। मैं कहता हूँ कि, कई दूर की भाषाओं के विपरीत, C आपको अतिरिक्त सामान का एक टन लागू नहीं करता है, जिसकी आपको आवश्यकता नहीं है और आपको एक लाइटनिंग-फास्ट बेस प्रदान करता है जिस पर आपको आवश्यक सामान को लागू करना है। क्या आपका आशय यही था?

— अंडरस्कोर_ड

"आपके पास वास्तव में एक दूसरे के बिना नहीं हो सकता है।": वास्तव में कई नई भाषाओं (जंग, निम, डी, ...) का प्रयास है। यह मूल रूप से एक "सुरक्षित" भाषा के एक युगल "असुरक्षित" आदिम के साथ मेल खाने के लिए उबलता है जब नियंत्रण का यह स्तर बिल्कुल आवश्यक है। हालाँकि, वे सभी C और C ++ से संचित ज्ञान पर निर्माण करते हैं, इसलिए शायद यह कहा जाए कि जिस समय C और C ++ विकसित किए गए थे, उस समय आप एक के बिना एक नहीं हो सकते थे, और आजकल ऐसी भाषाएं हैं जो विभाजन का प्रयास करती हैं उनके "असुरक्षित" बिट्स, लेकिन वे अभी तक नहीं पकड़े हैं।

— मैथ्यू एम।

1) एक वैध बिंदु नहीं है! सी ने अल्गोल 68 से विशेषताएं लीं, जो इस अर्थ में एक "सुरक्षित" भाषा है; इसलिए लेखक ऐसी भाषाओं के बारे में जानते थे। अन्य बिंदु महान हैं।

— रीइनियरियरपोस्ट

@MatthieuM। आप Microsoft अनुसंधान को भी देखना चाह सकते हैं। उन्होंने पिछले एक या दो दशक में कुछ प्रबंधित OSes का निर्माण किया है, जिनमें कुछ ऐसे भी हैं जो कुछ तेज हैं (पूरी तरह से आकस्मिक रूप से - इनमें से अधिकांश शोध OS का प्राथमिक लक्ष्य सुरक्षा है, गति नहीं) कुछ वास्तविक जीवन के वर्कलोड के लिए एक समान अप्रबंधित OS से । स्पीडअप ज्यादातर सुरक्षा बाधाओं के कारण होता है - स्थिर और गतिशील निष्पादन योग्य जाँच उन अनुकूलन को अनुमति देता है जो अप्रबंधित कोड में उपलब्ध नहीं हैं। सभी को देखने के लिए काफी कुछ है, और सभी स्रोतों में शामिल हैं;)

— लुअन

@ लुअन: मिडोरी इतनी भयानक लगती है; मैं हमेशा जेओ के ब्लॉग लेखों का इंतजार कर रहा हूं।

— मथिउ एम।

Answer 2

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

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

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

---

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

दूसरी ओर (टिप्पणियों के जवाब में), एक सिस्टम प्रोग्रामिंग भाषा को स्वयं-होस्टिंग होने की आवश्यकता नहीं है। यह मुद्दा इसलिए सामने आया क्योंकि मूल प्रश्न "लोग सी का उपयोग क्यों करते हैं", पहली टिप्पणी में पूछा गया कि "आपको PyPy होने पर C" जैसी भाषा की आवश्यकता क्यों होगी, और मैंने नोट किया कि PyPy वास्तव में C. का उपयोग करता है। मूल रूप से प्रश्न के लिए प्रासंगिक था, लेकिन दुर्भाग्य से (और भ्रामक) "स्व-होस्टिंग" वास्तव में इस उत्तर के लिए प्रासंगिक नहीं है। मुझे खेद है कि मैं इसे लाया।

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

Comments

"यदि आप जावा वर्चुअल मशीन या पाइथन इंटरप्रेटर लिखते हैं, तो आपको उन्हें लिखने के लिए एक सिस्टम प्रोग्रामिंग लैंग्वेज की आवश्यकता होगी।" उह? आप PyPy की व्याख्या कैसे करते हैं? संकलक या दुभाषिया या वर्चुअल मशीन लिखने के लिए आपको C जैसी भाषा की आवश्यकता क्यों होगी?

— विंसेंट सवार्ड

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

— विन्सेन्ट सावर

यहां तक ​​कि अगर यह सभी तरह से नीचे गिरता है, तो PyPy जैसी कोई चीज किसी अन्य भाषा में लिखे गए पायथन दुभाषिया के बिना मौजूद नहीं हो सकती है।

— ब्लरफुल

@Birfl लेकिन यह वास्तव में ज्यादा नहीं कह रहा है। सी असेंबली कंपाइलर के बिना नहीं लिखा जा सकता था, और आप असेंबली को हार्डवेयर के बिना नहीं लिख सकते जो इसे लागू करता है।

— बाग़ जू garden

यदि PyPy "सिस्टम प्रोग्रामिंग लैंग्वेज" नहीं है, क्योंकि C कंपाइलर कहीं पर है, तो C सिस्टम प्रोग्रामिंग लैंग्वेज नहीं है, क्योंकि असेंबलर किसी जगह इस्तेमाल किया जाता है। दरअसल, इन दिनों सी का किसी और भाषा में अनुवाद करना लोकप्रिय नहीं है? उदाहरण के लिए LLVM

— बहिष्कृत और बंद

Answer 3

एक और उत्तर जोड़ने के लिए क्षमा करें, लेकिन मुझे नहीं लगता कि कोई भी मौजूदा उत्तर सीधे आपके पहले वाक्य को बताते हुए संबोधित करता है:

'मैं C सीखने पर विचार कर रहा हूँ'

क्यों? क्या आप उन चीजों के प्रकार करना चाहते हैं जिनका उपयोग आमतौर पर C आज के लिए किया जाता है (जैसे डिवाइस ड्राइवर, VMs, गेम इंजन, मीडिया लाइब्रेरी, एम्बेडेड सिस्टम, OS कर्नेल)?

यदि हाँ, तो हाँ, निश्चित रूप से C या C ++ सीखें, यह इस बात पर निर्भर करता है कि आप किसमें रुचि रखते हैं। क्या आप इसे सीखना चाहते हैं ताकि आपको अपनी उच्च-स्तरीय भाषा की गहरी समझ हो?

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

Gist पाने के लिए कुछ C कोड लिखें। फिर इसे वापस शेल्फ पर रखें। जब तक आप प्रोडक्शन सी कोड नहीं लिखना चाहते, तब तक सुरक्षा की चिंता न करें ।

Comments

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

— लुआण

@Luaan वास्तव में, पॉइंटर्स का उपयोग करके स्ट्रिंग को कॉपी करना सीखना आपको विचार देता है, यह सीखना कि कैसे सुरक्षित रूप से ऐसा करना एक और स्तर है, और किसी के लक्ष्यों पर निर्भर करता है शायद एक अनावश्यक।

— जारेड स्मिथ

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

— ट्रिस्टन

मैं आखिरी वाक्य से असहमत हूं। बुरी आदतों को विकसित करने से पहले जानें कि यह कैसे सही है।

— ग्लॉगल

@glglgl IDK, अगर मैं वेब पर एक जावास्क्रिप्ट स्निपेट पढ़ता हूं (या लिखता हूं) तो मैं समझ के साथ ऐसा करता हूं कि इसका उत्पादन तैयार नहीं है: इसमें अपवाद हैंडलिंग नहीं होगा, यह O (n ^ 2) हो सकता है, आदि कोई नहीं। उस बिंदु को प्राप्त करने के लिए आवश्यक है। यह सभी उत्पादन कोड के लिए आवश्यक है। यह अलग क्यों है? मैं बौद्धिक रूप से समझते हुए अपने स्वयं के संपादन के लिए भोले सी लिख सकता हूं कि अगर मैं इसे बाहर रखना चाहता था तो मुझे बहुत अधिक काम करने की आवश्यकता होगी।

— जारेड स्मिथ

Answer 4

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

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

* यहां तक ​​कि एकता भी सभी सी # नहीं है, इसके विशाल हिस्से सी ++ हैं और आप सिर्फ अपने गेम कोड के लिए सी # का उपयोग करते हैं।

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

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

मेरी "बस गति पहुंचने" की टिप्पणी का जवाब देने के लिए, हाँ, C # की अधिक गति बेहतर हार्डवेयर से आती है, लेकिन जैसा कि .NET फ्रेमवर्क और C # संकलक में सुधार हुआ है, वहां कुछ स्पीडअप हुए हैं।

"खेल इंजन के रूप में उसी भाषा में लिखे गए हैं" टिप्पणी के बारे में, यह निर्भर करता है। कुछ हैं, लेकिन कई भाषाओं के एक संकर में लिखे गए हैं। Unreal UnrealScript और C ++ कर सकते हैं, Unity C # Javascript और Boo करते हैं, C या C ++ में लिखे गए कई अन्य इंजन स्क्रिप्टिंग भाषाओं के रूप में Python या Lua का उपयोग करते हैं। वहाँ एक सरल जवाब नहीं है।

और सिर्फ इसलिए कि उसने मुझे यह पढ़ने के लिए उकसाया "अगर आपकी गेम 200fps या 120fps पर चलती है तो आपको परवाह है", अगर आप गेम 60fps से ज्यादा तेज चला रहे हैं, तो आप शायद सीपीयू समय बर्बाद कर रहे हैं, क्योंकि औसत मॉनीटर भी ताज़ा नहीं होता है। तेजी से। कुछ उच्च अंत और नए हैं, लेकिन इसके मानक (अभी तक नहीं ...)।

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

Comments

" सी # कुछ भी विंडोज के लिए " - ओह, यह ऐसी गिरावट है। और आप एक उदाहरण भी देते हैं। एकता। AFAIK यह नहीं लिखा है कि यह C # API प्रदान करता है क्योंकि भाषा अच्छी है। यह वास्तव में अच्छी तरह से डिजाइन किया गया है। और मुझे c ++ अधिक पसंद है, लेकिन यह क्रेडिट दिया जाना चाहिए कि यह कहां है। हो सकता है कि आपने .NET के साथ C # मिलाया हो? वे अक्सर एक साथ बाहर घूमते हैं।

— luk32

"यहां तक ​​कि एकता सभी सी # नहीं है, इसके विशाल हिस्से सी ++ हैं" और? एकता में खेल अक्सर C # का बड़े पैमाने पर उपयोग करते हैं, और पिछले कुछ समय से लगभग हो रहे हैं। यह सुझाव देना कि C # 'अभी हाल ही में पहुंच रही गति' है या तो अधिक संदर्भ की आवश्यकता है, या इस दशक तकनीक के अंधे होने का जोखिम चलाता है।

— NPSF3000

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

— पीटर टेलर

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

— लुआण

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

— लुआं

Answer 5

यह मज़ेदार है कि आप दावा करते हैं कि सी अनिश्चित है क्योंकि "इसमें संकेत हैं"। विपरीत सच है: जावा और सी # में व्यावहारिक रूप से केवल पॉइंटर्स हैं (गैर-देशी प्रकारों के लिए)। Java में सबसे आम त्रुटि शायद Null Pointer Exception (cf. https://www.infoq.com/pretations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare ) है। दूसरी सबसे आम त्रुटि शायद अप्रयुक्त वस्तुओं के लिए छिपे हुए संदर्भों को पकड़ रही है (जैसे बंद डायलॉग्स का निपटारा नहीं किया जाता है) जो इसलिए जारी नहीं किया जा सकता है, जिससे एक लंबे समय तक चलने वाले मेमोरी फ़ुट प्रिंट के साथ लंबे समय तक चलने वाले कार्यक्रम हो सकते हैं।

दो बुनियादी तंत्र हैं जो C # और Java को सुरक्षित बनाते हैं, और दो अलग-अलग तरीकों से सुरक्षित हैं:

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

हाल ही में C ++ के स्मार्ट पॉइंटर्स प्रोग्रामर्स के लिए उस काम को आसान बनाते हैं।

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

यह ध्यान देने योग्य है कि विस्तृत रन समय एक सुरक्षा जोखिम भी है। यह मुझे प्रतीत होता है कि नए खोजे गए सुरक्षा मुद्दों के कारण ओरेकल हर दो हफ्ते में जेवीएम को अपडेट कर रहा है। बेशक, एक कार्यक्रम की तुलना में जेवीएम को सत्यापित करना बहुत कठिन है।

एक विस्तृत रन समय की सुरक्षा इसलिए अस्पष्ट और एक हद तक धोखा देने वाली है: समीक्षा और पुनरावृत्तियों के साथ आपका औसत C प्रोग्राम यथोचित सुरक्षित हो सकता है। आपका औसत जावा प्रोग्राम केवल जेवीएम के रूप में सुरक्षित है; यह वास्तव में नहीं है। कभी नहीँ।

उस लेख के बारे में gets()आप ऐतिहासिक पुस्तकालय निर्णयों को प्रतिबिंबित करने के लिए लिंक करते हैं जो आज अलग तरह से बनाया जाएगा, न कि मूल भाषा।

Comments

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

— सैम ड्यूफेल

इसके अलावा, stackoverflow.com/questions/57483/… - यह कहना अधिक सटीक होगा कि जावा में "व्यावहारिक रूप से संदर्भ" हैं।

— सैम ड्यूफेल

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

— Arlie Stephens

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

— ज्यादातर विकृत

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

— पीटर ए। श्नाइडर

Answer 6

क्योंकि "सुरक्षा" की गति में लागत होती है, "सुरक्षित" भाषा धीमी गति से प्रदर्शन करती है।

आप पूछते हैं कि सी या सी ++ जैसी "खतरनाक" भाषा का उपयोग क्यों करें, क्या किसी ने आपको वीडियो ड्राइवर या जैसे पायथन या जावा में लिखा है, आदि और देखें कि आप "सुरक्षा" के बारे में कैसा महसूस करते हैं :)

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

Comments

यह सामान्य रूप से सही नहीं है कि सुरक्षा की गति में गति होती है । सबसे सुरक्षित उपलब्ध भाषाएं अधिकांश संकलन समय पर चेक करती हैं। O'Caml, Ada, Haskell, Rust सभी औसत रन गति के मामले में C से बहुत पीछे नहीं हैं। आम तौर पर वे जो करते हैं वह कार्यक्रम के आकार, स्मृति दक्षता, विलंबता और स्पष्ट रूप से संकलन समय में महत्वपूर्ण ओवरहेड है। और, हाँ, उन्हें धातु के सामान के साथ मुश्किलें हैं। लेकिन यह वास्तव में एक गति मुद्दा नहीं है।

— लेफ्टरनबाउट

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

— लुआण

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

— वू

@Wintermute हाँ मिथक है कि आप एक प्रदर्शन ओवरहेड शुरू किए बिना किसी भी सुरक्षित / सी + + को सुरक्षित नहीं बना सकते हैं, यही वजह है कि मैं इसे गंभीरता से लेता हूं ( कुछ ऐसे क्षेत्र हैं जहां यह निश्चित रूप से सच है [सीमा जाँच])। अब रस्ट अधिक व्यापक क्यों नहीं है? इतिहास और जटिलता। Rust अभी भी अपेक्षाकृत नया है और C में लिखी गई कई सबसे बड़ी प्रणालियाँ अस्तित्व में आने से पहले ही अस्तित्व में थीं - आप एक नई भाषा में एक लाख LOC को फिर से लिखने नहीं जा रहे हैं, भले ही यह अधिक सुरक्षित हो। इसके अलावा हर प्रोग्रामर और उनका कुत्ता C, Rust जानता है? सौभाग्य काफी लोगों को मिल रहा है।

— वू

@Voo डॉग्स C कर रहे हैं ... कोई आश्चर्य नहीं कि मैंने वहां इतना बुरा कोड देखा है ... j / k पॉइंट रस्ट के बारे में लिया (मैंने अभी इसे डाउनलोड और इंस्टॉल किया है, इसलिए आपके संबंध में एक और कन्वर्ट हो सकता है) BTW यह सही करने के लिए जंग ... मैं "D" :) के लिए एक ही वृद्धि कर सकता है :)

— Wintermut3

Answer 7

उपरोक्त सभी के अलावा, एक बहुत ही सामान्य उपयोग का मामला भी है, जो अन्य भाषाओं के लिए एक सामान्य पुस्तकालय के रूप में सी का उपयोग कर रहा है।

मूल रूप से, लगभग सभी भाषाओं में C का API इंटरफ़ेस है।

सरल उदाहरण, लिनक्स / आईओएस / एंड्रॉइड / विंडोज के लिए एक सामान्य एप्लिकेशन बनाने का प्रयास करें। वहाँ से बाहर आने वाले सभी उपकरणों के अलावा, जो हमने समाप्त किया वह सी में एक मुख्य पुस्तकालय कर रहा था, और फिर प्रत्येक पर्यावरण के लिए जीयूआई को बदल रहा है, जो है:

• IOS: ObjectiveC मूल रूप से C पुस्तकालयों का उपयोग कर सकता है
• Android: जावा + जेएनआई
• लिनक्स / विंडोज / मैकओएस: जीटीके / .नेट के साथ आप देशी पुस्तकालयों का उपयोग कर सकते हैं। यदि आप पायथन, पर्ल, रूबी का उपयोग करते हैं, तो उनमें से प्रत्येक के पास देशी एपीआई इंटरफेस हैं। (जावा फिर से जेएनआई के साथ)।

मेरे दो सेंट,

Comments

PHP का उपयोग करने के लिए मुझे पसंद करने वाले कारणों में से एक है, क्योंकि इसके लगभग सभी पुस्तकालय हैं, वास्तव में, सी में लिखा है - शुक्र है, या PHP असहनीय रूप से धीमा होगा :) PHP डर के बिना मैला कोड लिखने के लिए बहुत अच्छा है कुछ भी 'खतरनाक' कर रहे हैं (और इसीलिए मैं किसी भी चीज़ की तुलना में बहुत अधिक PHP कोड लिखना पसंद करता हूं - मुझे मैला कोड पसंद है !: D), लेकिन यह जानकर अच्छा लगता है कि उन फ़ंक्शन कॉल के नीचे अच्छे ol के भरोसेमंद हैं C पुस्तकालयों ने इसे कुछ प्रदर्शन को बढ़ावा देने के लिए ;-) इसके विपरीत, C में मैला कोड लिखना एक बड़ा नहीं-नहीं है ...

— ग्वेनेथ Llewelyn

Answer 8

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

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

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

कुछ इस तरह से विचार करें:

int hey(int x)
{
   printf("%d", x);
   return x*10000;
}
void wow(int x)
{
  if (x < 1000000)
    printf("QUACK!");
  hey(x);    
}

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

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

Comments

हाइपर-मॉडर्न कंपाइलर में भी C, एरे पर बाउंड-चेक नहीं करता है। यदि ऐसा होता, तो वह भाषा की परिभाषा के अनुकूल नहीं होता। मैं उस तथ्य का उपयोग कभी-कभी नकारात्मक सूचक रखने के लिए सरणी के बीच में एक अतिरिक्त सूचक के साथ सरणियों को बनाने के लिए करता हूं।

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

मैं आपके उदाहरण का सबूत देखना चाहता हूँ "QUACK!" बिना शर्त। x निश्चित रूप से तुलना के बिंदु पर 1000000 से अधिक हो सकता है, और बाद में मूल्यांकन जिसके परिणामस्वरूप अतिप्रवाह होता है, इससे बचाव नहीं होता है। यदि आप इनलाइनिंग को सक्षम करते हैं, जो अधिक बहता है, जो ओवरफ्लोिंग को कई गुना हटा देता है, तो निहित सीमा प्रतिबंधों के बारे में आपका तर्क पकड़ में नहीं आता है।

— ग्राहम

@ robertbristow-johnson: वास्तव में, मानक काफी स्पष्ट रूप से कहता है कि उदाहरण के लिए int arr[5][[5], एक्सेस करने का प्रयास arr[0][5]अनिर्धारित व्यवहार को जन्म देगा। ऐसा नियम एक संकलक के लिए संभव बनाता है जिसे कुछ ऐसा दिया जाता है जो arr[1][0]=3; arr[0][i]=6; arr[1][0]++;अनुमान लगाने के लिए arr[1][0]4 के बराबर होगा, बिना मूल्य के संबंध में i।

— सुपरकैट

@ robertbristow-johnson: भले ही कंपाइलर बिना किसी अंतराल के संरचनात्मक रूप से एरेज़ को आवंटित करता है, लेकिन यह गारंटी नहीं देता है कि किसी एक एरे को इंडेक्स करना दूसरे को प्रभावित करने की गारंटी है। कैसे इस तरह के कोड का इलाज करेंगे gcc के उदाहरण के लिए Godbolt.org/g/Avt3KW देखें ।

— 22

@ robertbristow-johnson: मैंने असेंबली में यह बताने के लिए टिप्पणी की कि यह क्या कर रहा है। कंपाइलर उस कोड को 1 में s-> arr2 [0] में देखता है और उसके बाद increments s-> arr2 [0] करता है, इसलिए gcc उन दो ऑपरेशन्स को मिलाता है जिनमें कोड होता है बस वैल्यू वैल्यू 2 को स्टोर करते हैं, बिना इस संभावना पर विचार किए कि हस्तक्षेप करने वाला लेखन s-> arr1 [i] s-> arr1 [0] के मूल्य को प्रभावित कर सकता है (चूंकि, मानक के अनुसार, यह नहीं हो सकता है)।

— सुपरकैट

Answer 9

ऐतिहासिक कारण। मुझे अक्सर नया कोड लिखने को नहीं मिलता, ज्यादातर मुझे पुराने सामान को बनाए रखने और बढ़ाने के लिए मिलता है जो दशकों से चला आ रहा है। मैं खुश हूं कि यह सी है और फोरट्रान नहीं।

जब कोई छात्र कहता है, तो मैं चिढ़ सकता हूं, "लेकिन जब आप Y कर रहे होंगे तो पृथ्वी पर यह भयानक एक्स क्यों करते हैं?"। खैर, एक्स मुझे मिला काम है और यह बिलों का बहुत अच्छी तरह से भुगतान करता है। मैंने इस अवसर पर वाई किया है, और यह मजेदार था, लेकिन एक्स जो हम में से ज्यादातर करते हैं।

Answer 10

"खतरनाक" क्या है?

यह दावा है कि सी "खतरनाक" है, जो भाषा की लौ युद्धों (जावा की तुलना में सबसे अधिक बार) में एक लगातार बात कर रहा है। हालाँकि, इस दावे के प्रमाण अस्पष्ट हैं।

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

इसके अलावा, "खतरनाक" संदर्भ पर निर्भर करता है: आप क्या करने की कोशिश कर रहे हैं, और आप किस प्रकार के जोखिमों से चिंतित हैं?

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

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

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

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

Comments

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

— सुपरकैट

Answer 11

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

तो इसीलिए लोग C का उपयोग करते हैं - कम खतरनाक उपकरण बनाने के लिए जिनका आप उपयोग करना चाहते हैं।

Answer 12

मुझे अपने प्रश्न को फिर से बताने दें:

मैं सीखने [उपकरण] पर विचार कर रहा हूं।

लेकिन लोग [उपकरण] (या [संबंधित उपकरण]) का उपयोग क्यों करते हैं यदि [वे] people खतरनाक ’तरीके से उपयोग किए जा सकते हैं?

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

उदाहरण के लिए, यदि आपको लकड़ी के एक ब्लॉक में 6 मिमी व्यास, 5 सेमी गहरे, बेलनाकार छेद लगाने की आवश्यकता है, तो ड्रिल LALR पार्सर की तुलना में बहुत बेहतर उपकरण है। यदि आप जानते हैं कि ये दो उपकरण क्या हैं, तो आप जानते हैं कि सही उपकरण कौन सा है। यदि आप पहले से ही एक ड्रिल, वॉयला !, छेद का उपयोग करना जानते हैं।

सी सिर्फ एक और उपकरण है। यह कुछ कार्यों के लिए दूसरों की तुलना में बेहतर है। यहाँ अन्य उत्तर इसे संबोधित करते हैं। यदि आप कुछ C सीखते हैं, तो आप पहचान पाएंगे कि यह कब सही उपकरण है और कब नहीं।

Comments

इस जवाब का यही कारण है कि सवालों को "मुख्य रूप से राय-आधारित" के रूप में बाहर निकाल दिया जाता है। यह मत कहो कि C के अपने फायदे हैं, कहते हैं कि वे क्या हैं!

— रीइनियरियरपोस्ट

Answer 13

मैं C सीखने पर विचार कर रहा हूँ

C को न सीखने का कोई विशेष कारण नहीं है लेकिन मैं C ++ का सुझाव दूंगा। यह बहुत कुछ प्रदान करता है कि C क्या करता है (चूंकि C ++ C का एक सुपर सेट है), जिसमें "एक्स्ट्रा" की एक बड़ी मात्रा है। C ++ से पहले C सीखना अनावश्यक है - वे प्रभावी रूप से अलग भाषाएं हैं।

एक और रास्ता रखो, अगर सी लकड़ी के उपकरणों का एक सेट था, तो यह संभवतः होगा:

• हथौड़ा
• नाखून
• हाथ आरी
• हाथ वाली ड्रिल
• ब्लॉक सैंडर
• छेनी (शायद)

आप इन उपकरणों के साथ कुछ भी निर्माण कर सकते हैं - लेकिन कुछ भी अच्छा संभावित समय और कौशल का एक बहुत आवश्यकता है।

C ++ आपके स्थानीय हार्डवेयर स्टोर पर बिजली उपकरणों का संग्रह है।

यदि आप शुरू करने के लिए बुनियादी भाषा सुविधाओं के साथ चिपके रहते हैं, तो C ++ में अपेक्षाकृत कम अतिरिक्त सीखने की अवस्था है।

लेकिन लोग C (या C ++) का उपयोग क्यों करते हैं अगर इसे 'खतरनाक तरीके से' इस्तेमाल किया जा सकता है?

क्योंकि कुछ लोग IKEA से फर्नीचर नहीं चाहते हैं। =)

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

विशेष रूप से, C में कई प्रोग्रामर्स के लिए यह वांछनीय है कि यह निम्नलिखित सुविधाओं का सेट है:

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

• संगतता - सी लंबे समय से आसपास है और सभी के पास इसके लिए उपकरण और पुस्तकालय हैं। भाषा स्वयं भी उपयुक्त नहीं है - यह एक प्रोसेसर से अपेक्षा करता है कि वह सामान रखने के लिए निर्देशों और मेमोरी को निष्पादित करे और इसके बारे में।

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

प्रोग्रामर सिर्फ जावा या पायथन या विज़ुअल बेसिक जैसी दूसरी संकलित भाषा का उपयोग क्यों नहीं करते हैं?

दक्षता (और कभी-कभी स्मृति प्रबंधन योजनाएं जो स्मृति के लिए अपेक्षाकृत सीधी पहुंच के बिना लागू नहीं की जा सकती हैं)।

सीधे पॉइंटर्स के साथ मेमोरी एक्सेस करना बहुत सी नीट (आमतौर पर जल्दी) ट्रिक्स का परिचय देता है, जब आप अपने ग्रुबी पंजे को छोटों पर और अपनी मेमोरी क्यूबहोल में शून्य पर रख सकते हैं और इस बात का इंतजार नहीं करना होगा कि ऑल टीचर को सिर्फ खिलौने सौंपना है। playtime में फिर उन्हें फिर से स्कूप।

संक्षेप में, सामान जोड़ना संभावित रूप से शिथिलता पैदा करता है या अन्यथा अवांछित जटिलता का परिचय देता है।

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

वास्तव में, कुछ भी "अतिरिक्त" संभावित रूप से शुरू करने या आपके कोड को जटिल बनाता है। "डरावने बिंदुओं के बिना" भाषाओं में, आप हमेशा अपने पीछे सफाई करने के लिए कोड के अन्य बिट्स की प्रतीक्षा कर रहे हैं या अन्यथा चीजों को करने के लिए "सुरक्षित" तरीकों का पता लगा सकते हैं - क्योंकि आपका कार्यक्रम अभी भी वही मेमोरी एक्सेस ऑपरेशन कर रहा है जैसा कि उसके साथ किया जा सकता है संकेत दिए गए। आप सिर्फ इसे संभालने वाले नहीं हैं (इसलिए आप इसे c = genius = P) नहीं कर सकते।

खतरनाक रूप से, मेरा मतलब पॉइंटर्स और इसी तरह के अन्य सामानों से है। [...] स्टैक ओवरफ्लो प्रश्न की तरह, क्यों फ़ंक्शन इतना खतरनाक है कि इसका उपयोग नहीं किया जाना चाहिए?

स्वीकृत उत्तर के अनुसार:

"यह 1999 आईएसओ सी मानक तक भाषा का एक आधिकारिक हिस्सा बना रहा, लेकिन इसे आधिकारिक तौर पर 2011 मानक द्वारा हटा दिया गया था। अधिकांश सी कार्यान्वयन अभी भी इसका समर्थन करते हैं, लेकिन कम से कम जीसीसी किसी भी कोड के लिए चेतावनी जारी करता है जो इसका उपयोग करता है।"

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

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

स्पष्ट करने के लिए, पॉइंटर्स खतरनाक नहीं हैं जब तक कि आप गलती से एक मेमोरी स्थान तक नहीं पहुंचते हैं जिसे आप करने का इरादा नहीं कर रहे थे। और फिर भी यह गारंटी नहीं देता कि आपका कंप्यूटर पिघल जाएगा या फट जाएगा। ज्यादातर मामलों में, आपका प्रोग्राम कार्य करने के लिए (सही ढंग से) बंद हो जाएगा।

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

उस बिंदु पर, क्योंकि सही मायने में प्रत्यक्ष मेमोरी एक्सेस ऑपरेशन अक्सर सामान्य रूप से कम लाभ प्रदान करते हैं, जैसे कि वे वर्षों पहले हो सकते हैं, यहां तक ​​कि गैर ++ कचरा संग्रहित भाषाओं जैसे C ++ ने स्मार्ट पॉइंटर्स जैसी चीजों को स्मृति दक्षता और सुरक्षा के बीच की खाई को पाटने में मदद करने के लिए पेश किया है ।

सारांश में, सूचक को डरने का बहुत कम कारण है जब तक कि वह सुरक्षित रूप से उपयोग नहीं किया जाता है। स्टीव "द क्रोकोडाइल हंटर" इरविन के साउथ पार्क के संस्करण से एक संकेत लें - मगरमच्छ के बुमहोल्स में अपना अंगूठा चिपकाकर न घूमें ।

Comments

मैं C के बजाय C ++ सीखने के सुझाव से सहमत नहीं हूँ। अच्छा C ++ लिखना अच्छा C लिखने से कठिन है और C ++ पढ़ना C पढ़ने से कहीं अधिक कठिन है। इसलिए C ++ की सीखने की अवस्था बहुत अधिक कठिन है। "C ++ C का एक सुपर सेट है" यह कमोबेश यह कहना है कि जूते चप्पल के सुपरसेट हैं। उनके अलग-अलग फायदे और उपयोग हैं और हर एक में ऐसी विशेषताएं हैं जो दूसरे को नहीं आती हैं।

— मार्टिंकव

"अच्छा C ++ लिखना अच्छे C लिखने से कठिन है" - बिलकुल। =) "[R] C ++ पढ़ने से C ++ बहुत कठिन है" - कोई भी उन्नत प्रोग्रामिंग संभवतः जादू से अप्रभेद्य है;; मेरे दो सेंट यह है कि यह भाषा निर्भर की तुलना में बहुत अधिक प्रोग्रामर निर्भर है, हालांकि C ++ खुद की मदद करने के लिए ज्यादा कुछ नहीं करता है। इस श्रेणी में "तो C ++ का लर्निंग कर्व ज्यादा स्टाइपर है।" - लंबे समय में, हाँ। अल्पावधि में, इससे कम (मेरी राय)। पूर्व में, C और C ++ में अधिकांश बुनियादी भाषा पाठ्यक्रम, C ++ की कक्षाओं को छोड़कर, लगभग समान सामान्य प्रकार की सामग्री को कवर करने की संभावना है।

— अन्कसुमन

"उनके अलग-अलग फायदे और उपयोग हैं और हर एक में ऐसी विशेषताएं हैं जो दूसरे को नहीं आती हैं।" - जैसा कि उल्लेख किया गया है "C [।] को न सीखने का कोई विशेष कारण नहीं है" C एक ठीक भाषा है और मैं इसके द्वारा छड़ी करता हूं। अगर यह ओपी या किसी और के अनुकूल है, तो मैं इसे सीखने का पूरा समर्थन करता हूं। =)

— अनिकसुमन

लर्निंग सी आपको सिखाता है कि मशीन कैसे काम करती है (सभी तरह से नीचे नहीं, लेकिन फिर भी धातु के करीब एक कदम)। यह सीखने का एक बहुत अच्छा कारण है।

— Agent_L

Answer 14

हमेशा की तरह, प्रोग्रामिंग भाषा समस्या हल करने का एक परिणाम है। आपको वास्तव में सी ही नहीं बल्कि कई अलग-अलग भाषाओं (और कंप्यूटर की प्रोग्रामिंग के अन्य तरीकों) को सीखना चाहिए, यह जीयूआई उपकरण या कमांड इंटरप्रेटर हों) समस्याओं को हल करते समय उपयोग करने के लिए एक अच्छा टूलबॉक्स होना चाहिए।

कभी-कभी आप पाएंगे कि एक समस्या जावा डिफ़ॉल्ट पुस्तकालयों में शामिल होने वाली किसी चीज़ के लिए अच्छी तरह से उधार देती है, ऐसे में आप इसका लाभ उठाने के लिए जावा का चयन कर सकते हैं। अन्य मामलों में यह हो सकता है कि आपको विंडोज़ पर कुछ करने की आवश्यकता है जो .NET रनटाइम में बहुत सरल है, इसलिए आप C # या VB का उपयोग कर सकते हैं। एक ग्राफिकल टूल या कमांड स्क्रिप्ट हो सकती है जो आपकी समस्या को हल करती है, फिर आप इनका उपयोग कर सकते हैं। हो सकता है कि आपको कई प्लेटफार्मों पर GUI एप्लिकेशन लिखने की आवश्यकता हो, जावा एक विकल्प हो सकता है, जिसे JDK में शामिल लाइब्रेरी दी गई है, लेकिन फिर, एक लक्ष्य प्लेटफॉर्म में JRE की कमी हो सकती है, इसलिए हो सकता है कि आप C और SDL (या परिचित) का चयन करें।

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

लब्बोलुआब यह है कि, आपको कई उपकरण, भाषाएं और प्रतिमान सीखना चाहिए जैसा कि आप संभवतः कर सकते हैं।

कृपया मानसिकता से दूर हो जाएं: "मैं एक एक्स प्रोग्रामर हूं" (एक्स = सी, सी ++, जावा, आदि)

बस "मैं एक प्रोग्रामर हूँ" का उपयोग करें।

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

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

Answer 15

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

Answer 16

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

इससे कोई फर्क नहीं पड़ता कि आप उस मामले में C ++ का उपयोग करते हैं। आप अभी भी पॉइंटर्स static_castsसे कास्ट करने के लिए कोड पर सभी जगह छिड़काव void*कर रहे हैं और अभी भी बिट्स और बाइट्स के साथ काम कर रहे हैं और सी के मुकाबले इस संदर्भ में टाइप सिस्टम का सम्मान करने से संबंधित अधिक परेशानियों से निपट रहे हैं, जिसमें बहुत सरल प्रकार की प्रणाली है जहां आप स्वतंत्र हैं करने के लिए memcpyबिट और प्रकार प्रणाली पर बुलडोजर के बारे में चिंता किए बिना चारों ओर बाइट्स।

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

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

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

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

इस सामान को लेना आसान है। मुझे याद है कि किसी के साथ एक फेसबुक पोस्ट यह इंगित करता है कि पायथन के साथ 3 डी वीडियो गेम बनाने के लिए कैसे संभव है, इस निहितार्थ के साथ कि निम्न-स्तरीय भाषाएं अप्रचलित हो रही हैं, और यह निश्चित रूप से एक सभ्य दिखने वाला खेल था। लेकिन अजगर भारी-भरकम काम करने के लिए C में लागू पुस्तकालयों में उच्च-स्तरीय कॉल कर रहा था। आप केवल मौजूदा पुस्तकालयों में उच्च-स्तरीय कॉल करके अवास्तविक इंजन 4 नहीं बना सकते हैं। अवास्तविक इंजन 4 हैपुस्तकालय। इसने सभी प्रकार के काम किए जो कि प्रकाश व्यवस्था से लेकर अपने नोडल ब्लूप्रिंट सिस्टम तक के अन्य पुस्तकालयों और इंजनों में कभी मौजूद नहीं थे और यह मक्खी पर कोड को कैसे संकलित और चला सकते हैं। यदि आप निम्न इंजन / कोर / कर्नेल स्तर पर नवाचार करना चाहते हैं, तो आपको निम्न-स्तर प्राप्त करना होगा। यदि सभी गेम देवता उच्च-स्तरीय सुरक्षित भाषाओं में बदल जाते हैं, तो कोई अवास्तविक इंजन 5 या 6 या 7 नहीं होगा। यह संभवत: 4 दशकों बाद भी लोग अवास्तविक इंजन का उपयोग कर रहे होंगे क्योंकि आप आने वाले स्तर पर कुछ नया नहीं कर सकते। पुराने में केवल उच्च-स्तरीय कॉल करके अगली-जीन इंजन के साथ बाहर।