C ++ D से बेहतर क्या करता है?

Question

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

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

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

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

D को कुछ बहुत ही कुशल C ++ प्रोग्रामर्स ( वाल्टर ब्राइट और आंद्रेई अलेक्जेंड्रेस्कु , डी समुदाय की मदद से) द्वारा डिज़ाइन किया गया था , जिसमें C ++ के कई मुद्दे तय किए गए थे, लेकिन क्या ऐसा कुछ था जो वास्तव में बेहतर नहीं हुआ? कुछ उसे याद किया? आपको लगता है कि कुछ बेहतर समाधान नहीं था?

इसके अलावा, ध्यान दें कि मैं डी 2.0 के बारे में बात कर रहा हूं , डी 1.0 के बारे में नहीं ।

Comments

मुझे यकीन है कि डी समुदाय इसे देखता है क्योंकि मुझे यकीन है कि डी देवों की तुलना में यहां कहीं अधिक सी ++ देव हैं। इस तरह आपके पास अधिक दिलचस्प या कम से कम विविध उत्तर होंगे।

— Klaim

इसके अलावा, D2 को वाल्टर ब्राइट द्वारा डिजाइन किया गया था, लेकिन अलेक्जेंड्रेस्कु के साथ भी। आप अपने प्रश्न में इसे ठीक करना चाह सकते हैं।

— Klaim

@ अस्वीकरण: डी और मानक पुस्तकालय में भी सामुदायिक भागीदारी का एक बहुत कुछ था (और अभी भी है)।

— मिशैल मिनिच

@Anto एक भाषा के रूप में, C ++ आपको बनाने में बहुत बेहतर है, प्रोग्रामर, आपके जीवन से नफरत करता है।

— अरलेन

@jokoon: असल में, हाँ, बहुत कम काम के साथ: digitalmars.com/d/2.0/interfaceToC.html

— Anto

Answer 1

C ++ की अधिकांश चीजें "D की तुलना में बेहतर हैं। मेटा चीजें हैं: C ++ में बेहतर कंपाइलर, बेहतर टूल, अधिक परिपक्व लाइब्रेरी, अधिक बाइंडिंग, अधिक विशेषज्ञ, अधिक ट्यूटोरियल आदि हैं। मूल रूप से इसमें बाहरी और बेहतर सभी चीजें हैं जो आप अधिक परिपक्व भाषा से उम्मीद करेंगे। यह अमानवीय है।

भाषा के लिए, कुछ चीजें हैं जो C ++ मेरी राय में D से बेहतर हैं। वहाँ शायद अधिक है, लेकिन यहाँ कुछ है कि मैं अपने सिर के ऊपर सूचीबद्ध कर सकते हैं:

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

एक और समस्या जिसने मुझे जकड़ लिया है, वह है लॉजिकल कॉस्ट (यानी mutableC ++ की तरह नहीं ) की कमी । यह थ्रेड-सुरक्षित कोड लिखने के लिए बहुत अच्छा है, लेकिन यह मुश्किल (असंभव?) बनाता है कांस्टेबल ऑब्जेक्ट्स के भीतर आलसी इंट्राइलेशन करने के लिए (एक कॉन्स्ट 'get' फंक्शन के बारे में जो पहले कॉल पर दिए गए वैल्यू का निर्माण और कैश करता है)।

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

ध्यान दें कि C ++ में कुछ प्रकार के सिस्टम मौसा (जैसे कि गैर-संवेदी कास्ट, iteratorसाथ ही आवश्यकता होती है const_iterator) है जो इसे काफी बदसूरत बनाते हैं, लेकिन जबकि C ++ का प्रकार सिस्टम भागों में थोड़ा गलत है, यह आपको डी की तरह काम करने से नहीं रोकता है कभी-कभी करता है।

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

डी कभी-कभी थोड़ा सुविधाजनक होता है
एक आलोचना जिसे आप अक्सर सी ++ के बारे में सुनते हैं वह यह है कि यह आपसे कुछ निम्न-स्तर के मुद्दों को छुपाता है जैसे कि सरल असाइनमेंट जैसे a = b;कई काम कर सकते हैं जैसे कि रूपांतरण ऑपरेटर को कॉल करना, अधिभार असाइनमेंट ऑपरेटर को कॉल करना, आदि। कोड से देखना मुश्किल है। कुछ लोगों को यह पसंद है, कुछ लोगों को नहीं। किसी भी तरह से, डी में यह है भी बदतर (बेहतर?) जैसी चीजों की वजह से opDispatch, @property, opApply, lazyजो संभावित चीजें हैं जो आप की उम्मीद नहीं है में मासूम की तलाश में कोड बदलना होगा।

