मैं डी क्यों चुनता हूं

शुरू करने के बजाय

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

यह भी ध्यान दिया जाना चाहिए कि डी: डी 1 और डी 2 के दो संस्करण हैं। D1 स्थिर है, इसके अपडेट केवल बग फिक्स को प्रभावित करते हैं, और D2 वर्तमान में नई सुविधाएँ जोड़ रहा है। चूंकि नई परियोजनाओं के लिए डी 2 की सिफारिश की गई है, यह वह होगा जो लेख में विचार किया जाएगा, जब तक कि अन्यथा संकेत न दिया जाए।

सामान्य रूप से प्रोग्रामिंग भाषाओं के दायरे में

तो चलिए शुरू करते हैं। सबसे पहले, मैं यह नोट करना चाहता हूं कि प्रोग्रामिंग भाषा का विकल्प मुख्य रूप से कार्यों की श्रेणी पर निर्भर करता है - सी / सी ++ / जावा / सी # सबसे अधिक संभावना है कि रिलेशनल डेटाबेस के लिए वेब पेज या एसक्यूएल के लिए जावास्क्रिप्ट को प्रतिस्थापित नहीं किया जा सकता है। यद्यपि यहां, शायद, आपको एक आरक्षण करने की आवश्यकता है: सिद्धांत रूप में, आप एक संकलक बना सकते हैं या उन कक्षाओं का एक पुस्तकालय लिख सकते हैं जो दिए गए नियमों के अनुसार, एक भाषा को दूसरे में बदल देंगे। इसलिए, उदाहरण के लिए, Microsoft ने ASP.NET प्लेटफॉर्म को विकसित करते समय - ब्राउज़र स्क्रिप्ट को .NET प्लेटफ़ॉर्म की किसी भी भाषा में लिखा जा सकता है (उदाहरण के लिए, C # में) और फिर स्वचालित रूप से संबंधित जावास्क्रिप्ट कोड में बदल दिया। हालाँकि, मैंने व्यक्तिगत रूप से केवल ब्राउज़र के लिए फ़ॉर्म सत्यापनकर्ता बनाने के अपेक्षाकृत सरल उदाहरणों के लिए इस कार्यक्षमता का परीक्षण किया है, इसलिए यह संभव है कि कुछ गैर-मानक मामले के लिए जावास्क्रिप्ट का उपयोग करना आवश्यक है। दूसरी ओर, सभी आधुनिक ब्राउज़रों के साथ परीक्षण किए गए स्वतंत्र रूप से वितरित पुस्तकालयों और रूपरेखाओं (उदाहरण के लिए, jQuery, MooTools, प्रोटोटाइप, आदि) की संख्या को देखते हुए, यह पहिया को फिर से स्थापित करने के लायक नहीं हो सकता है। और चूंकि हम विभिन्न तकनीकों के लिए भाषाओं की प्रयोज्यता के बारे में बात कर रहे हैं, उदाहरण के लिए, आप एक ऑपरेटिंग सिस्टम लिखने के लिए हास्केल कहते हैं, एक कार्यात्मक प्रोग्रामिंग भाषा चुन सकते हैं, लेकिन एक सिस्टम प्रोग्रामिंग भाषा के रूप में जावास्क्रिप्ट का चयन करना शायद अनुचित होगा। वैसे, हास्केल में एक ओएस पहले से ही लिखा गया है, जिसे हाउस कहा जाता है। खैर, SQL में एप्लिकेशन प्रोग्राम लिखना संभव नहीं है, क्योंकि इसमें ट्यूरिंग पूर्णता नहीं है। Transact-SQL में पहले से ही ऐसी पूर्णता है, लेकिन यह केवल Microsoft SQL Server और Sybase ASE के लिए समर्थित है, इसलिए यह भाषा एप्लिकेशन प्रोग्राम लिखने के लिए उपयुक्त नहीं है।

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

 भाज्य :: पूर्णांक -> पूर्णांक
  भाज्य ० = १
  भाज्य n |  n> 0 = n * भाज्य (n - 1)

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

 +++++++++++ [> ++++++++++++++++++++++++++++ <<<< -]> ++
  ।>। +। ++++++++ +++। ++ ++। << +++++++++++++++++++। ++ ++।
  ------.-------->> +>।

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

