अन्य उत्तरों में पहले से ही कुछ अच्छे अंक हैं, लेकिन मैं आपके प्रश्नों और कथनों को व्यक्तिगत रूप से संबोधित करते हुए अधिक संपूर्ण उत्तर प्रदान करना चाहूंगा।
यदि जावा एक ऐसी सुविधा प्रदान नहीं करता है जो C ++ के पास है, तो इसका मतलब है कि यह सुविधा अच्छी नहीं है, इसलिए हमें इसका उपयोग करने से रोकना चाहिए।
यह बहुत अच्छी तरह से उत्तर दिया गया है: जावा C ++ का "अच्छा भाग" नहीं है, और न ही ऐसा सोचने का कोई कारण है।
विशेष रूप से, हालांकि प्रत्येक व्यक्ति C ++ सुविधा के गुणधर्म बहस योग्य हैं, C ++ 11 / C ++ 14 की कई विशेषताएं जो जावा का हिस्सा नहीं हैं, जरूरी नहीं है क्योंकि जावा डिजाइनरों ने सोचा था कि वे एक खराब विचार थे। एक उदाहरण के रूप में, 8 संस्करण तक, जावा में लैम्बदास नहीं था, लेकिन उन्हें C ++ 11 मानक में C ++ से परिचित कराया गया था। जावा 8 से पहले, आपकी धारणा है कि जावा से गायब सी ++ सुविधाएँ डिज़ाइन द्वारा गायब थीं क्योंकि वे "अच्छे नहीं हैं" का अर्थ यह होता है कि लैम्बदास को भाषा की सुविधा के रूप में "अच्छा नहीं" (हर जगह LISPers के आतंक से, हालांकि वे हैं) शायद यह सुनकर काफी डर गया कि आप वास्तव में जावा की तरह हैं )। लेकिन अब जावा डिजाइनरों ने लैम्बडा पर अपना स्टैम्प ऑफ अप्रूवल (टीएम) डाल दिया है, इसलिए वे अब ए गुड थिंग हैं।
जावा 8 में भी थोड़ा गहरा खुदाई करने के लिए, लैम्ब्डा-एस-क्लोजर C ++ 14 के लैम्ब्डा की तरह लचीला नहीं है, लेकिन यह जेवीएम आर्किटेक्चर की सीमाओं के कारण हो सकता है कि एक सचेत निर्णय के बजाय अधिक लचीला दृष्टिकोण खराब हो। भाषा-डिजाइन परिप्रेक्ष्य।
C ++ विशिष्ट सुविधाओं के साथ C ++ कोड (जैसे: मित्र कार्य, एकाधिक उत्तराधिकार) केवल C ++ प्रोग्रामर द्वारा बनाए रखा जा सकता है या इसकी समीक्षा की जा सकती है, लेकिन अगर हम सिर्फ जावा की तरह C ++ लिखते हैं (C ++ भाषा विशिष्ट सुविधा के बिना), तो कोड को बनाए रखा जा सकता है या दोनों की समीक्षा की जा सकती है। सी ++ और जावा प्रोग्रामर।
यह मुख्य बात है जिसका मैं जवाब देना चाहता था।
मोटे तौर पर, प्रोग्रामर से कोड समीक्षाएं प्राप्त करने के लिए कुछ मूल्य हो सकते हैं जो आपके द्वारा उपयोग की जाने वाली भाषा से परिचित नहीं हैं। वे आपको अपने फ़ंक्शन / विधि के नाम और टिप्पणियों की स्पष्टता के बारे में मूल्यवान प्रतिक्रिया दे सकते हैं, और (जैसा कि आपका प्रश्न सही ढंग से पता चलता है) यदि भाषा एक या अधिक भाषाओं के समान है जो वे पहले से जानते हैं, तो वे मूल कार्यक्रम प्रवाह का पालन करने में सक्षम हो सकते हैं और संभावित रूप से तर्क त्रुटियों को पकड़ते हैं।
हालाँकि, यह मामला नहीं है कि इस तरह की समीक्षा कभी भी "उन लोगों के लिए" के समान "अच्छी" या "उन डेवलपर्स की समीक्षा के बराबर" होगी जो वास्तव में उस भाषा को जानते हैं जो आप उपयोग कर रहे हैं। अनिवार्य रूप से, ऐसा इसलिए है क्योंकि एक भाषा को दूसरे की तरह देखना आमतौर पर सूक्ष्म अंतर को छिपाएगा, जबकि एक भाषा को दूसरे की तरह व्यवहार करना (विशेष रूप से C ++ और जावा के मामले में) भाषा के लिए अ-मुहावरेदार हो सकता है और / या अभी भी बहुत ही भ्रामक हो सकता है। समीक्षकों के लिए।
पहले, आइए इस बारे में सोचें कि C ++ को "Java" की तरह बनाने का क्या अर्थ होगा। एक साधारण मामले के रूप में, आप newजावा में ठीक उसी तरह वस्तुओं का उपयोग कर सकते हैं :
Foo foo = new Foo();
लेकिन ऑब्जेक्ट्स ->ने .कॉल विधियों के बजाय इस तरह का उपयोग किया है , इसलिए यदि आप जावा की तरह दिखने के लिए विधि कॉल चाहते हैं, तो आपको इसके बजाय लिखना होगा:
Foo& foo = *new Foo();
लेकिन यह अन-आइडियल है; विशेष रूप से, मेमोरी को बाद में उपयोग करके साफ किया जाना चाहिए delete &foo, जो कि कुछ अनुभवी सी ++ देवों को भी महसूस नहीं हो सकता है कि कानूनी कोड है । किसी भी तरह से, वहाँ अजीब गैर जावा की तरह भर में छिड़का प्रतीक हैं, इसलिए हम नहीं कर सकते काफी भाषा जावा "की तरह लग रहे" बनाते हैं। (आप *newका उपयोग करके #define New *new, या इससे भी बदतर हो सकता है #define new *new, लेकिन तब आप अपने साथी डेवलपर्स के लिए आपसे घृणा कर रहे हैं।) और, जैसा कि ऊपर उल्लेख किया गया है, deleteजावा में मौजूद नहीं है, इसलिए किसी भी मामले में (जैसा कि किसी अन्य उत्तर में उल्लेख किया गया है। ) आप वास्तव में ऑब्जेक्ट-उपयोग "लुक" नहीं कर सकते हैं जिस तरह से यह जावा में मेमोरी लीक के बिना करता है।
लेकिन आधुनिक सी ++ में स्मार्ट शेयर्ड पॉइंटर्स शामिल हैं, जो जावा के मेमोरी-मैनेजेड वेरिएबल-रेफरेंस की तरह व्यवहार करते हैं। तो जावा में हर जगह जो आप लिख सकते हैं Foo foo = new Foo();, आप इसके बजाय लिख सकते हैं:
std::shared_ptr<Foo> foo = std::make_shared<Foo>();
अब आप एक भाषा सुविधा का उपयोग कर रहे हैं जो वास्तव में जावा के हुड के नीचे बहुत कुछ है। लेकिन अचानक आपको गैर-सी ++ समीक्षकों को समझाने के लिए बहुत कुछ है: यह shared_ptrसामान क्या है ? सूक्ष्म पेचीदा "गोचा" क्या हैं make_shared? (यह सही-अग्रेषण का उपयोग करता है, जिसमें कुछ विफलता के मामले हैं और "गलत" निर्माता को बुलाया जा सकता है।) तरीकों को क्यों बुलाया जाना चाहिए ->, लेकिन .कुछ तरीकों के साथ उपयोग करने की अनुमति संकलक द्वारा दी जाती है? ( shared_ptrइसकी अपनी विधियाँ हैं।) यदि यह विधि Foo::reset(void)मौजूद है, तो एक अपरिवर्तित डेवलपर इसके साथ कॉल करने का प्रयास कर सकता है foo.reset(), जो (यदि Fooकॉल होने पर उस उदाहरण की ओर संकेत करने वाला केवल एक साझा सूचक है) अंतर्निहित मेमोरी को हटा देगा और nullify करेगा foo, और जावा डेवलपर्स को इस समस्या को पकड़ने की संभावना नहीं है।
इसके अलावा, C ++ में बहुत सारे नुकसान हैं जो भाषा के लिए विशिष्ट हैं। जैसा कि सबसे अच्छा मैं बता सकता हूं, अधिकांश सी ++ डेवलपर्स धीरे-धीरे "सुरक्षित" सी ++ प्रथाओं के लिए अपने स्वयं के मुहावरे को विकसित करके इन नुकसानों से निपटना सीखते हैं, जो अक्सर उनके लिए या उनकी विकास टीम के लिए कुछ अनोखा होता है (उदाहरण के लिए मौजूदा जवाब देखें जिसमें उल्लेख है Google कोडिंग प्रथाओं और उस पर टिप्पणी कह रहा है कि "अनुभवी सी ++ दिग्गज आमतौर पर Google कोडिंग दिशानिर्देशों को अस्वीकार करते हैं")। सभी का दावा है कि भाषा बहुत जटिल हो सकती है, ऐसा लगता है (मेरे अनुभव में, कम से कम), आमतौर पर "अच्छी तरह से, इसके गलत उपयोग को रोकने के कुछ बदलाव" के साथ मिलते हैं। मुझे लगता है कि यह C ++ समुदाय का एक अत्यधिक नकारात्मक दृष्टिकोण है, और निश्चित रूप से अनुभवी डेवलपर्स भाषा-शिक्षार्थियों की मदद करने के लिए अधिक इच्छुक हैं, लेकिन ऐसा नहीं करता है उदाहरण के लिए अपरिभाषित व्यवहार के बारे में एक निश्चित संवेदनशीलता प्रतीत होती है (उदाहरण के लिए ऊपर मेरे 'नुकसान' लिंक में चर्चा के बहुत से देखें)।
जावा डेवलपर केवल कोड समीक्षा के माध्यम से इन नुकसानों को खोजने और सही करने में सहायक नहीं होंगे।
आपको किसी दिन जावा में कोड बदलने के लिए कहा जा सकता है।
यह पूरी तरह से मान्य है - सराहनीय, यहां तक कि - यह ध्यान रखने की कोशिश करने के लिए कि डिजाइन चरण में आपके भविष्य में आपके कोड के साथ क्या हो सकता है।
लेकिन, सबसे पहले, यह विशेष रूप से एक दूरस्थ संभावना की तरह लगता है: कोड आमतौर पर या तो फिर से उपयोग किया जाता है (उदाहरण के लिए आप JNI इंटरफेस का उपयोग करके कुछ भविष्य के जावा सॉफ्टवेयर में कुछ या सभी C ++ कोड को प्लग कर सकते हैं) या पूरी तरह से फिर से लिखा जाता है सीधे "मैन्युअल रूप से स्थानांतरित" से।
और, दूसरा, आप बाद में कहते हैं,
हर सी ++ भाषा विशिष्ट सुविधा (जैसे: एकाधिक विरासत) को जावा में लागू करने के लिए विकल्प होना चाहिए ...।
यह अनिवार्य रूप से आपके "जावा में कनवर्ट" बिंदु को रद्द करता है। यदि सॉफ़्टवेयर मुहावरेदार C ++ में लिखा गया है और फिर मुहावरेदार जावा में परिवर्तित हो गया है, तो यह अपेक्षा करने का कोई कारण नहीं है कि यह रूपांतरण जावा सुविधाओं के लिए C ++ सुविधाओं के सटीक एक-से-एक मैपिंग को लागू करके (या) किया जा सकता है।
C ++ विशिष्ट विशेषताओं के बिना कोड आमतौर पर अधिक बनाए रखने योग्य है।
यह स्पष्ट नहीं है कि आपका यहां क्या मतलब है, लेकिन मैं वास्तव में कुछ हद तक इस बात से सहमत हूं: जब तक आप बहुत सावधान नहीं हैं, और यहां तक कि जब आप सावधान होते हैं, तो C ++ की विशेषताएं स्थिरता की समस्याएं पैदा कर सकती हैं। सी ++ FQA लाइट (एक वेबसाइट भाषा और कोई है जो कम से कम वास्तव में यह काफी अच्छी तरह से समझने के लिए प्रकट होता है से उसके अनुयायियों की आलोचना) कहा गया है कि
... 80% डेवलपर्स भाषा के अधिकांश 20% पर समझते हैं। यह अलग-अलग लोगों के लिए समान 20% नहीं है, इसलिए एक-दूसरे के कोड को समझने के लिए उन पर भरोसा न करें।
कृपया ध्यान दें: यदि आप एक सी ++ प्रशंसक हैं और आप मेरे जवाब में इस बिंदु पर आते हैं और टिप्पणी करने के लिए नीचे कूदने के लिए इच्छुक महसूस करते हैं कि एफक्यूए के लेखक वास्तव में सी ++ को नहीं समझते हैं या उनके अधिकांश तर्कों में अपमानजनक है। , ध्यान दें कि (1) ठीक दो वाक्यों के बाद मैं उसे उद्धृत करता हूं कि मैं स्वीकार करता हूं कि FQA एक बहुत ही पक्षपाती स्रोत है, और (2) यह वास्तव में मेरे लिए क्या कहना चाह रहा है या नहीं, इसके लिए कोई फर्क नहीं पड़ता कि FQA लेखक C ++ को समझता है या नहीं। , और मैं सी ++ को काटने की कोशिश नहीं कर रहा हूं, और आपको बाकी पोस्ट को यह मानकर बिना पढ़ना चाहिए कि मैं सी-सी ++ विरोधी हूं क्योंकि मैंने एफक्यूए उद्धृत किया है। नोट का अंत।
इसी तरह, लिनुस टॉर्वाल्ड्स अनिवार्य रूप से इस कारण से सी ++ से नफरत करते हैं (चेतावनी: लिंक में बहुत सारे शपथ लेना शामिल है, असली बदनाम लिनुस शैली में)।
जाहिर है, ये बात बहुत पक्षपाती है, लेकिन यहां तक कि C ++ के प्रस्तावक भी अक्सर कहते हैं कि आपको भाषा सुविधा-सेट की संपूर्णता का उपयोग नहीं करना चाहिए (एक बार फिर, Google कोडिंग दिशानिर्देश देखें; साथ ही, C ++ के निर्माता Bjarne Stroustrup; , सार्वजनिक रूप से कहा गया है, "सी ++ के भीतर, बाहर निकलने के लिए संघर्ष करने वाली एक बहुत छोटी और क्लीनर भाषा है")।
इसलिए मुझे लगता है कि इस विचार में कुछ योग्यता है कि सी ++ सुविधाओं का दुरुपयोग करना बहुत आसान हो सकता है, खासकर यदि आप एक जावा पृष्ठभूमि से आ रहे हैं। इसके अलावा, भाषा के कुछ सबसेट तक खुद को सीमित करके इन समस्याओं को दूर करने के विचार में योग्यता है।
हालाँकि, यह तय करना कि किसी अलग भाषा के आधार पर किस उपसमुच्चय का उपयोग करना सही दृष्टिकोण की तरह प्रतीत नहीं होता है, जब तक कि "अलग भाषा" C नहीं है, क्योंकि वास्तव में C ++ भाषा का C- जैसा उपसमुच्चय है। (लिनुस ऊपर अपने शेख़ी में इसे संदर्भित करता है, और स्कॉट मेयर्स ने भी इस उपसमुच्चय को "उप-भाषा" के रूप में संदर्भित किया है) जावा का रन-टाइम प्रतिमान (कचरा एकत्र करना, एक वीएम पर चल रहा है) सी ++ के मौलिक रूप से भिन्न है। स्पष्ट नहीं है कि इसमें से C ++ उपयोग के बारे में जानने के लिए कोई उपयोगी सबक नहीं हैं, और जैसा कि ऊपर उल्लेख किया गया है, जावा से सीधे C ++ के बारे में पाठ आकर्षित करने की कोशिश करने से बहुत गैर-मुहावरेदार कोड हो सकता है।
इसके बजाय, भाषा के अपने "स्वीकार्य उपसमुच्चय" को यह समझने की कोशिश करें कि भाषा का उपयोग मुहावरेदार तरीके से कैसे किया जा सकता है। यदि आप एक काफी प्रतिबंधात्मक उपसमुच्चय चाहते हैं जो अभी भी C ++ की कई विशेषताओं का लाभ उठाता है जो कि C प्रदान करता है, तो उपरोक्त Google कोडिंग दिशानिर्देश शुरू करने के लिए एक अच्छी जगह हो सकती है। ज़रूर, आपको डेवलपर्स मिलेंगे जो कहते हैं कि Google के कुछ प्रतिबंधों के लिए "कोई तर्कसंगत तर्क नहीं है" , लेकिन जब तक आप अलेक्जेंड्रेस्कु को डी भाषा पर अपने काम से दूर नहीं कर रहे हैं (जो खुद आपको कुछ बताना चाहिए), शायद ठीक है। यह निश्चित रूप से जावा में C ++ को चालू करने की कोशिश से बेहतर है।
कोड दिशानिर्देशों के एक सेट के लिए एक और अच्छा प्रारंभिक बिंदु नई सी ++ कोर दिशानिर्देश है , बज़्ने स्ट्रॉस्ट्रुप और हर्ब सटर द्वारा एक कार्य-प्रगति।
C ++ की कमियों से निपटने का एकमात्र तरीका एक अलग भाषा चुनना है। यह आपको जावा की तरह लगता है, और आपको लगता है कि एक मौका है कि यह परियोजना अंततः जावा में परिवर्तित हो सकती है। जैसा कि एक अन्य जवाब में कहा गया है, आप बस ... जावा से शुरू कर सकते हैं।
दो कारण हैं जो आपको वास्तव में जावा के अलावा किसी अन्य चीज़ का उपयोग करने की आवश्यकता हो सकती है :
- आपको वास्तव में रन-टाइम प्रदर्शन की आवश्यकता है। इस स्थिति में, C ++ की तरह यह जावा का इलाज संभवत: वास्तव में आपकी मदद नहीं करेगा, क्योंकि जावा जैसी तकनीक साझा-पॉइंटर्स आपके रन-टाइम प्रदर्शन को नीचा दिखाती है।
- आपको एक अस्पष्ट प्लेटफ़ॉर्म पर काम करने के लिए सॉफ़्टवेयर की आवश्यकता है जो अभी तक जेवीएम का समर्थन नहीं करता है। इस मामले में, आप शायद उन भाषाओं के साथ फंस गए हैं जिनमें जीसीसी या क्लैंग फ्रंटेंड हैं। C और C ++ स्पष्ट उम्मीदवार हैं, लेकिन आप भी रुस्ट की तरह कुछ देख सकते हैं। (क्विक प्लग: मैंने बड़े पैमाने पर रस्ट का उपयोग नहीं किया है, लेकिन यह बहुत बढ़िया लग रहा है और मैं जितनी जल्दी हो सके एक प्रमुख रस्ट प्रोजेक्ट पर काम करने के लिए उत्सुक हूं, और मुझे लगता है कि सी ++ प्रोजेक्ट शुरू करने पर विचार करने वाले सभी को रस्ट को एक विकल्प के रूप में मानना चाहिए।)
हर C ++ भाषा की विशिष्ट सुविधा (उदाहरण: एकाधिक वंशानुक्रम) में जावा में लागू होने के विकल्प होने चाहिए। यदि ऐसा नहीं होता है, तो इसका मतलब है कि डिज़ाइन पैटर्न या कोड आर्किटेक्चर समस्याग्रस्त है।
मैंने पहले से ही इसे कुछ हद तक संबोधित किया है, लेकिन मैंने जानबूझकर अपना दूसरा वाक्य छोड़ दिया है।
मुझे यकीन नहीं है कि ऐसा कुछ constexpr, जो जावा जैसी आंशिक-जेआईटी भाषा में कोई मतलब नहीं होगा, यह अवैध वास्तुकला का संकेत है। मैं इस विचार के लिए अधिक खुला हूं कि टेम्प्लेट मेटा-प्रोग्रामिंग का अत्यधिक उपयोग इसके लायक होने की तुलना में अधिक परेशानी हो सकती है, विशेष रूप से अब जो constexprसंकलन-समय फ़ंक्शन मूल्यांकन करने के लिए मौजूद है, लेकिन यह इस मामले से स्पष्ट है constexprकि कोई डिज़ाइन दोष नहीं है यदि आप इसका उपयोग कर रहे हैं: आप बस यह सुनिश्चित कर रहे हैं कि कुछ गणनाएँ कोड चलाने से पहले भी होती हैं, जो कि एक भयानक प्रदर्शन को बढ़ावा देने वाला है (उदाहरण के लिए बेंचमार्क गेम की एन-बॉडी समस्या के लिए इस प्रविष्टि को देखें , जो एक दूसरे को छोड़कर हर दूसरी प्रविष्टि को बेहतर बनाता है। C ++ में लिखा है,