मुझे नहीं लगता कि यह व्यक्तिगत रूप से एक बड़ा मुद्दा है, लेकिन कुछ लोग इसे बंद कर सकते हैं।

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

D आवंटित स्मृति में Naive array परिभाषा
यह मेरा एक पालतू जानवर है:

int[3] a = [1, 2, 3]; // in D, this allocates then copies
int a[3] = {1, 2, 3}; // in C++, this doesn't allocate

जाहिर है, डी में आवंटन से बचने के लिए, आपको करना चाहिए:

static const int[3] staticA = [1, 2, 3]; // in data segment
int[3] a = staticA; // non-allocating copy

ये छोटे 'आपकी पीठ के पीछे' आवंटन मेरे पिछले दो बिंदुओं के अच्छे उदाहरण हैं।

संपादित करें: ध्यान दें कि यह एक ज्ञात समस्या है जिस पर काम किया जा रहा है।
संपादित करें: यह अब ठीक हो गया है। कोई आवंटन नहीं होता है।

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

Comments

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

— स्टीव 314

आप निम्न-स्तरीय कोड के लिए जीसी को अभी भी अक्षम कर सकते हैं - पीटर कह रहे हैं कि वर्तमान में भाषा इस पर बहुत कुछ निर्भर करती है। इसके अलावा, आप GC को अपने API: GC.addRange से core.memory का उपयोग करके प्रबंधित प्रबंधित ढेर के बाहर की सीमाओं को बताने के लिए कह सकते हैं ।

— व्लादिमीर पैंटेलेव

+1 इंगित करने के लिए कि डी मानक पुस्तकालय कचरा एकत्र किया गया है और यह कि जीसी-ऑफ कोड एक सहज इंटरोप नहीं है। यह कुछ ऐसा नहीं है जिसके बारे में मैंने सोचा है, लेकिन यह काबू पाने के लिए एक बड़ी बाधा की तरह लगता है।

— मस्कॉन्ग

Answer 2

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

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

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

इस सब को ध्यान में रखते हुए, मैं कुछ चीजों की गणना करूंगा, जो मैं सोच सकता हूं, और प्रत्येक के लिए मैं बताऊंगा कि डी की पसंद कुछ अन्य, उच्च-स्तरीय, चार्टर को पूरा करने की इच्छा से कैसे प्राप्त होती है।

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

2. D अस्पष्ट-लिंग प्रकारों को अस्वीकार करता है (यह तय नहीं कर सकता कि वे मूल्य या संदर्भ प्रकार हैं)। इस तरह के डिजाइनों को सर्वसम्मति से सी ++ में बंद कर दिया जाता है और लगभग हमेशा गलत होता है, लेकिन उनमें से कुछ तकनीकी रूप से सही हैं। हमने यह चुनाव इसलिए किया क्योंकि यह ज्यादातर गलत कोड और केवल एक छोटे से अंश सही कोड को नापसंद करता है जिसे फिर से डिज़ाइन किया जा सकता है। हमारा मानना ​​है कि यह एक अच्छा व्यापार है।

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

4. D में आप उदाहरण के लिए int नहीं फेंक सकते। आपको थ्रोबेबल विरासत में मिली वस्तु फेंकनी चाहिए। कोई भी स्थिति डी में बेहतर नहीं है, लेकिन, यह एक बात है कि C ++ ऐसा कर सकता है जो D नहीं कर सकता।

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

एक या दो छोटी चीजें हो सकती हैं, लेकिन कुल मिलाकर यह होना चाहिए।

Comments

@DeadMG: इसके लिए C ++ में काम करने के लिए, जिस ऑब्जेक्ट को ले जाया जा रहा है, उसे इंगित करने वाले ऑब्जेक्ट को बैक पॉइंटर की आवश्यकता होगी (ताकि यह कॉपी निर्माण के दौरान अपडेट हो सके)। अगर ऐसा है, तो D में आप पॉइंटर का उपयोग कर सकते हैं, वैसे भी पॉइंटर को अपडेट करने के लिए। कृपया डी के खिलाफ बहस न करें यदि आपके पास केवल इसका ज्ञान है।