अंत में, आपकी अपनी पसंद भाषा की आपकी पसंद को प्रभावित कर सकती है। ठीक है, अगर अचानक पहले दो प्रतिबंध पर्याप्त नहीं हैं।

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

C # की खामियों के बारे में थोड़ा

चलिए शुरू करते हैं। एप्लिकेशन प्रोग्रामिंग के लिए भाषा के रूप में C # क्यों नहीं चुना, क्योंकि यह वही है जो इसके लिए है? मुख्य समस्या, जो मेरे लिए अत्यंत महत्वपूर्ण है, इंटरमीडिएट लैंग्वेज कॉमन इंटरमीडिएट लैंग्वेज (CIL) में संकलित है, जो विघटन को एक तुच्छ कार्य बनाती है। इसके अलावा, इसके लिए विशेष उपकरण हैं। उदाहरण के लिए, .NET परावर्तक चर, कार्यों और वर्गों के मूल नामों को सहेजने सहित त्रुटियों के बिना C # / VB.NET / F # स्रोत कोड उत्पन्न करता है। परिणामी स्रोत कोड टिप्पणियों की अनुपस्थिति को छोड़कर मूल एक से भिन्न होता है। जो लोग प्रयोग करना चाहते हैं, वे आधिकारिक साइट से कार्यक्रम का परीक्षण संस्करण डाउनलोड कर सकते हैं।

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

हालांकि, द्विआधारी कोड में संकलित करने के महत्व का सवाल आवेदन के क्षेत्र पर निर्भर करता है - यदि कार्यक्रम को विकास कंपनी के बाहर उपयोग करने की योजना नहीं है, तो, सबसे अधिक संभावना है, प्रोग्रामिंग भाषा का चयन करते समय विघटन का खतरा निर्णायक नहीं होगा। और एक रेखा खींचने के लिए, मैं जोड़ना चाहूंगा: Microsoft से C # संकलक के मानक पैकेज में प्रोग्राम को बाइनरी कोड में संकलित करने का एक उपकरण है, लेकिन CIL के लिए स्रोत कोड के बिना प्रोग्राम काम नहीं करेगा। इसलिए हैकिंग से बचाने के लिए इसका उपयोग करना असंभव है।

C # का उपयोग करने से पहले सोचने वाली दूसरी बात परिणामी कोड की पोर्टेबिलिटी है। मुझे ओक्लेट बोली दें: "मुझे लगता है कि Microsoft ने .Net तकनीक का नाम दिया है ताकि यह यूनिक्स निर्देशिका लिस्टिंग पर प्रकट न हो।" मुझे पता नहीं है कि लेखक सही है, लेकिन C # से WinAPI फ़ंक्शन, COM ऑब्जेक्ट और अन्य घटकों को कॉल करना बहुत आसान है जो प्रोग्राम को असहनीय बना देगा। यहां तक ​​कि विंडोज-विशिष्ट घटकों के उपयोग के बिना, कार्यक्रम खुद यूनिक्स सिस्टम पर नहीं चलेगा - मोनो को चलाने के लिए आवश्यक होगा। हां, बेशक, मोनो एक प्रसिद्ध उत्पाद है, लेकिन इसका उपयोग करते समय समस्याएं पैदा हो सकती हैं। ध्यान रखने वाली पहली बात यह है कि मोनो डेवलपर्स हमेशा Microsoft से एक कदम पीछे होंगे, क्योंकि वे पहले से जारी पुस्तकालयों और मानकों को लागू करना शुरू करते हैं। दूसरा: और वे गलती से नहीं थकते हैं? हां, मैं समझता हूं कि यह एक मुफ्त-लाइसेंस परियोजना है जो समुदाय को विकसित कर रही है, लेकिन अभी भी समर्थन समाप्त करने का जोखिम है। यह मौजूदा अनुप्रयोगों को प्रभावित नहीं करेगा, लेकिन नए पुस्तकालयों के लिए समर्थन की कमी के कारण नए कार्यक्रम असहनीय होने की संभावना है। याद रखने वाली तीसरी बात Microsoft के WinForms, ADO.NET और ASP.NET घटकों के मानकों की कमी है। उनका उपयोग Microsoft से कानूनी दावों को उलझा सकता है, इसलिए मोनो के साथ उनका उपयोग करने की अनुशंसा नहीं की जाती है। उत्तरार्द्ध का मतलब है कि उत्कृष्ट ASP.NET घटक, जो विभिन्न आकारों की साइटों के निर्माण के लिए उपयोग किया जाता है, एक ही PHP पर बिल्कुल कोई लाभ नहीं है। ठीक है, अगर अचानक आप अभी भी इसे अपनी परियोजनाओं में उपयोग करना चाहते हैं, तो विंडोज के सर्वर संस्करण के लिए लाइसेंस खरीदने के लिए मानसिक रूप से तैयार रहें।

