C ++ बहुत जटिल है?
कभी-कभी मैं एक हब्र पढ़ता हूं। और जब मैंने
http://habrahabr.ru/blogs/cpp/111403/ पोस्ट पर ध्यान दिया, तो मैं ईमानदारी से मानता हूं, उसने मुझे जीने के लिए छुआ। मैं कई वर्षों से C ++ को एक मुख्य भाषा के रूप में उपयोग कर रहा हूं। एक बार फिर, मैं ईमानदारी से मानता हूं: मैं उसे पूरी तरह से नहीं जानता। यह संभावना नहीं है कि मैं Boost :: MPL, Boost :: Spirit या Boost :: Xpressive जैसी कोई चीज बना सकता हूं। लेकिन क्या यह भाषा की जटिलता के बारे में बात करने का एक कारण है? हां, C ++ भाषा मानक C # मानक से दो गुना बड़ा है। लेकिन सामग्री को देखें:
http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-334.pdf और
http://www.open-std.org/jtc1/sc22/wg21-docs / पेपर्स/2007/n2461.pdf क्या अंतर ध्यान देने योग्य है? मेरा सुझाव है कि C # भाषा का पूर्ण उपयोग करने के लिए, .NET का कुछ भाग गायब है। वास्तव में, C ++ का उपयोग STL के बिना भी किया जा सकता है और सामान्य रूप से रन-टाइम भाग के बिना भी। अपनी जवानी में, यहां तक कि ओएस ने यह लिखना शुरू कर दिया कि लोडर असेंबलर में कहां था, और सी ++ में बाकी सब कुछ। तथ्य यह है कि एसटीएल मानक में शामिल है और विस्तार से वर्णित है। .NET के विपरीत, C ++ के लिए एक बड़ा प्लस और C # के लिए एक बड़ा ऋण है। इसीलिए, हालाँकि मैं C # के बारे में खबरों से थोड़ा ईर्ष्या से देखता हूं, लेकिन मैं इसे इस्तेमाल करने की योजना नहीं बनाता। मेरा मुख्य OS लिनक्स है और मोनो परियोजना मुझे .NET के साथ समस्या का हल नहीं लगती है।
कोई भी प्रोग्रामिंग भाषा तब तक जटिल होती है जब तक आपको उससे निपटने का समय नहीं मिल जाता है। या क्या कोई सोचता है कि 10 पन्नों पर पूर्ण विवरण के साथ आदर्श पूर्ण भाषाएं हैं और बिल्कुल बिना नुकसान के? मैंने ऐसा नहीं सुना है। लेकिन कई वर्षों से मैं सुनता हूं कि सी ++ पहले से ही मर चुका है या धीरे-धीरे मर रहा है, उसकी लाश को बायपास करने की युक्तियां हैं। सभी प्रकार की रेटिंग दर्शाती है कि पहली जगह में हमारे पास जावा या सी # है। लेकिन आप हार्ड ड्राइव की सामग्री को देखते हैं, जहां जावा या सी # में अधिकांश सॉफ्टवेयर है? हां, जावा और C # खुद C ++ में लिखे गए हैं (ठीक है, कम से कम जो पहले था)।
सी के लिए मुझे क्या नफरत है।
मैं तुरंत निर्दिष्ट करता हूं कि मेरी घृणा C89 के समय से है। जैसे ही मैंने इस भाषा को देखा, मुझे तुरंत एहसास हुआ कि मुझे इससे नफरत है। विशेष रूप से ये डिजाइन:
void main(argc, argv) int argc; char **argv; { ... }
दो बार तर्क क्यों दोहराए? या फ़ंक्शन घोषणाएं केवल
func() तरह हैं, इसे क्या तर्क स्वीकार करते हैं? यह स्पष्ट है कि किसी भी रिटर्न इंट, लेकिन क्या प्रकार के नियंत्रण के बारे में? और आपको तर्कों के प्रकार का पता लगाने के लिए एक कार्यान्वयन की तलाश करनी होगी। केवल कार्यान्वयन बदलते समय, मैं इसके बारे में नहीं जान सकता हूं, जिससे अपरिभाषित व्यवहार हो जाएगा।
मुझे अभी भी सी से विरासत में मिले कोड के साथ काम करना है। यह सिर्फ बफर ओवरफ्लो और लीक का एक गुच्छा है। आप अक्सर गलती से आते हैं और हैरान होते हैं, और यह अब तक कैसे काम किया है? "C ++ कोड को बर्दाश्त नहीं करता है," सही है। लेकिन किसी कारण से, सी, इसके विपरीत, इसके लेखन में योगदान देता है। अधिक सटीक रूप से, किसी कारण से नहीं, कारण स्पष्ट हैं: कोई लिंक नहीं है (जो संकेत से अधिक सुरक्षित हैं), कोई प्रकार की सुरक्षा (ठोस
void * ) नहीं है ... बहुत सी चीजें हैं। और यह तथ्य कि केवल त्रुटियों में योगदान होता है: स्ट्रैकट, प्रिंटफ, मिलता है ... कोई आरएआईआई नहीं है, कोई कचरा संग्रह नहीं है, यहां से बहुत सारे लीक हैं। इन वर्षों में, मैंने C भाषा के विरुद्ध बड़ी संख्या में तर्क जमा किए हैं, और शायद ही कभी मैं इसका उपयोग करता हूं कि अब मुझे सब कुछ याद नहीं रहेगा।
लेकिन मैं C ++ में ड्राइवर और OS कर्नेल लिखने का सुझाव नहीं देता। बेशक, सी इसके लिए बेहतर है। छोटे पुस्तकालयों और उपयोगिताओं के लिए, सी शायद सी ++ से भी बेहतर विकल्प है। लेकिन साधारण किराए के प्रोग्रामर द्वारा विकसित एक मध्यम या बड़ी परियोजना के लिए, भाषा के रूप में सी चुनना शायद ही एक अच्छा विचार है। कोडांतरक में कम से कम सौ हजार लाइनों का अनुवाद करने की आवश्यकता किसे हो सकती है? और लाखों? यदि कोई इस विचार को पसंद करता है, तो सभी अधिक सी ++ सबसे अच्छा विकल्प है, इस कोडांतरक कोड के बहुत अधिक होंगे:
C ++ का C पर लाभ:
- महान सुरक्षा
- टेम्प्लेट का उपयोग करके जेनेरिक कोड लिखने की क्षमता
- एक वस्तु उन्मुख दृष्टिकोण का उपयोग करने की क्षमता
- RAII के साथ संसाधन प्रबंधन
- ओवरलोडिंग कार्यों और ऑपरेटरों द्वारा कोड सरलीकरण
- अपवादों के माध्यम से आसान त्रुटि से निपटने
- सी ++ 11!
- ...
यह केवल इन फायदों का सही उपयोग करने के लिए बनी हुई है। उदाहरण के लिए,
goto प्रतिस्थापन के रूप में अपवादों का उपयोग न करें, अल्पविराम ऑपरेटर को अधिभार न डालें, आदि।
नुकसान:
- लंबा संकलन
- बड़ा उत्पन्न मशीन कोड
एक लंबी संकलन केवल एक समस्या बन जाती है अगर हेडर फ़ाइलों को गलत तरीके से एक्सेस किया जाता है (जब उनके पास सब कुछ अनियंत्रित रूप से पॉप होता है) या पुस्तकालयों का उपयोग करते समय Boost :: Xpressive। उदाहरण के लिए, मेरी मशीन पर बड़ी क्यूटी परियोजना (2 साल पहले, 4 कोर, 8 जीबी रैम) सिर्फ 15 मिनट में पूरी तरह से बनाई गई है। खैर, मात्रा ... एक आवश्यक बलिदान।
क्या मैं जावा से नफरत करता हूँ।
मैंने ईमानदारी से जावा में लिखे कार्यक्रमों का उपयोग करने की कोशिश की। कई बार और कई सालों से। लेकिन व्यावहारिक रूप से उनमें से कोई भी सामान्य रूप से काम नहीं कर सकता था। उदाहरण के लिए, C ++ के लिए IDE के रूप में विंडोज संस्करण में 2008 मॉडल का प्रसिद्ध ग्रहण कार्यक्रम। Eclipse.exe का उपयोग करना शुरू नहीं हुआ। मुझे याद नहीं है कि गलती क्या थी, लेकिन मैंने काम करने से इनकार कर दिया। केवल तभी जब आप ग्रहण
c .exe का उपयोग करते हैं, जो कंसोल विंडो को छोड़ देता है, जो कि सहनीय है। लेकिन कुछ समय बाद, इस विधि ने भी काम करना बंद कर दिया। मैं मंचों में चढ़ गया, eclipse.ini फ़ाइल के लिए गुप्त क्रियाएं मिली और इसने काम किया! लेकिन लंबे समय तक नहीं। सबसे पहले, eclipse.exe लॉन्च ने काम करना बंद कर दिया, फिर ग्रहण
c .exe। फिर से मुझे इसे शुरू करने का रास्ता तलाशना पड़ा। यह पता चला कि स्टार्टअप पर कार्यक्षेत्र को तुरंत निर्दिष्ट करना उचित है। .Bat फ़ाइल बनाई। लेकिन यह लंबे समय के लिए पर्याप्त नहीं था। शायद समस्या यह थी कि परियोजना में कोड की कई मिलियन लाइनें थीं ... लेकिन मेरी राय में, इस तरह से व्यवहार करने का यह एक कारण नहीं है।
सबसे बुरी बात यह है कि सभी मामलों में, ग्रहण ने जावा में कॉल स्टैक को पॉप अप किया और बंद कर दिया। एक भी त्रुटि संदेश नहीं है। और इससे भी अधिक अप्रिय यह है कि जावा में लिखे गए लगभग सभी कार्यक्रमों ने ऐसा किया!
दूसरी लंबी कहानी AS2 सर्वर (
http://en.wikipedia.org/wiki/AS2 ) के साथ थी। यह Apache Tomcat के लिए एक एप्लिकेशन के रूप में था। तब मुझे अभी तक नहीं पता था कि जावा प्रोग्रामर लोगों को एक्सएमएल फाइलों के साथ कैसे परेशान करते हैं और इसे पूरी तरह स्वीकार्य प्रारूप मानते हैं। लेकिन मैं अब ऐसा नहीं सोचता, और मैं XML से उतना ही नफरत करता हूं जितना कि जावा। इसलिए, सर्वर को स्थापित करने के बाद, उसने शुरू करने से इनकार कर दिया और लॉग को सभी असंगत कॉल स्टैक लॉग करने के लिए लिखा। Java.policy और java.security को ठीक किया, आवश्यक फ़ाइलों के लिए देखा गया local_policy.jar और US_export_policy.jar, ने काम करना शुरू कर दिया। लेकिन हमेशा नहीं, समय-समय पर उन्होंने काम के बदले ढेर लिखना जारी रखा। नतीजतन, वे इस निष्कर्ष पर पहुंचे कि आपके सर्वर को लिखना आसान है। मैं इसे पहले करूंगा, बहुत समय बचाऊंगा।
जावा प्रोग्राम धीरे-धीरे चलते हैं और बहुत सारी मेमोरी का उपभोग करते हैं। सभी और निश्चित रूप से बहुमत नहीं है, लेकिन उनमें से कई जो मैंने परीक्षण किए हैं। उसी समय, मैं अजगर या माणिक में कार्यक्रमों का उपयोग करने का आनंद लेता हूं और किसी भी असुविधा को महसूस नहीं करता हूं। और अब
ओरेकल का
समझ से
बाहर व्यवहार ।
और सी ++ मुझे भी नफरत है
मैं एक ही समय में प्यार और नफरत करता हूं। सी। के रूप में एक लंबी विरासत के लिए एक लंबे संकलन के लिए। कई अस्पष्टताओं के लिए, जिनमें से सभी को सी से विरासत में नहीं मिला है। इस तथ्य के लिए कि सी ++ 11 की प्रतीक्षा करने में इतना समय लगा। राक्षसी डिजाइनों के लिए जिन्हें बनाना पड़ता है।
finality शब्द की कमी के लिए। आत्मनिरीक्षण की कमी के लिए। कई विरासत और अशुद्धियों की अनुपस्थिति के लिए। विभिन्न संकलक और OS में अंतर के लिए ... हां, उसके पास दोष हैं। वे हर जगह हैं। लेकिन मेरे क्षेत्र में, ज्यादातर मामलों में, सी ++ के लाभ पल्ला झुकना। और सबसे महत्वपूर्ण बात, यह बिल्कुल जावास्क्रिप्ट, रूबी, पायथन जैसी व्याख्या की गई भाषाओं के साथ संघर्ष नहीं करता है ... लेकिन यह उनके साथ काफी शांति से मिलता है।
मैं क्या प्यार करता हूँ?
GW-बेसिक। जीवन के लिए पहला प्यार है।