— पीटर अलेक्जेंडर

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

— 17-16 बजे डेडएमजी जूल

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

— आंद्रेई अलेक्जेंड्रेस्कु

@quant_dev: आपको यह सुनकर खुशी होगी कि GSASC प्रोजेक्ट पहले से ही एक अच्छे आकार में है, जो BLAS के उच्च प्रदर्शन रैखिक बीजगणित पर केंद्रित है। यह परीक्षण और बेंचमार्किंग उद्देश्यों के लिए उपयुक्त आदिम का "भोला" कार्यान्वयन प्रदान करता है। आपके दूसरे प्रश्न का उत्तर देने के लिए, जावा संख्यात्मक पुस्तकालयों की तुलना करने के लिए बार को बहुत कम निर्धारित करता है। यह हमेशा उच्च-प्रदर्शन बीजीय कामों तक पहुँचने के लिए एक जेएनआई बाधा पर जाने की परेशानी होगी, और सिंटैक्स खराब होगा क्योंकि जावा में ऑपरेटर ओवरलोडिंग का अभाव है।

— आंद्रेई अलेक्जेंड्रेस्कु

@PeterAlexander: डेडएमजी बिंदु पर सही है। "आपको टाइपर्स को मान प्रकारों का उपयोग नहीं करना चाहिए" इस तथ्य से स्पष्ट रूप से अनभिज्ञ है कि किसी भी भाषा में पॉइंटर्स आमतौर पर मूल्य प्रकारों के साथ उपयोग किए जाते हैं (क्या आप वास्तव में एक के Object*रूप में व्यापक रूप से उपयोग किए जाने की उम्मीद करते हैं int*?) और डी पूरी तरह से अनदेखा कर रहे हैं? प्रदर्शन जुर्माना, या यह दावा करना मौजूद नहीं है। यह स्पष्ट रूप से गलत है - कैश मिस कई मामलों में काफी ध्यान देने योग्य है, इसलिए सी ++ में हमेशा डी पर लचीलेपन का लाभ होगा

— मेहरदाद

Answer 3

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

वास्तव में, मुझे वास्तव में अपने मस्तिष्क को उन कारणों के साथ पोंछना होगा, जिनकी वजह से C ++, एक भाषा के रूप में, डी से बेहतर है। आम तौर पर जो दिमाग में आता है वह व्यापार की बात है।

1. चूँकि डी की गति सकर्मक है, और क्योंकि भाषा अपरिवर्तनीय है , इसलिए इसकी C ++ की तुलना में कहीं अधिक मजबूत गारंटी है const, जिसका अर्थ है कि D नहीं है और नहीं हो सकता है mutable। इसका तार्किक आधार नहीं हो सकता । तो, आपको डी के कास्ट सिस्टम के साथ एक बहुत बड़ा लाभ मिलता है, लेकिन कुछ स्थितियों में, आप सिर्फ उसी constतरह का उपयोग नहीं कर सकते जैसे आपके पास सी ++ में होगा।

2. D के पास केवल एक कास्ट ऑपरेटर है, जबकि C ++ में 4 (5 यदि आप C कास्ट ऑपरेटर की गिनती करते हैं)। यह सामान्य मामले में डी में कलाकारों के साथ काम करना आसान बनाता है, लेकिन समस्याग्रस्त है जब आप वास्तव में अतिरिक्त जटिलताओं / लाभ चाहते हैं जो कि const_castऔर इसके भाइयों को प्रदान करते हैं। लेकिन D वास्तव में इतना शक्तिशाली है कि आप C ++ की कास्ट को लागू करने के लिए टेम्प्लेट का उपयोग कर सकते हैं, इसलिए यदि आप वास्तव में उन्हें चाहते हैं, तो आप उनके पास हो सकते हैं (और वे किसी बिंदु पर D के मानक पुस्तकालय में समाप्त भी हो सकते हैं)।