और अंत में, तीसरी बात खुद से पूछना: क्या Microsoft इस भाषा को विकसित करना जारी रखेगा? वर्तमान में, सभी C # / CLI पेटेंट Microsoft के स्वामित्व में हैं, और इसका समर्थन करने में विफलता का मतलब इस भाषा की मृत्यु होगा। व्यक्तिगत रूप से, मेरा मानना ​​है कि C # विकसित होना जारी रहेगा - Microsoft ने इस भाषा में बहुत अधिक निवेश किया है। लेकिन कोई भी गारंटी नहीं दे सकता है: एक समय में माइक्रोसॉफ्ट ने विजुअल बेसिक का समर्थन करने से इनकार कर दिया, इसके बजाय एक पूरी तरह से नई भाषा, विजुअल बेसिक .NET का निर्माण किया, जो अपने पूर्ववर्ती के साथ पिछड़े संगतता के बिना था। नतीजतन, इससे बेसिक पर काम करने वाले हजारों प्रोग्रामरों के लिए त्रासदी हुई। इसके अलावा, प्रेस रिपोर्टों के अनुसार, 2015-2016 में, माइक्रोसॉफ्ट ने टैबलेट, स्मार्टफोन, कंप्यूटर, कंसोल, टीवी और अन्य उपकरणों के लिए एक नया ओएस बनाकर विंडोज ब्रांड को छोड़ने की योजना बनाई है, जिसका अर्थ है कि इस ओएस के लिए विकास के लिए भाषाएं विस्मरण में भी डूब सकता है।

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

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

C ++ की खामियों के बारे में थोड़ा

C ++ क्यों नहीं चुना? बेशक, यह उद्योग मानक है जिसके बारे में सभी ने सुना है। लेकिन वास्तव में, इस भाषा में कई महत्वपूर्ण कमियां हैं, जिनमें से कुछ पर मैं विचार करने की कोशिश करूंगा। पहली बात जो दिमाग में आती है वह यह है कि यह भाषा जटिल है। अधिक सटीक रूप से, यह बहुत जटिल है। इसकी तुलना में, C # पर काम करना बचकाना मज़ा जैसा लगने लगता है। खुद के लिए न्यायाधीश: अकेले सी पर मानक 500 पृष्ठों, सी ++ - 800, सी ++ 11 के बारे में - 1300 के बारे में लेता है। यदि आप तकनीकी दस्तावेज की मात्रा की तुलना करते हैं - तो यह भाषा मिक्सर, सिलाई मशीन और कार की तुलना में अधिक कठिन है, हवाई जहाज की तरह अधिक दृष्टिकोण। तुलना के लिए, C # 4.0 मानक केवल 505 पृष्ठ लेता है। इस बिंदु पर, मैं एलन कर्टिस का के एक उद्धरण को याद करना चाहता हूं: "मैंने 'ऑब्जेक्ट-ओरिएंटेड' की अवधारणा का आविष्कार किया, लेकिन मैं कह सकता हूं कि मेरा मतलब सी ++ से एक ही समय में नहीं था।" इसके विपरीत, आप, निश्चित रूप से, C ++ के निर्माता बजरने स्ट्रॉस्ट्रुप को याद कर सकते हैं: "केवल दो प्रकार की भाषाएं हैं: उन सभी के बारे में जो शिकायत करते हैं और जो कोई भी उपयोग नहीं करता है," लेकिन यह उद्धरण एक बहाने की तरह लगता है। इस अर्थ में डी एक काफी सुविधाजनक भाषा है - इसका डिज़ाइन मुख्य रूप से C # और जावा के आधार पर डिज़ाइन किया गया था। डी 1 स्पेसिफिकेशन का दायरा 223 पेज है। D2 के लिए विनिर्देश एक संकलक के साथ html- पृष्ठों के रूप में आता है, जो आधिकारिक वेबसाइट www.d-programming-language.org पर भी उपलब्ध है। इसके अलावा, आंद्रेई अलेक्जेंड्रेस्कु (द डी प्रोग्रामिंग लैंग्वेज) की एक पुस्तक है, जो वास्तव में डी 2 मानक (वॉल्यूम - 492 पृष्ठों, वर्तमान में रूसी में अनुवादित) का वर्णन है। तो, भाषा की जटिलता ही उस पर प्रोग्रामिंग की सुविधा नहीं देती है। डी में, सब कुछ सरल, होशियार और अधिक समझ में आता है।

सुरक्षा पहले

सी ++ की अगली बड़ी खामी त्रुटियों के लिए संकलन के दौरान एक खराब कोड जांच है। दूसरे शब्दों में, C ++ में कोड लिखना बहुत आसान है जिसे संकलित किया जाएगा लेकिन सही तरीके से काम नहीं करेगा। हमें एलीमेंट एलीमेन्ट ऑपरेटर [] (इंडेक्सिंग ऑपरेशन) प्राप्त करने के ऑपरेटर तक सीमित करते हुए, विशेषज्ञों को भाषा की ऐसी विवादास्पद विशेषताओं की पूरी सूची का संकलन छोड़ना चाहिए। यह तथ्य कि यह भाषा सरणी तत्वों की सीमाओं की जांच नहीं करती है, मुझे लगता है, किसी के लिए कोई रहस्य नहीं है। हालाँकि, इसके बावजूद, बफर ओवरफ्लो त्रुटियां थीं, सी और सी ++ कार्यक्रमों में दिखाई देंगी। यद्यपि प्रोग्रामर ये गलतियां करते हैं, मेरा मानना ​​है कि इसका कारण उस भाषा में ठीक है जो उनकी उपस्थिति में योगदान देता है। उदाहरण के लिए, C # हमेशा सरणी की सीमाओं से परे चेक बनाता है, जिससे ऐसी त्रुटियों की संभावना बहुत कम हो जाती है, लेकिन प्रदर्शन (बफर ओवरफ्लो अभी भी संभावित रूप से संकलक या मानक पुस्तकालयों के कार्यान्वयन में संभावित त्रुटियों के कारण संभव है)। एसटीएल पुस्तकालय कई समस्याओं को हल करता है, लेकिन यह केवल सही है अगर सही तरीके से उपयोग किया जाए। उदाहरण के लिए, वेक्टर टेम्प्लेट क्लास यह जांच नहीं करता है कि क्या यह इंडेक्सिंग ऑपरेशन (ऑपरेटर []) का उपयोग करते समय इसकी सीमा से परे है, सीमा की जांच करने के लिए, आपको फ़ंक्शन (H. M. Daytel, P.J. Daytel, "C ++ में प्रोग्राम कैसे करें") का उपयोग करने की आवश्यकता है। दूसरे शब्दों में, एसटीएल रामबाण नहीं है।