3. D में C ++ की तुलना में बहुत कम निहित जातियां हैं और यह घोषित करने की संभावना अधिक है कि दो कार्य एक-दूसरे के साथ संघर्ष में हैं (आपको मजबूर करने के लिए और अधिक विशिष्ट होने के लिए कि आपके कौन से कार्य हैं - या तो जाति के साथ या पूर्ण मॉड्यूल पथ देकर )। कभी-कभी, यह कष्टप्रद हो सकता है, लेकिन यह सभी प्रकार के समारोह अपहरण मुद्दों को रोकता है । आप जानते हैं कि आप वास्तव में उस फ़ंक्शन को कॉल कर रहे हैं जिसका आप मतलब है।

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

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

6. C # के समान, D संरचना और वर्गों को अलग करता है । कक्षाएं संदर्भ प्रकार हैं जिनके पास वंशानुक्रम है और वे व्युत्पन्न हैं Object, जबकि संरचनाएं विरासत के बिना मूल्य प्रकार हैं। यह अलगाव अच्छा और बुरा दोनों हो सकता है। यह C ++ में क्लासिक स्लाइसिंग समस्या से छुटकारा दिलाता है और यह अलग-अलग प्रकारों में मदद करता है जो वास्तव में उन प्रकार के मूल्य हैं, जिन्हें पॉलिमॉर्फिक माना जाता है, लेकिन सबसे पहले, कम से कम, अंतर C ++ प्रोग्रामर के लिए कष्टप्रद हो सकता है। अंततः, इसके कई लाभ हैं, लेकिन यह आपको अपने प्रकारों से कुछ अलग तरीके से निपटने के लिए मजबूर करता है।

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

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

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

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

1. डी में सशर्त संकलन है । यह उन विशेषताओं में से एक है जो मुझे अक्सर याद आती है जब मैं C ++ में प्रोग्रामिंग कर रहा होता हूं। यदि C ++ इसे जोड़ देगा, तो C ++ लेप्स और सीमा में सुधार करेगा जब यह टेम्प्लेट की तरह सामान में आएगा।

2. डी में संकलन-समय प्रतिबिंब है ।