वास्तव में, बफर ओवरफ्लो त्रुटियां पहली नज़र में लगता है की तुलना में अधिक गंभीर समस्या है। 1988 में इंटरनेट को पंगु बनाने वाले प्रसिद्ध मॉरिस वर्म ने इस विशेष प्रकार की त्रुटि का उपयोग किया (क्षति का अनुमान $ 96 मिलियन है)। एक और उदाहरण: रिटर्न-ओरिएंटेड प्रोग्रामिंग तकनीक का उपयोग करते समय, सिस्टम के बाद के हैकिंग के लिए केवल 2-3 कोडांतरक निर्देशों को लागू करने के लिए पर्याप्त है। दूसरे शब्दों में, एक बाइट के एक बफर अतिप्रवाह भी एक भेद्यता हो सकती है। मुझे "सुरक्षित कोड" पुस्तक से सुरक्षा विशेषज्ञों माइकल हावर्ड और डेविड लेब्लांक के एक उद्धरण को उद्धृत करें: "Microsoft में कई सुरक्षा अभियानों के दौरान, हमने लगातार पहचान की वकालत की और, यदि आवश्यक हो, तो C या C ++ से C # या किसी अन्य प्रबंधित भाषा में लिखे गए खतरनाक घटकों को पोर्ट करना। । इसका मतलब यह नहीं है कि कोड स्वचालित रूप से सुरक्षित हो जाएगा, लेकिन कुछ हमले वर्गों - सबसे अधिक संभावना बफर अतिप्रवाह हमलों - शोषण करने के लिए और अधिक कठिन हो जाएगा। सर्वर पर DoS के हमलों के बारे में भी यही बात है, जो मेमोरी लीक और अन्य संसाधनों के कारण संभव है। " एक पल के लिए सोचें: यह सुझाव दिया जाता है कि आप धीमी, कम कार्यात्मक और आसानी से भाषा को जुदा करने के लिए उपयोग करते हैं क्योंकि एरे की सीमाओं और कचरा कलेक्टर की अंतर्निहित जाँच के कारण।

यहां आपको एक DoS हमले (सेवा की अस्वीकृति, सेवा की अस्वीकृति) और एक DDoS हमले (सेवा के वितरण से इनकार, वितरित सेवा से इनकार) के बीच अंतर पर जोर देने की आवश्यकता है। एक DoS हमला, एक नियम के रूप में, सेवा में "स्मार्ट" ट्रिक्स और कमजोरियों का उपयोग करता है और इसे कम संख्या में कंप्यूटर (संभवतः एक से भी) से बाहर किया जाता है। उदाहरण के लिए, जैसा कि ऊपर वर्णित है, एक DoS हमला एक मेमोरी रिसाव पर आधारित हो सकता है। एक अन्य उदाहरण एक फ़ाइल सर्वर पर हमला है, जिसमें सभी डाउनलोड की गई फ़ाइलों को वायरस के लिए जांचा जाता है।सबसे पहले, आकार में कई गीगाबाइट की एक फ़ाइल बनाई जाती है, जिसमें एक शून्य होता है, इसे संग्रहीत किया जाता है (संग्रह का आकार कई किलोबाइट है), इसे हमलावर सर्वर पर अपलोड किया जाता है, जिसके बाद सर्वर इसे अनपैक कर देता है और एंटीवायरस के साथ इसे जांचने की कोशिश करता है ... डीडीओएस हमला केवल ओवरलोड के कारण सेवा से इनकार करने का एक प्रयास है। इतने सारे अनुरोधों के साथ सेवा जिसके लिए यह स्पष्ट रूप से डिज़ाइन नहीं किया गया है। दूसरे शब्दों में, यह एक "हेड-ऑन" हमला है, बड़ी संख्या में वाहनों से तुरंत बाहर किया जाता है। इस तथ्य के बावजूद कि डीडीओएस हमलों से बचाव के कई तरीके हैं, ठीक से आयोजित डीडीओएस हमले से अपने आप को 100% सुरक्षित करना असंभव है, इसलिए सेवा का प्रदर्शन स्वयं ही अत्यंत महत्वपूर्ण हो जाता है: हम जितने अधिक अनुरोध कर सकते हैं, हमले के परिणाम उतने ही कम हो सकते हैं। परिणाम एक विरोधाभास है:C #, बेहतर संसाधन नियंत्रण के कारण, DoS हमले के संचालन को महत्वपूर्ण रूप से जटिल कर सकता है, लेकिन इसकी कम गति के कारण DDoS हमले के लिए सेवा को और अधिक असुरक्षित बनाता है।

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

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

C/C++ –

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

कचरा संग्रहण का विषय अधिक विस्तार से कवर किया जाना चाहिए। मैंने अक्सर वाक्यांश सुना है: "यदि कचरा संग्रह भाषा में जोड़ा गया था, तो इसने प्रदर्शन को खराब कर दिया।" मैं तुरंत इन लोगों से पूछना चाहता हूं: "क्या आपने परीक्षण किए हैं?" एक सिस्टम प्रोग्रामिंग भाषा होने के नाते, D मैनुअल मेमोरी मैनेजमेंट के उपयोग की अनुमति देता है (हालाँकि यह सुविधा अब SafeD सबसेट में शामिल नहीं है)। नए और हटाए गए ऑपरेटरों को लोड करना और सी-स्टाइल मेमोरी प्रबंधन फ़ंक्शन मॉलोक और मुफ्त आपके टूलकिट में दिखाई देंगे। इसके अलावा, एक नियम के रूप में, प्रदर्शन को केवल 10% कोड (मार्टिन फॉवलर की पुस्तक "रिफैक्टरिंग। मौजूदा कोड में सुधार करना") की सामग्री के आधार पर 90% तक बढ़ाया जा सकता है। दूसरे शब्दों में, अधिकांश कार्यक्रम निर्देशों का उपयोग करके लिखे जा सकते हैं जो संसाधनों के साथ सुरक्षित रूप से काम करते हैं,और गति के लिए महत्वपूर्ण एक छोटा टुकड़ा ध्यान से जाँच की जा सकती है। यह महसूस करना महत्वपूर्ण है कि उसी प्रोग्रामिंग भाषा का उपयोग किया जाता है, जो कोड के निर्माण, रखरखाव और रखरखाव को सरल करता है। इसके अलावा, बड़े कार्यक्रमों में, कचरा संग्रह विकास को गति देता है, क्योंकि C ++ प्रोग्रामर मेमोरी प्रबंधन पर बहुत समय (कुछ स्रोतों के अनुसार, 50% तक) खर्च करता है। तो यहां आपके लिए एक सिफारिश है: कोड लिखें, और प्रदर्शन के मुद्दों को प्रोफाइलर पर छोड़ दें, जो आपको कोड के एक टुकड़े की पहचान करने में मदद करेगा जो प्रदर्शन के मामले में समस्याग्रस्त है।चूंकि C ++ प्रोग्रामर मेमोरी मैनेजमेंट पर बहुत समय (कुछ स्रोतों के अनुसार 50% तक) खर्च करता है। तो यहां आपके लिए एक सिफारिश है: कोड लिखें, और प्रदर्शन के मुद्दों को प्रोफाइलर पर छोड़ दें, जो आपको कोड के एक टुकड़े की पहचान करने में मदद करेगा जो प्रदर्शन के मामले में समस्याग्रस्त है।चूंकि C ++ प्रोग्रामर मेमोरी मैनेजमेंट पर बहुत समय (कुछ स्रोतों के अनुसार 50% तक) खर्च करता है। तो यहां आपके लिए एक सिफारिश है: कोड लिखें, और प्रदर्शन के मुद्दों को प्रोफाइलर पर छोड़ दें, जो आपको कोड के एक टुकड़े की पहचान करने में मदद करेगा जो प्रदर्शन के मामले में समस्याग्रस्त है।

वहाँ भी एल्गोरिदम की एक संख्या है कि बस कचरा संग्रह के बिना सही ढंग से काम नहीं कर सकते हैं। मैं आपको एक सरल उदाहरण देता हूं: आपके पास एक अमूर्त वर्ग संख्या है, जो एक निश्चित संख्या का प्रतीक है, और इसके उपवर्ग हैं: पूर्णांक, दीर्घ, BigInt, फ्लोट, डबल, वास्तविक, जटिल, आदि। अब कल्पना कीजिए कि आपके कार्यक्रम में कहीं यह रेखा दिखाई देती है:

संख्या * c = a + b;