3. चर डिफ़ॉल्ट रूप से थ्रेड-स्थानीय होते हैं, लेकिन हो सकता है sharedकि आप उन्हें चाहते हैं। इस धागे के साथ काम करता है अब तक सी ++ की तुलना में क्लीनर। आप पूर्ण नियंत्रण में हैं। आप थ्रेड्स के बीच संवाद करने के लिए पासिंगimmutable और मैसेज का उपयोग कर सकते हैं , या आप वेरिएबल बना सकते हैं sharedऔर इसे म्यूटेक्स और कंडीशन वेरिएबल्स के साथ C ++ कर सकते हैं । यहां तक ​​कि C ++ में सिंक्रोनाइज़ेशन (C # और Java के समान) के साथ सुधार हुआ है । इसलिए, D की थ्रेडिंग स्थिति C ++ की तुलना में कहीं बेहतर है।

4. D के टेम्प्लेट C ++ के टेम्प्लेट की तुलना में कहीं अधिक शक्तिशाली हैं, जिससे आप कहीं अधिक, कहीं अधिक आसानी से कर सकते हैं। और टेम्पलेट की कमी के अलावा, त्रुटि संदेश वैसे ही बेहतर हैं जैसे वे C ++ में हैं। डी टेम्पलेट्स को बहुत शक्तिशाली और प्रयोग करने योग्य बनाता है। यह कोई संयोग नहीं है कि आधुनिक सी ++ डिजाइन के लेखक डी के मुख्य सहयोगियों में से एक है। मुझे लगता है कि C ++ टेम्पलेट्स में D टेम्पलेट्स की तुलना में गंभीरता से कमी है, और C ++ में प्रोग्रामिंग करते समय यह बहुत निराशाजनक हो सकता है।

5. डी में अंतर्निहित अनुबंध प्रोग्रामिंग है ।

6. डी में एक अंतर्निहित इकाई परीक्षण रूपरेखा है।

7. D ने यूटीकोड के साथ string(UTF-8), wstring(UTF-16) और dstring(UTF-32) के लिए बिल्ट-इन सपोर्ट दिया है । यह यूनिकोड से निपटना आसान बनाता है। और अगर आप सिर्फ stringयूनिकोड के बारे में चिंता करना चाहते हैं और आम तौर पर उपयोग नहीं करना चाहते हैं, तो आप कर सकते हैं - हालांकि यूनिकोड की मूल बातों के बारे में कुछ समझ मानक पुस्तकालय कार्यों में से कुछ के साथ मदद करता है।

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

9. D की सरणियाँ C ++ के सरणियों से बहुत बेहतर हैं। न केवल वे लंबाई के साथ एक उचित प्रकार हैं, बल्कि उन्हें आकार और आकार में जोड़ा जा सकता है। उन्हें समेटना आसान है। और सबसे अच्छी बात यह है कि उनके पास टुकड़ा करने की क्रिया है । और यह कुशल सरणी प्रसंस्करण के लिए एक बड़ा वरदान है। स्ट्रिंग्स डी में वर्णों के सरणियाँ हैं, और यह कोई समस्या नहीं है (वास्तव में यह बहुत अच्छा है!), क्योंकि डी के सरणियाँ बहुत शक्तिशाली हैं।

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

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

इसलिए, मुझे लगता है कि इस सवाल का संक्षिप्त जवाब "बहुत कम है।" डी, एक भाषा के रूप में, आमतौर पर C ++ से बेहतर है।

Comments

कचरा संग्रह भाषाओं में गैर GC langs (YT पर अलेक्जेंड्रेस्कु की बात के अनुसार) की तुलना में 2-5x अधिक मेमोरी का उपयोग किया जाता है ताकि निश्चित रूप से एक समस्या है अगर वह (मेम उपयोग) अड़चन है।

— NoSenseEtAl

Answer 4

RAII और स्टैक मेमोरी उपयोग

डी 2.0 RAII को स्टैक पर होने की अनुमति नहीं देता है क्योंकि इसने scopeस्टैक पर वर्ग उदाहरणों को आवंटित करने में कीवर्ड के मूल्य को हटा दिया है ।

आप डी में मूल्य-प्रकार की विरासत नहीं कर सकते हैं, इसलिए प्रभावी रूप से आपको RAII के किसी भी रूप के लिए ढेर आवंटन करने के लिए मजबूर किया जाता है।
यही है, जब तक आप उपयोग नहीं करते हैं emplace, लेकिन यह उपयोग करने के लिए बहुत दर्दनाक है, क्योंकि आपको हाथ से मेमोरी आवंटित करना है। (मुझे अभी इसका emplaceडी में उपयोग करना व्यावहारिक है )

Answer 5

C ++ आपको क्रियात्मक होने के लिए मजबूर करने में बहुत बेहतर है। यह आपकी नज़र में बेहतर या बदतर हो सकता है, यह इस बात पर निर्भर करता है कि आप अनुमान या क्रियाशीलता पसंद करते हैं।

C ++ में रन-टाइम संस्मरण की तुलना करें :

template <typename ReturnType, typename... Args>
function<ReturnType (Args...)> memoize(function<ReturnType (Args...)> func)
{
    map<tuple<Args...>, ReturnType> cache;
    return ([=](Args... args) mutable {
            tuple<Args...> t(args...);
            return cache.find(t) == cache.end()
                ? cache[t] : cache[t] = func(args...);
    });
}

डी में एक ही बात के साथ:

auto memoize(F)(F func)
{
    alias ParameterTypeTuple!F Args;
    ReturnType!F[Tuple!Args] cache;
    return (Args args)
    {
        auto key = tuple(args);
        return key in cache ? cache[key] : (cache[key] = func(args));
    };
}

सूचना, उदाहरण के लिए, के साथ अतिरिक्त शब्दाडंबर template <typename ReturnType, typename... Args>बनाम (F), Args...बनाम Args, args...बनाम args, आदि
बेहतर या बदतर के लिए, सी ++ अधिक वर्बोज़ है।

बेशक, आप डी में भी ऐसा कर सकते हैं:

template memoize(Return, Args...)
{
    Return delegate(Args) memoize(Return delegate(Args) func)
    {
        Return[Tuple!Args] cache;
        return delegate(Args args)
        {
            auto key = tuple(args);
            return key in cache ? cache[key] : (cache[key] = func(args));
        };
    }
}

और वे लगभग समान दिखेंगे, लेकिन तब इसके लिए एक की आवश्यकता होगी delegate, जबकि मूल ने किसी भी कॉल करने योग्य वस्तु को स्वीकार किया था । (C ++ 0x संस्करण के लिए एकstd::function ऑब्जेक्ट की आवश्यकता होती है , इसलिए किसी भी तरह से, यह अधिक इनपुट है और इसके इनपुट में प्रतिबंधात्मक है ... जो कि अच्छा है अगर आप वर्बोसिटी पसंद करते हैं, तो बुरा अगर आप नहीं करते हैं।)

Answer 6

मुझे D के बारे में अधिक जानकारी नहीं है, लेकिन बहुत से, कई C ++ प्रोग्रामर जिन्हें मैं जानता हूं, वे इसे नापसंद करते हैं, और मुझे व्यक्तिगत रूप से सहमत होना होगा- मुझे D का लुक पसंद नहीं है और मैं एक करीब नहीं जाऊंगा।

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

यहाँ कुछ चीजें हैं जो मैंने देखा है जब थोड़ा शोध करते हैं और कुछ ऐसे लोगों से बात करते हैं जिन्होंने इसे आज़माया है:

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

मैंने कार्यों और प्रतिनिधियों के साथ समस्याओं के बारे में सुना है। जाहिर है, डी के पास रन-टाइम कॉल करने योग्य फ़ंक्शन प्रकारों के रूप में कार्य और प्रतिनिधि दोनों हैं, और वे समान नहीं हैं, लेकिन वे विनिमेय हैं या ... कुछ? मेरे मित्र को उनसे कुछ समस्याएँ थीं। यह निश्चित रूप से C ++ से डाउनग्रेड है, जो अभी-अभी हुआ है std::functionऔर आप कर रहे हैं।

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

फिर, कुछ और बातें हैं। उदाहरण के लिए, सिर्फ विकिपीडिया प्रविष्टि पढ़ें।

import std.metastrings;
pragma(msg, Format!("7! = %s", fact_7));
pragma(msg, Format!("9! = %s", fact_9));

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

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

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

स्कॉट मेयर्स लिखते हैं:

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

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

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

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

मौलिक रूप से, यह इतना नहीं पेश करता है कि C ++ प्रोग्रामर पहले से ही ऐसा नहीं कर सकता है। शायद डी में एक फैक्टरियल मेटाप्रोग्राम लिखना आसान है, लेकिन हम पहले से ही सी + + में फैक्टरियल मेटाप्रोग्राम लिख सकते हैं । हो सकता है कि D में आप कंपाइल-टाइम रे-ट्रेसर लिख सकते हैं , लेकिन वास्तव में कोई भी ऐसा नहीं करना चाहता है। सी ++ दर्शन के मौलिक उल्लंघनों की तुलना में, आप डी में क्या कर सकते हैं, विशेष रूप से उल्लेखनीय नहीं है।

यहां तक ​​कि अगर इन चीजों को सतह पर केवल समस्याएं हैं, तो मुझे पूरा यकीन है कि सतह पर डी वास्तव में सी ++ की तरह नहीं दिखता है, शायद यह एक अच्छा कारण है कि कई सी ++ प्रोग्रामर डी की ओर पलायन नहीं कर रहे हैं। शायद डी को खुद ही एक बेहतर विज्ञापन देने की जरूरत है।

Comments

@ डेडएमजी: यह 100% गलत है और यहstd::function कहने की बात याद नहीं आ रही है कि यह निश्चित रूप से सी ++ से डाउनग्रेड है, जो अभी-अभी हुआ है और आपने किया है। क्यों? क्योंकि आप भी, उदाहरण के लिए, फंक्शन पॉइंटर्स हैं। यह D: D के "फ़ंक्शन" फ़ंक्शन पॉइंटर्स के बिल्कुल समान है, और D के "डेलिगेट्स" C ++ के समान हैं std::function(सिवाय इसके कि वे अंतर्निहित हैं)। कहीं भी कोई "डाउनग्रेड" नहीं है - और उनके बीच एक 1: 1 पत्राचार है, इसलिए यदि आप C ++ से परिचित हैं तो यह बिल्कुल भी भ्रमित नहीं होना चाहिए।

— मेहरदाद

@ मर्क ट्रैप: मुझे यह स्वीकार करना चाहिए कि मैं इस विषय पर आपके रुख को नहीं समझता - टिप्पणियों का उपयोग नहीं किया जाना चाहिए, आप जानते हैं, एक उत्तर पर टिप्पणी करना?

— klickverbot

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

— klickverbot

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

— डब्ल्यू पर जस्टिन डब्ल्यू

@ मर्क: उनके बारे में जो भी मौजूदा नीति है, मैं उसे बेवकूफ समझता हूं और टिप्पणी चर्चा को हटाता हूं । मुझे लगता है कि इस उत्तर में व्यापक विचार-विमर्श हुआ था (जो अब मुझे दिलचस्पी है), लेकिन मुझे यकीन नहीं है, और मुझे पता लगाने का कोई तरीका नहीं है। वह कमरा जो आपने 10k संदेशों से अच्छी तरह से जोड़ा है, और मुझे इस बात की कोई संभावना नहीं है कि मैं एक चर्चा पा सकता हूं जो मुझे लगता है कि याद रखा गया था, लेकिन इसकी सामग्री को याद नहीं कर सकता। इस उत्तर के बारे में चर्चाएँ यहाँ हैं, इस उत्तर के बारे में , न कि कुछ चैट रूम में, जहाँ वे सेक्स, ड्रग्स और रॉक'न'रोल की चर्चाओं में घुलमिल सकते हैं।

— sbi

Answer 7

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

डी संस्करण:

class A { int i; }

int foo(A a) {
    return a.i; // Will crash if a is null
}

int main() {
    A bar = null;
    // Do something, forgetting to set bar in all
    // branches until finally ending up at:
    return foo(bar);
}

C ++ संस्करण:

class A { int i; };

int foo(A& a) {
    return a.i; // Will probably not crash since
                // C++ references are less likely
                // to be null.
}

int main() {
    A* bar = null;
    // Do something, forgetting to set bar in all
    // branches until finally ending up at:
    // Hm.. I have to dereference the bar-pointer
    // here, otherwise it wont compile.  Lets add
    // a check for null before.
    if (bar)
        return foo(*bar);
    return 0;
}

निष्पक्ष होने के लिए आप Aडी में बनाकर सी-++ के बहुत करीब पहुंच सकते हैं structऔर foo()-गर्गमेंट को एक के रूप में चिह्नित refकर सकते हैं (कक्षाएं संदर्भ प्रकार हैं और संरचना डी में मूल्य प्रकार हैं, सी # के समान)।

मेरा मानना ​​है कि NonNullableकक्षाओं के लिए खाका बनाने की योजना है क्योंकि डी मानक पुस्तकालय निर्माण के बजाय। यहां तक ​​कि मैं केवल Type&की तुलना में संक्षिप्तता पसंद करता हूं NonNullable(Type), और डिफ़ॉल्ट के रूप में गैर-अशक्त पसंद करेंगे (कुछ की तरह प्रतिपादन Typeऔर Nullable(Type))। लेकिन यह बहुत देर हो चुकी है कि डी को बदलने के लिए और मैं अब ऑफ-टॉपिक को स्थानांतरित कर रहा हूं।

Comments

डी में फ़ंक्शन फ़ंक्शन और रिटर्न मान दोनों refको आपको C ++ के रूप में एक ही प्रभाव देने के लिए चिह्नित किया जा सकता है &। एक प्रमुख अंतर यह है कि refभले ही यह एक अस्थायी नहीं होगा const।

— जोनाथन एम डेविस

मुझे जिस तरह से डी में स्थानीय चर का संदर्भ देने की मनाही है, मुझे पसंद है, मुझे तब तक इस बात की जानकारी नहीं थी कि जब तक मैं आपकी टिप्पणी नहीं पढ़ता। लेकिन आप इसके बारे में बिना सोचे-समझे एक गैर-स्थानीय अशक्त संदर्भ वापस कर सकते हैं, जहाँ C dereference संचालक आपको विचार देगा।

— २०:०५ पर लुमोर

आप भ्रमित कर रहे हैं। कक्षाएं हमेशा संदर्भ होती हैं, और यह रेफ से अलग होती है। D में संदर्भ जावा में संदर्भ की तरह हैं। वे पॉइंटर्स प्रबंधित कर रहे हैं। रेफ से गुजरना या लौटना C ++ में गुजरने या साथ लौटने जैसा है। रेफरी द्वारा एक क्लास रेफरेंस पास करना C ++ में पॉइंटर को पास करने जैसा है (& A * &)। स्टैक पर कक्षाएं नहीं चलतीं। हां, NonNullable से ऐसा क्लास रेफरेंस संभव होगा जो गैर-शून्य होने की गारंटी हो, लेकिन यह रेफ से पूरी तरह अलग हो। सी ++ कोड में आप जो करने की कोशिश कर रहे हैं वह डी में काम नहीं करता है क्योंकि कक्षाएं स्टैक पर नहीं जाती हैं। संरचनाएं करते हैं।

— जोनाथन एम डेविस

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

— जोनाथन एम डेविस

C ++ संदर्भ भाषा मानक के अनुसार शून्य नहीं हो सकता (यह कहते हुए कि "शायद अशक्त नहीं होगा" गलत है क्योंकि यह शून्य नहीं हो सकता)। मैं चाहता हूं कि एक वर्ग के लिए वैध मूल्य के रूप में अशक्त को खारिज करने का एक तरीका था।

— jsternberg

Answer 8

सबसे महत्वपूर्ण बात यह है कि सी ++ "डी की तुलना में बेहतर करता है" विरासत पुस्तकालयों के साथ हस्तक्षेप कर रहा है । विभिन्न 3 डी इंजन, ओपनसीएल और एक जैसे। जैसा कि डी नया है, इसमें चुनने के लिए अलग-अलग पुस्तकालयों की मात्रा कम है।

C ++ और D के बीच एक और महत्वपूर्ण अंतर यह है कि C ++ में कई वित्तीय रूप से स्वतंत्र विक्रेता हैं, लेकिन 2014 तक D का व्यावहारिक रूप से केवल एक है , 2-मैन टीम जिसने इसे बनाया था। यह दिलचस्प है कि "दूसरा स्रोत सिद्धांत" कहता है कि परियोजनाओं को कभी भी प्रौद्योगिकी, घटकों पर निर्भर नहीं होना चाहिए, जिनके पास केवल एक, एकल, विक्रेता है, सॉफ्टवेयर के लिए भी पकड़ है।

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

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

ओरेकल ने ईसी को जावा एसई 7 विनिर्देश अनुरोध और लाइसेंस के साथ प्रदान किया जो कि स्व-विरोधाभासी हैं, विशेष रूप से कल्पना के स्वतंत्र कार्यान्वयन के वितरण को प्रतिबंधित करते हैं, और सबसे महत्वपूर्ण बात, कल्पना के स्वतंत्र स्रोत के वितरण को रोकते हैं।

एक ऐतिहासिक नोट के रूप में, यह कहा जा सकता है कि HTML5 WebGL के विकसित होने से पहले जावा एप्लेट्स में 3 डी कैनवस के हार्डवेयर में तेजी थी। जावा एप्लेट्स स्टार्ट-अप स्पीड इश्यू को हल किया जा सकता था, अगर जावा एक सामुदायिक परियोजना होती, लेकिन जावा के एकमात्र फाइनेंसर, सन माइक्रोसिस्टम्स के अधिकारियों ने जावा कार्यान्वयन को ठीक करने के लिए इसे महत्वपूर्ण नहीं पाया। अंतिम परिणाम: जावा GUI चौखटे (स्विंग, आदि) के "गरीब आदमी की प्रतिकृति" के रूप में कई विक्रेताओं द्वारा एचटीएमएल 5 कैनवास। दिलचस्प रूप से पर्याप्त है, सर्वर की तरफ पायथन प्रोग्रामिंग भाषा के समान फायदे हैं जो जावा ने वादा किया था: एक बार लिखें, हर सर्वर पर चलाएं, हार्डवेयर की परवाह किए बिना, बशर्ते कि पायथन एप्लिकेशन मशीन कोड के लिए संकलित न हो। अजगर जावा के रूप में पुराने / युवा के बारे में है, लेकिन जावा के विपरीत, यह '

सारांश:

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

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

C ++ की कुछ सीमाओं के लिए संभावित समाधान

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

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

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