जहाँ a और b संख्या के सूचक हैं, अर्थात वास्तविक प्रकार के चर ज्ञात नहीं हैं। यह माना जाता है कि यदि ए और बी लॉन्ग हैं, तो परिणाम लॉन्ग या बिगआईंट (ओवरफ्लो त्रुटियों से बचने के लिए), यदि इंटीगर और कॉम्प्लेक्स, तो कॉम्प्लेक्स, यदि डबल और डबल है, तो इंटेगर, लॉन्ग, फ्लोट या डबल (निर्भर करता है) दशमलव स्थानों की प्राप्त संख्या से, उदाहरण के लिए 0.5 + 0.5 = 1), आदि। मुझे बताएं कि ऑपरेटर + (संख्या * a, संख्या * b) फ़ंक्शन को सही तरीके से कैसे लागू किया जाए? कार्यान्वयन का एक विस्तृत विश्लेषण इस लेख के दायरे से परे है, लेकिन हर कोई मल्टी-ट्रांसफर (और विशेष रूप से डबल ट्रांसफर) पर अध्यायों में जेफ अल्जीरिया की वास्तविक सी प्रोग्रामर्स के लिए सी ++ की कई विशेषताओं से खुद को परिचित कर सकता है। मैं सिर्फ यह नोट करना चाहता हूं कि ऑपरेटर + फ़ंक्शन को नए ऑपरेटर का उपयोग करके ढेर पर एक ऑब्जेक्ट बनाना होगा,चूंकि कोड जो इसे कहता है, वह वस्तु c के वास्तविक प्रकार के बारे में कुछ भी नहीं जान सकता है, और इसलिए स्टैक पर मेमोरी आवंटित नहीं कर सकता है। नतीजतन, हमें स्मृति को मुक्त करने के लिए एक कचरा संग्रह तंत्र की आवश्यकता है। इस मामले में, आप संदर्भ गिनती के साथ स्मार्ट पॉइंटर्स का उपयोग कर सकते हैं, लेकिन उनकी मौलिक सीमाएं हैं। दूसरे शब्दों में, कुछ भी अंतर्निहित कचरा संग्रह भाषा को प्रतिस्थापित नहीं कर सकता है, और यह तथ्य कि सी ++ 11 मानक केवल अपने मूल कार्यों का समर्थन करता है (उन्नत कचरा संग्रह का कार्यान्वयन मानक में शामिल नहीं है) मुझे बिल्कुल भी खुश नहीं करता है। अंत में, मैं फ्रांसिस बेकन के एक उद्धरण को याद करना चाहूंगा: "जो कोई भी नए साधनों का सहारा नहीं लेना चाहता है, वह अन्य परेशानियों से बचना चाहता है।" हां, अगर अचानक आप संख्या के साथ पिछले उदाहरण में रुचि रखते थे, तो मैं भी CLOS पर ध्यान देने की सलाह देता हूं - आम लिस्प ऑब्जेक्ट सिस्टम,जो पहले से ही कई शेड्यूलिंग के लिए अंतर्निहित समर्थन है।

विध्वंसक बनाम कचरा संग्रह

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

जैसा कि आप जानते हैं, C # और जावा ने इस मॉडल को छोड़ दिया, विनाशकर्ताओं की जगह, जो कि कचरा संग्रहण के बाद कहा जाता है, को नष्ट कर दिया। उत्तरार्द्ध, सिस्टम-मुक्त संसाधनों के लिए टर्मिनेटर का उपयोग करना असंभव बनाता है, क्योंकि एक टर्मिनेटर कॉल लंबे समय के बाद हो सकता है। इसलिए, आपको स्पष्ट रूप से संसाधनों को मुक्त करने की आवश्यकता है। “लेकिन जानकारी छिपाने के बारे में क्या? आखिरकार, मुझे अब याद रखना चाहिए कि किन वर्गों को संसाधनों के स्पष्ट रिलीज की आवश्यकता है, और जो नहीं करते हैं! यह यहां है कि त्रुटियां दिखाई देती हैं, "आप पूछते हैं, और आप सही होंगे। इसके जवाब में, यह केवल यह बताने और जवाब देने के लिए बना हुआ है कि यह C ++ में था और D. में है। हालांकि, एक प्रोग्राम के मामले में जो गलत तरीके से लिखा गया है, संसाधनों को जारी करना "यह ज्ञात नहीं है कि" अभी भी "कभी नहीं" से बेहतर है, इसलिए मॉडल के बीच एक अस्पष्ट विकल्प है C ++ और C # / Java में संसाधन प्रबंधन करना मुश्किल है।शायद इसीलिए C ++ और Java भक्तों के बीच इतनी बहस होती है।

C# , , , ( , ..). , FileStream, Stream , StreamWriter, (, , , ..) ( Stream, , FileStream, MemoryStream, NetworkStream ..). , (. , . , . , . , « - . »). , , ( .NET). : . , FileStream StreamWriter , . .NET ! , 50% FileStream , StreamWriter . StreamWriter, ? : , , , ( ). , , Microsoft : . , , FileStream StreamWriter… C++: « , ». : RAII , D .

एक निष्कर्ष के बजाय

दुर्भाग्य से, इस लेख में डी की कई विशेषताओं की समीक्षा करने के लिए पर्याप्त स्थान नहीं था। हालांकि, मैं उन्हें संक्षेप में सूचीबद्ध करना चाहूंगा, लेकिन फिर भी:

• बहु-थ्रेडेड प्रोग्राम बनाने के लिए एक कुशल मॉडल, सुरक्षा की दृष्टि से C ++ से काफी बेहतर है
• एक शक्तिशाली मेटाप्रोग्रामिंग सिस्टम जो गैर-तुच्छ टेम्पलेट्स के निर्माण को बहुत सरल करता है। यह नेमारल भाषा में मैक्रोज़ के साथ कार्यक्षमता में तुलनीय है (जिनका सी / सी ++ मैक्रोज़ से कोई लेना-देना नहीं है)।
• लगातार और अपरिवर्तनीय चर
• संकलन मंच पर संकलन
• कार्यात्मक भाषाओं की विशेषता लक्षण की उपस्थिति। विशेष रूप से, भाषा में शुद्ध कार्य, आलसी गणना, लंबदा, क्लोजर, उच्च-क्रम फ़ंक्शन आदि हैं।
• वर्ग विरासत और विधि को ओवरराइड करने पर रोक लगाने की क्षमता लगभग C # / Java में ही है
• , . , C++ C#, .
• unit-,
• «» , Ada, C# Java, C++11
• , , C++
• , NaN ( ) , C99, C++
• ( D )
• ,
• (, , C#)
• , «»
• ,
• और बहुत कुछ ...

?

• (Andrei Alexandrescu) «The D Programming Language»
• ( )
• « D»
• « D»
• , D
• डी समर्थन के साथ आईडीई और संपादकों की सूची । मैं मोनो-डी की सिफारिश कर सकता हूं, लेकिन आपको डी-आईडीई, पोसिडॉन और विज़ुअल डी पर भी ध्यान देना चाहिए।
• डी के लिए डीबगर्स की सूची (वास्तव में, सी ++ समर्थन के साथ कोई भी डिबगर करेगा)
• डी में लिखी गई ओपन सोर्स परियोजनाओं की सूची (अतिरिक्त पुस्तकालयों की संख्या भी वहां पाई जा सकती है)

आगे पढ़ रहे हैं

• स्टीव मैककोनेल, परफेक्ट कोड
• माइकल हॉवर्ड और डेविड लेब्लांक, सिक्योर कोड
• माइकल हॉवर्ड, डेविड लेब्लांक और जॉन विएगा, "19 डेडली सिंस थ्रेटनिंग सिक्योरिटी प्रोग्राम। कैसे ठेठ गलतियों को रोकने के लिए "
• ई। गामा, आर। हेल्म, आर। जॉनसन, डी। वलिसाइड्स, “ऑब्जेक्ट-ओरिएंटेड डिज़ाइन टेक्निक्स। डिजाइन पैटर्न
• मार्टिन फाउलर, रिफैक्टरिंग। मौजूदा कोड में सुधार »
• एचएम Daytel, P.J. Daytel, "C ++ में प्रोग्राम कैसे करें"
• जेफ अल्जीरिया, "रियल प्रोग्रामरों के लिए C ++"

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