Godot: गोडोट में सी++ की स्थिति

इस पर कई बार चर्चा हुई, सामान्य उत्तर हैं:

1) कोडबेस को 03 से ऊपर किसी भी चीज़ में स्थानांतरित करने की कोई इच्छा नहीं है। सुविधाएँ इसके लायक नहीं हैं। GDNative C++ के लिए, हालांकि इसका उपयोग करना पूरी तरह से संभव है।
2) एसटीएल/बूस्ट/आदि का उपयोग करने की कोई इच्छा नहीं है। तर्क हमेशा एक ही रहा है: ए) गोडोट टेम्पलेट्स छोटी चीजें करते हैं जो वे सामान्य रूप से नहीं करते हैं (यानी, परमाणु पुनर्गणना और लिखने पर कॉपी) बी) एसटीएल अपने बहुत लंबे उलझन वाले प्रतीकों के कारण विशाल डीबग प्रतीक और डीबग बाइनरी उत्पन्न करता है

हम वैसे ही रखते हैं जैसे सब कुछ है।

निजी बातचीत पर मेरी कुछ राय है, लेकिन मैं इसे बनाना चाहता था
अधिक सार्वजनिक चर्चा।

मुझे नहीं पता था कि इस पर इतनी चर्चा हो चुकी है और इसे पहले ही बंद कर दिया गया है।

क्या आप ऑटो, कॉन्स्टेक्स और ऐसे को भी छोड़ देते हैं?

ड्रॉप 'रजिस्टर'?

एल 18 जुलाई। 2017 1:54 अपराह्न, "जुआन लिनिएत्स्की" नोटिफिकेशन @github.com
विवरण:

इस पर कई बार चर्चा हुई, सामान्य उत्तर हैं:

1. कोडबेस को 03 से ऊपर किसी भी चीज़ में स्थानांतरित करने की कोई इच्छा नहीं है। विशेषताएं हैं
   इसके लायक नहीं। GDNative C++ के लिए, हालांकि इसका उपयोग करना पूरी तरह से संभव है।
2. एसटीएल/बूस्ट/आदि का उपयोग करने की कोई इच्छा नहीं है। तर्क हमेशा से रहा है
   वही: ए) गोडोट टेम्पलेट्स छोटी चीजें करते हैं जो वे सामान्य रूप से नहीं करते हैं (यानी, परमाणु
   रिफकाउंट और कॉपी ऑन राइट) बी) एसटीएल विशाल डिबग प्रतीक और डिबग उत्पन्न करता है
   उनके अत्यंत लंबे उलझे हुए प्रतीकों के कारण बायनेरिज़

हम वैसे ही रखते हैं जैसे सब कुछ है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने सूत्र को लिखा है।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/godotengine/godot/issues/9694#issuecomment-316041201 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/ALQCtipKmepD_1Xw6iRXZ7aGoQlLfiwFks5sPJzqgaJpZM4ObOio
.

मैंने इस मुद्दे को उठाया कि स्मार्ट पॉइंटर्स का उपयोग करना सुरक्षित होगा और यह कोड एनआईएच सिंड्रोम से ग्रस्त है, लेकिन उच्च-अप का अपग्रेड करने का कोई इरादा नहीं है, इसलिए मेरा सुझाव है कि आप भी हार मान लें।

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

@Marqin क्षमा करें, लेकिन स्मार्ट पॉइंटर्स एक बुरा विचार है क्योंकि:

1) केवल एक ही उपयोगी है रीकाउंटेड एक, बाकी भाषा में पहले से मौजूद सुविधाओं के लिए मानसिक हस्तमैथुन है।
2) हर जगह स्मार्ट पॉइंटर्स का उपयोग करना एक भयानक विचार है, आपको संदर्भ चक्र होने का जोखिम है जो स्मृति को रिसाव करता है
3) हमारे पास पहले से ही कुछ समान है, Ref<> , अतिरिक्त लाभ के साथ कि हम नियंत्रित करते हैं कि रेफरेंसिंग गिनती कैसे काम करती है, इसलिए हम सी # जैसी भाषाओं में बाइंडिंग को संभालने के लिए विशेष मामलों को जोड़ सकते हैं, उनके पास अपना स्वयं का जीसी है

इसलिए, दलील देने से पहले दलील दें कि हम अपनी मर्जी से चीजें तय करते हैं, बस पूछिए। हम आमतौर पर सूचित निर्णय लेते हैं और प्रक्रिया को सभी के साथ साझा करते हैं।

यदि आप गुणवत्ता में सुधार करना चाहते हैं तो आसानी से क्या किया जा सकता है, इकाई परीक्षण लिखना शुरू करना है (उसके लिए स्कैन में कुछ वैकल्पिक नौकरी जोड़ें, और बस देव को gmock /gtest स्वयं स्थापित करें [क्लोग नहीं करने के लिए।/थर्डपार्टी])

बाकी भाषा में पहले से मौजूद सुविधाओं के लिए मानसिक हस्तमैथुन है

@reduz , इसके स्पष्ट स्वामित्व और भाषा में पहले से मौजूद RAII मेमोरी फ्रीिंग के साथ unique_ptr कैसा है?

इसके अलावा न केवल स्मृति प्रबंधन, बल्कि थ्रेडिंग भी आसान हो जाती है (उदाहरण के लिए lock_guard )।

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

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

कोई बात नहीं। मैं आपकी बात का सम्मान करता हूं। केवल मुझे लगता है कि इस बारे में चर्चा करना एक स्वस्थ बात है।

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

इसलिए हम कर सकते थे:

• दर्द रहित सभी कोड माइग्रेशन के लिए एक उचित उपसमुच्चय चुनें;
• या कम से कम नए कोड के लिए "अनुमोदित" के रूप में एक उचित उपसमुच्चय चुनें।

दोनों ही मामलों में एक कोडिंग शैली को परिभाषित करने की आवश्यकता होगी ताकि सुविधाओं का दुरुपयोग न हो, जैसा कि आपने कहा था कि यह auto के साथ होता है।

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

@Marqin जैसा कि उल्लेख किया गया है, गोडोट नोड्स के लिए अपनी स्मृति आवंटन योजना का उपयोग करता है, जो नए मानक पुस्तकालयों द्वारा प्रदान की गई किसी भी चीज़ से अधिक समझ में आता है।

इसके अलावा लॉक गार्ड कोड की लगभग 3 पंक्तियाँ हैं और हमने इसे C++11+ . का उपयोग किए बिना पहले ही लागू कर दिया है

फिर, हमें यह क्यों मान लेना चाहिए कि कुछ भी "मानक" 1) हमारे पास पहले से मौजूद 2 से बेहतर होना चाहिए) अगर हम इसे वैसे भी उपयोग करते हैं तो बेहतर है? .मुझे लगता है कि यह एक सामान्य भ्रांति है।

आगे क्या है, हमारे प्रिंट कार्यों को छोड़ना और ostream/istream का उपयोग करना? हमारे स्ट्रिंग क्लास को बदलें, जो बहुत बढ़िया है, और इसे और अधिक अपंग std::string या std::wstring से बदलें?

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

@RandomShaper समस्या यह है कि:

1) यह लाभ से अधिक लागत है।
2) सी ++ 11+ लिखने का मानक तरीका कैसा है, इस पर बहुत सारे तर्कों के लिए विंडो खुल जाएगी। यह किसी बिंदु पर उन्हें रखने के लायक हो सकता है, और इन सुविधाओं का लाभ उठाने के लिए इंजन के बड़े हिस्से को फिर से लिखना एक दिन उपयोगी हो सकता है, लेकिन मुझे लगता है कि ध्यान केंद्रित करने के लिए और भी महत्वपूर्ण चीजें हैं।
3) जैसा कि पहले उल्लेख किया गया है, यह संभव हो सकता है कि एक नए सी ++ संस्करण को पोर्ट करने के लिए जितना अच्छा लगता है, इसका परिणाम बहुत बड़ा बाइनरी आकार हो सकता है। ऐसे में यह अवांछित हो सकता है।

यह गंभीरता से इस समय इसके लायक नहीं है, हम कुछ वर्षों में इस पर फिर से चर्चा कर सकते हैं

मुझे लगता है कि यह सुनिश्चित करने के लिए समझ में आता है कि गोडोट --std=c++17 जैसे विकल्पों के साथ संकलित करता है, ताकि आप आसानी से आधुनिक सी ++ में लिखी गई लाइब्रेरी ला सकें यदि आपको आवश्यकता हो। उदाहरण के लिए, मैं कोडबेस से रजिस्टर कीवर्ड को हटाने के लिए वोट करूंगा https://github.com/godotengine/godot/issues/9691

किसी तरह संबंधित, मुझे याद है कि मैंने कहीं पढ़ा है कि gcc-6.3 समर्थित नहीं है (google
कहते हैं कि यह https://github.com/godotengine/godot/issues/7703 में था)। यह मुझे परेशान करता है क्योंकि gcc-6.3 मेरे डिस्ट्रो (डेबियन स्टेबल) में डिफ़ॉल्ट कंपाइलर है। क्या कोई इसकी पुष्टि कर सकता है? और यही वजह है कि?

@efornara कुछ तीसरे पक्ष के पुस्तकालयों को पहले से ही नए सी ++ संस्करणों की आवश्यकता होती है, और यह ठीक है क्योंकि स्कैन क्लोन बिल्ड वातावरण के साथ इसका ख्याल रखता है। यह कैसे काम करता है यह देखने के लिए etc2comp थ्रिडपार्टी कोड देखें।

@karroffel धन्यवाद, मुझे यह नहीं पता था।

यह तब एक अच्छी सुविधा होगी, लेकिन पुस्तकालय को आयात करने के लिए इसकी आवश्यकता नहीं है (हालांकि, यदि गोंद कोड के लिए आपको अधिक गोडोट शामिल करने की आवश्यकता है तो आप एक हेडर फ़ाइल में ठोकर खा सकते हैं जो संकलित नहीं होती है)।

वैसे, अगर किसी को भी कुछ ऐसा ही करने की ज़रूरत है और उसे यह पोस्ट मिल गई है, तो प्रासंगिक फ़ाइल है: https://github.com/godotengine/godot/blob/master/modules/etc/SCsub । मैंने इसे grep का उपयोग करते हुए पाया है और यह एकमात्र ऐसा स्थान है जहाँ इस समय इसकी आवश्यकता है।

c++11 को not-c++11 कोड से लिंक करना इतना सुरक्षित नहीं है - http://gcc.gnu.org/wiki/Cxx11AbiCompatibility

@Marqin जब तक मैं लिंक को गलत नहीं समझता, यह वास्तव में मानक पुस्तकालय से घटकों का उपयोग शुरू करने के लिए godot _not_ के मामले का समर्थन करता है, लेकिन इसके बजाय कस्टम घटकों से चिपके रहता है:

सी ++ 98 भाषा एबीआई-सी ++ 11 भाषा के साथ संगत है, लेकिन मानक लाइब्रेरी ब्रेक संगतता में कई जगह है।

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

@efornara लिंक कुछ तृतीय-पक्ष libs को जोड़ने के बारे में है जो सी ++ 11 का उपयोग गोडोट के साथ करते हैं जो सी ++ 03 का उपयोग करते हैं।

@ मारकिन हां, लेकिन जिस तरह से मैं लिंक को समझता हूं वह यह है कि आप इसे कर सकते हैं। आप जो नहीं कर सकते हैं, उदाहरण के लिए, गोडोट से थर्ड-पार्टी लाइब्रेरी में एक std::list<> पास करना।

@reduz जहां मुझे गोडोट के आंतरिक रेफरी <> के दस्तावेज मिल सकते हैं? गोडोट के आंतरिक कंटेनर एसटीएल के कंटेनर से कैसे भिन्न हैं, इस पर मुझे दस्तावेज़ीकरण कहां मिल सकता है?

@Marqin कंटेनरों के लिए बहुत कुछ नहीं है:
http://docs.godotengine.org/hi/stable/Development/cpp/core_types.html#containers
रेफरी के लिए <> मुझे एहसास हुआ कि कोई भी नहीं है। शायद जोड़ा जाना चाहिए।
इन चीजों को जोड़ने के लिए डॉक्टर को कैसे बेहतर बनाया जाए, इस पर किसी भी सुझाव का बहुत स्वागत है।

व्यक्तिगत रूप से मुझे नया सी++ मानक बहुत बढ़िया लगता है, लेकिन मैं किसी भी गोडोट आंतरिक रिफैक्टरिंग का प्रस्ताव नहीं दूंगा क्योंकि इसे बहुत कम लाभ के लिए बहुत अधिक प्रयासों की आवश्यकता होगी।

इस सटीक कारण के लिए पिछड़ी संगतता में से एक सी ++ के लक्षणों में से एक है। लेकिन फिर भी मैं इसे नई गोडोट सुविधाओं और GDNative में उपयोग करने में सक्षम होना चाहता हूं।
मैं इस कारण से आधुनिक सी ++ समर्थन के साथ गोडोट को संकलित करना पसंद करूंगा।

@reduz जैसा कि आपने कहा था सी ++ 11/14/17 आपको कम स्पष्ट कोड लिखने देता है। यहां तक ​​​​कि कठिन यह सी ++ न्यूबीज के लिए एक कमी है, यह सी ++ पावर उपयोगकर्ताओं के लिए एक अच्छी बात है।
जहां तक ​​"ऑटो" का सवाल है, मैं व्यक्तिगत रूप से सोचता हूं कि क्या यह बिजली उपयोगकर्ताओं के लिए भी अच्छा है। यह न केवल आपको सख्त आवश्यक न होने पर बार-बार टाइपिंग से बचने की अनुमति देता है, बल्कि यह कुछ बग टाइप करने से भी बच सकता है।

FYI करें, मैंने हाल ही में एक मास्टर (godot3) को संकलित किया है:

scons platform=x11 target=debug tools=yes builtin_openssl=true CCFLAGS=-std=c++17

डेबियन खिंचाव पर (gcc-6.3)। कष्टप्रद, सी फाइलों को संकलित करते समय विकल्प भी सेट किया जाता है, इसलिए यदि आप उन्हें सक्षम करते हैं तो आप चेतावनियों से भर जाते हैं, लेकिन इसके अलावा, यह सब आसानी से चला गया। यहां तक ​​​​कि रजिस्टर कीवर्ड भी परेशानी का कारण नहीं लगता है।

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

संपादित करें: चेतावनियों के बारे में बयान को स्पष्ट करते हुए, कुछ टाइपो को ठीक किया।

कष्टप्रद, सी फाइलों को संकलित करते समय विकल्प भी सेट किया जाता है

क्या आपने CPPFLAGS के साथ प्रयास किया था?

@ हिंसबार्ट नहीं, मैंने नहीं किया। हो सकता है कि कोई रास्ता हो, लेकिन चूंकि मैं स्कैन को अच्छी तरह से नहीं जानता, इसलिए मैं बिना किसी छेड़छाड़ के जो संभव लग रहा था, उसके साथ चला गया:

$ scons platform=x11 builtin_openssl=true -h | grep FLAGS
CCFLAGS: Custom flags for the C and C++ compilers
CFLAGS: Custom flags for the C compiler
LINKFLAGS: Custom flags for the linker

संपादित करें: वैसे, मुझे नहीं पता कि गोडोट बिल्ड सिस्टम में इसका उपयोग कैसे किया जाता है, लेकिन CPPFLAGS मुझे प्रीपोसेसर विकल्पों के बारे में सोचने पर मजबूर कर देगा। व्यक्तिगत रूप से, मैंने हमेशा C++ के लिए CXXFLAGS उपयोग किया है।

क्या आपने CPPFLAGS के साथ प्रयास किया?

मुझे लगता है कि CPPFLAGS प्रीप्रोसेसर का उपयोग करने वाली प्रत्येक भाषा को प्रभावित करता है, इसलिए सी और सी ++ दोनों शामिल हैं।

@ m4nu3lf आप GDNative के साथ जो भी सी ++ चाहते हैं उसका उपयोग कर सकते हैं।

मेरे अनुभव में, कोड को हटाने का कोई भी अवसर एक अच्छा अवसर है।

शायद हम किसी प्रकार के विकी पेज को दस्तावेज कर सकते हैं कि कौन सी फाइलों को हटाया जा सकता है और सी ++ 11 रूपों के साथ प्रतिस्थापित किया जा सकता है। इसमें शायद थ्रेडिंग प्राइमेटिव्स और ऐसे शामिल होंगे।

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

आप जो सबसे अच्छा कोड लिखेंगे वह वह कोड है जिसे आपने नहीं लिखा है। :)

जिज्ञासा से बाहर, क्या ऐसा कोड लिखना संभव है जो पुराने C++ और नए C++ दोनों के साथ संकलित हो? क्या सी ++ संस्करणों के बीच महत्वपूर्ण ब्रेकिंग परिवर्तन हैं?

जिज्ञासा से बाहर, क्या ऐसा कोड लिखना संभव है जो पुराने C++ और नए C++ दोनों के साथ संकलित हो? क्या सी ++ संस्करणों के बीच महत्वपूर्ण ब्रेकिंग परिवर्तन हैं?

नया C++ 99.99...% मामलों में पुराने C++ के साथ पीछे की ओर संगत है (केवल वे चीज़ें जिनका उपयोग नहीं किया जाना चाहिए था या जिन्हें खराब-परिभाषित किया गया था, उन्हें अब समर्थित नहीं के रूप में परिभाषित किया गया था, लेकिन सामान्य तौर पर जो केवल संकलन चेतावनियों का कारण बनेंगी, लेकिन आजकल भी काम करती हैं) .

हालांकि, नए सी ++ में महत्वपूर्ण विशेषताएं हैं, और वे स्पष्ट रूप से पुराने सी ++ संस्करणों में काम नहीं करेंगे, और वे सुविधाएं केवल वैरिएडिक मैक्रोज़ और auto और लैम्ब्डा जैसी उपयोगिता सुविधाएं नहीं हैं, बल्कि move जैसी दक्षता सुविधाएं भी हैं

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

मैं टिप्पणी करना चाहता था। मैं गोडोट को सी ++ 17 ध्वज के साथ संकलित करने में सक्षम था, जिसमें एकमात्र मुद्दा तीसरे_पार्टी सामान में से एक था जो auto_ptr का उपयोग करता था (जिसे सी ++ 17 से हटा दिया जाता है क्योंकि यह कितना खराब है)

समस्या यह नहीं है कि यह सी ++ 17 में संकलित नहीं है, समस्या यह है कि जो लोग सी ++ 17 सुविधाओं का उपयोग करना चाहते हैं, या इससे भी बदतर, उन लोगों का उपयोग करके पीआर शुरू करें ... केवल यह पता लगाने के लिए कि परियोजना सी पर है ++03.

अकेले लैम्ब्डा की कमी एक बहुत बड़ी समस्या है जो मुझे यहाँ दिखाई नहीं दे रही है।
कई बार, गोडोट को डेटा की एक अस्थायी सूची को स्टोर करना पड़ता है, फिर उस पर पुनरावृति करना होता है।
उन मामलों में से हर एक में, इसे "for_each" या इसी तरह की संरचना के रूप में किया जा सकता है जो स्वयं को पुनरावृत्त करता है, कोड को एक बड़ी मात्रा में सरल बनाता है, स्मृति उपयोग को कम करता है, और प्रदर्शन में सुधार करता है, लैम्ब्डा को रेखांकित/अनुकूलित करने के लिए धन्यवाद। (और यह सी ++ 11 है, हर जगह इस्तेमाल किया जाता है)। लिंक्ड सूची पर सभी सामान्य लूपों के लिए वही सटीक बात।

मूव ऑपरेटर बेहतर डेटा संरचनाओं की भी अनुमति देंगे, जो वर्तमान बिल्कुल भयानक लोगों को कुछ बेहतर अनुकूलित द्वारा प्रतिस्थापित कर सकते हैं।

स्ट्रिंग डेटाटाइप (जैसे "mystring" _hs) या इसी तरह, हमें कोड में हर जगह हैश स्ट्रिंग फैलाने का एक अच्छा तरीका दे सकता है, जिससे स्ट्रिंग जांच (स्क्रिप्ट और ईवेंट कोड में बहुत आम) बहुत तेज़ हो जाती है।

यहां तक ​​​​कि अगर std :: थ्रेड का उपयोग नहीं किया जाता है (मुझे लगता है कि यह एक बहुत ही भयानक अमूर्तता है), एसटीडी परमाणु पुस्तकालय अद्भुत है, और अत्यंत उपयोगी है। एसटीडी::परमाणुऔर पसंद।

और इस बारे में बात भी नहीं करते हैं कि लोगों को सी ++ 03 के लिए कितना मजबूर करना परियोजना को नुकसान पहुंचाता है, जब लोग आधुनिक पुस्तकालयों को आसानी से एकीकृत नहीं कर सकते हैं, क्योंकि गोडोट सी ++ के पुराने संस्करण पर एकमात्र गैर-छोड़े गए ओपन सोर्स सी ++ प्रोजेक्ट की तरह है ( जहां तक ​​मुझे मालूम है)

व्यक्तिगत रूप से, मैं रूढ़िवादी होने और पूर्ण नवीनतम सी ++ मानक पर नहीं जाने से सहमत हूं, लेकिन मुझे लगता है कि सी ++ 11 की तरह कुछ सी ++ 14 की कुछ सत्यापित सुविधाओं के साथ कुछ ऐसा है जो सबसे अच्छा काम करेगा, और गोडोट में काफी सुधार करेगा। सी ++ 11-14 अवास्तविक इंजन के लिए काफी अच्छा है, जो पीएस 4, एक्सबॉक्स, स्विच, पीसी, लो एंड पीसी, एंड्रॉइड, आईओएस, और एचटीएमएल 5 वेबसैम्प को पोर्ट करता है। मैं नहीं देखता कि गोडोट को खुद को सीमित क्यों करना चाहिए जब वह बहुत कम मात्रा में प्लेटफॉर्म का समर्थन करता है।

स्ट्रिंग डेटाटाइप (जैसे "mystring" _hs) या इसी तरह, हमें कोड में हर जगह हैश स्ट्रिंग फैलाने का एक अच्छा तरीका दे सकता है, जिससे स्ट्रिंग जांच (स्क्रिप्ट और ईवेंट कोड में बहुत आम) बहुत तेज़ हो जाती है।

साथ ही यह आपको स्विच जैसी चीजों में उनका उपयोग करने देता है। जैसे मैंने एक फ्लाईवेट स्ट्रिंग कार्यान्वयन को बदलने के लिए वर्षों पहले एक एटम प्रकार बनाया था:
https://github.com/OvermindDL1/OverECS/blob/master/StringAtom.hpp

इसमें 32-बिट (5 वर्ण अधिकतम, या 6 यदि आप तालिका को थोड़ा रिकोड करते हैं), और 64-बिट संस्करण (10 या 12 वर्ण अधिकतम, इस पर निर्भर करता है कि तंग एन्कोडिंग चुनना है या नहीं)। यह पूरी तरह से प्रतिवर्ती है, संकलन-समय पर या गतिशील रूप से किसी भी दिशा में रन-टाइम पर होता है, स्विच आदि में पूरी तरह से उपयोग योग्य ... आदि ... उस फ़ाइल का उदाहरण उपयोग:

switch(blah) {
  case "UPDATE"_atom64: ... pass
  case "PHYSUPDATE"_atom64: ... pass
  ...
}

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

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

कम से कम मैं कहूंगा कि सी ++ 14 गोडोट मानक होना चाहिए। सी ++ 17 अच्छा होगा (कुछ नए कोड में कुछ बहुत उपयोगी प्रदर्शन संवर्द्धन), लेकिन सी ++ 14 अब सार्वभौमिक न्यूनतम है। लेकिन निश्चित रूप से जीसीसी/क्लैंग/विजुअलस्टूडियो और जो कुछ भी अब सी ++ 17 जुर्माना (और यहां तक ​​​​कि सी ++ 20 के बड़े हिस्से) का समर्थन करता है, सी ++ 17 भी अच्छा लगता है। मैं शायद अभी भी 'जस्ट-इन-केस' के लिए सी ++ 14 का विकल्प चुनूंगा।

@ OvermindDL1 वह एटम चीज कमाल की है, इसे प्यार करो। यह निश्चित रूप से गोडोट के साथ वास्तव में अच्छी तरह से फिट होगा, जहां वह उस सटीक चीज को काफी बार कर रहा है।

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

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

अकेले लैम्ब्डा की कमी एक बहुत बड़ी समस्या है जो मुझे यहाँ दिखाई नहीं दे रही है।

क्या मैं अकेला हूं जो सोचता है कि लैम्ब्डा ज्यादातर मामलों में कोड को पढ़ना मुश्किल बनाता है?

@ फ़ैलेस : नहीं, आप अकेले नहीं हैं, मुझे लगता है कि लैम्ब्डा को पढ़ने में मुश्किल हो रही है, एक कारण है कि एकियन ने सी ++ संस्करण को ऊपर नहीं उठाया है।

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

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

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

कुछ ऐसा वास्तविक उदाहरण जिसे मैंने पहले ही लागू कर दिया है:

//old linked list iteration
while (scenario->instances.first()) {
            instance_set_scenario(scenario->instances.first()->self()->self, RID());
        }
//new (just abstracts above)
scenario->instances.for_each([]( RID& item  ){
    instance_set_scenario(item, RID());
});

यह दूसरा मामला भी है, कई बार दोहराया गया

//old. Note the 1024 array, wich is hard size, and is wasting memory

int culled = 0;
Instance *cull[1024];
culled = scenario->octree.cull_aabb(p_aabb, cull, 1024);
for (int i = 0; i < culled; i++) {

    Instance *instance = cull[i];
    ERR_CONTINUE(!instance);
    if (instance->object_ID == 0)
        continue;

    instances.push_back(instance->object_ID);
}

//NEW. not implemented yet. 0 memory usage, can be inlined, and doesnt have a maximum size. 
//Its also shorter and will be faster in absolutely every case compared to old version.

scenario->octree.for_each_inside_aabb(p_aabb, [](Instance* instance){       
    ERR_CONTINUE(!instance);
    if (instance->object_ID == 0)
        continue;
    instances.push_back(instance->object_ID);
});

कुछ ऐसा वास्तविक उदाहरण जिसे मैंने पहले ही लागू कर दिया है:

निश्चित नहीं है कि यहाँ क्या लाभ है ...

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

@ vblanco20-1 ठीक है, मैं खुद को समझाने की कोशिश करूंगा।
लोग आमतौर पर चीजें लिख देते हैं जैसे:

my_arr.push(
    [par1, par2, par3]{
      somefunc(par1, par2, par3);
    }
);

और फिर, कुछ अन्य जगहों पर:

func = my_arr.front();
func();

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

@ आपका उदाहरण सबसे खराब उदाहरण है जो आप लैम्ब्डा के साथ कर सकते हैं (और उस तरह के उपयोग को निश्चित रूप से प्रतिबंधित किया जाना चाहिए)।

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

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

यह बॉयलरप्लेट को भी कम कर रहा है और कोड वास्तव में क्या कर रहा है (लिंक की गई सूची को फिर से चालू करना) "स्पष्ट" बना रहा है। बस "पहले () -> स्वयं () -> स्वयं" से छुटकारा पाना अपने आप में एक सुधार है।

ध्यान रखें कि इसके लाभ वास्तव में अधिक उपयोग के साथ जमा होते हैं, क्योंकि आप "unordered_for_each" जैसी चीजें प्राप्त करने में सक्षम होंगे जो नोड्स को स्मृति में क्रम में पुनरावृत्त करता है (आवंटक के माध्यम से, या यदि लिंक की गई सूची शीर्ष पर संग्रहीत है एक सरणी), या "reverse_for_each"। यहां तक ​​कि "ढूंढें" या "क्रमबद्ध करें" जैसी चीजें भी। (मैं एसटीडी :: एल्गोरिदम की सिफारिश नहीं करता, कम से कम सी ++ 20 तक जब रेंज विलय हो जाते हैं। अपने डेटा संरचना के हिस्से के रूप में अपने स्वयं के एल्गोरिदम को लागू करना उपयोग करने के लिए बहुत बेहतर है)

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

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

मैं प्रदर्शन के बारे में और अधिक शोध करूँगा।

शनिवार, 8 दिसंबर, 2018 को 17:06 vblanco20-1 < नोटिफिकेशन @github.com ने लिखा:

@Faless https://github.com/Faless आपका उदाहरण इसका एक उदाहरण है
सबसे खराब आप लैम्ब्डा के साथ कर सकते हैं (और उस तरह का उपयोग निश्चित रूप से होना चाहिए
प्रतिबंधित)।

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

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

यह बॉयलरप्लेट को भी कम करता है और कोड को और अधिक "स्पष्ट" बनाता है
वास्तव में (लिंक की गई सूची को पुनरावृत्त करना)। बस छुटकारा "
first()->self()->self " अपने आप में एक सुधार है।

ध्यान रखें कि इसके लाभ वास्तव में अधिक उपयोग के साथ जमा होते हैं, जैसे
आप "unordered_for_each" जैसी चीज़ें प्राप्त करने में सक्षम होंगे जो पुनरावृत्त होती हैं
नोड्स क्रम में वे स्मृति में हैं (आवंटक के माध्यम से, या यदि
लिंक की गई सूची एक सरणी के शीर्ष पर संग्रहीत है), या "reverse_for_each"। यहां तक ​​कि चीजें
जैसे "ढूंढें" या "क्रमबद्ध करें"। (मैं std::algorithms को इतना अधिक अनुशंसा नहीं करता, at
कम से कम सी ++ 20 तक जब रेंज विलय हो जाते हैं। अपने स्वयं के एल्गोरिदम को लागू करना
आपकी डेटा संरचना के हिस्से के रूप में उपयोग करना बेहतर है)

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

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/godotengine/godot/issues/9694#issuecomment-445474001 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/ABnBbvBTxThAh0v8AfFCdGsSv2HFnEz6ks5u2_GKgaJpZM4ObOio
.

सी ++ 11 विशेषताएं जो कोडबेस की रखरखाव में सुधार करेगी:

• override और final
• लूप के लिए रेंज-आधारित
• nullptr
• दृढ़ता से टाइप की गई गणना
• explicit कीवर्ड

C++11 विशेषताएं जो जीवन की गुणवत्ता में सुधार करेंगी:

• समकोण ब्रैकेट (अब और नहीं Vector<Vector> > )

[[nodiscard]] (सी++17?) यहां देखें

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

ज्यादातर मामलों में इसका प्रदर्शन में उल्लेखनीय प्रभाव पड़ता है।

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

@ OvermindDL1 हां, सिद्धांत रूप में ऐसा ही होना चाहिए।
इसे देखें: https://twitter.com/zeuxcg/status/108578185156891432
मैंने हाल ही में सोशल मीडिया पर इस तरह के कई मामले देखे हैं। यह "शून्य लागत अमूर्तता" के रूप में नहीं है जैसा इसे करना चाहिए।

@lupoDharkael वह ट्विटर थ्रेड (एक बार जब यह अंत में लोड हो गया, पवित्र वाह ट्विटर एक भयानक इंटरफ़ेस है ... मैं इसे भूलता रहता हूं ...) केवल संकलन गति के बारे में बात करता है क्योंकि libstdc ++ में math.h C ++ 17 मोड में बड़ा है (जहां libc++ में वह समस्या नहीं है) बेहतर रनटाइम गति के लिए अधिक मात्रा में अधिभार और सुविधाओं के कारण, इसलिए कोई भी संकलन जो math.h में लाता है, में लगभग 300ms का बढ़ा हुआ संकलन समय होता है यदि नए stdlib के बजाय उस विशिष्ट पुराने stdlib का उपयोग किया जाता है। यह रनटाइम प्रदर्शन के बारे में कुछ भी नहीं बताता है (जिनमें से मैंने केवल उच्च सी ++ मोड में तेज़ देखा है, उपयोग की जाने वाली सुविधाओं के आधार पर, सबसे खराब मामलों में समान गति)। तो जहां It's not as "zero cost abstractions" as it should. सवाल है, मुझे अभी भी यकीन नहीं है कि आप क्या संदर्भित कर रहे हैं? क्या आपके पास रनटाइम प्रदर्शन के मुद्दों की वास्तविक रिपोर्ट के लिए कोई लिंक है क्योंकि आपके द्वारा लिंक किए गए धागे का इससे कोई लेना-देना नहीं है क्योंकि यह पुराने stdlib में गणित के साथ संकलन करते समय संकलन समय में केवल 300ms की वृद्धि थी (मैं हूँ मुझे यकीन नहीं है कि मैं एक संकलित वस्तु के संकलन समय में एक फ्लैट 300ms वृद्धि के मुद्दे को वैसे भी देखता हूं)?

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

मेरे पास केवल एक लैपटॉप है और इंजन के लिए सुविधाओं पर काम करने में समय लगता है क्योंकि मुझे हर बदलाव के बाद कंपाइल+लिंक प्रक्रिया के लिए इंतजार करना पड़ता है।

यदि आपके पास ccache स्थापित है, तो वृद्धिशील निर्माण प्रक्रिया में बहुत समय लिंकिंग पर खर्च होगा। आप लिंक करने के लिए ld के बजाय gold का उपयोग करके एक या दो सेकंड शेव कर सकते हैं, और lld पर स्विच करके इसे और भी अधिक अनुकूलित करना संभव है।

ओह निश्चित रूप से, मैं बैकिंग बिल्डर के रूप में ccache और निंजा दोनों के लिए पर्याप्त अच्छा नहीं कह सकता (यदि उदाहरण के लिए cmake या तो उपयोग कर रहा है), वे दोनों इतना समय बचाते हैं!

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

ढेर में एक जोड़ने के लिए:
static_assert

उदाहरण के लिए संघ SpatialMaterial::MaterialKey मानता है कि संरचना का आकार uint64_t के समान है, लेकिन जहां तक ​​​​मैं कह सकता हूं, इसे कहीं भी नहीं बताया गया है।

वहां एक static_assert(sizeof(MaterialKey) == sizeof(uint64_t)) थप्पड़ मारना चाहता था, लेकिन नहीं कर सका।

दूसरी बात यह है कि बहुत अधिक मैनुअल बॉयलरप्लेट लिखे बिना और अनावश्यक रेफ-काउंटिंग का उपयोग किए बिना विनाश पर उचित सफाई सुनिश्चित करने के लिए unique_ptr का उपयोग किया जा रहा है।

मैं अपने 2 (या 20) सेंट को गोडोट और उसके कोडबेस के लिए नए व्यक्ति के रूप में पेश करना चाहता हूं। मैं वर्तमान में गोडोट के लिए _Battle for Wesnoth_ को पोर्ट करने के प्रयास की देखरेख कर रहा हूं और उस पर काम कर रहा हूं। अब, फ्रंट एंड (संपादक और जीडीस्क्रिप्ट एपीआई) बहुत अच्छा है! कुछ खुरदुरे किनारों के अलावा, इसने अब तक हमें अच्छी गति से प्रगति करने की अनुमति दी है। लेकिन हमने यह भी सोचा था कि हम (टीम) किसी बिंदु पर बैक एंड (इंजन) के लिए पैच का योगदान देंगे। उस अंत तक, इस सप्ताह की शुरुआत में मैंने गिट रेपो को क्लोन किया और सी ++ में चारों ओर घूमना शुरू कर दिया, और ईमानदारी से ... मैं थोड़ा निराश हूं।

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

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

for(std::vector<T>::iterator foo = container.begin(); foo != container.end(); ++foo) {}

जो गन्दा है! जिन मामलों में हमें वास्तव में एक पुनरावर्तक की आवश्यकता होती है, हमने यह किया:

for(auto foo = container.begin(); foo != container.end(); ++foo) {}

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

ज्यादातर मामलों में हम इसके बजाय केवल श्रेणी-के लिए स्विच करेंगे:

for(const auto& foo : container) {}

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

रेंज-फॉर लूप में auto का उपयोग करने से यहां एक अतिरिक्त लाभ भी होता है। यदि आप कभी भी कंटेनर के प्रकार को बदलते हैं तो यह अपडेट करने के लिए आपको याद रखने वाली एक कम चीज़ बनाता है! मैं वास्तव में जुआन के तर्क को नहीं समझ सकता कि ये चीजें आपके कोड को कम पठनीय या समझने में कम आसान बनाती हैं। मेरे लिए, यह ठीक विपरीत है।

स्टेट ऑफ गोडोट वीडियो में उन्होंने लैम्ब्डा का भी जिक्र किया। फिर, उनका दुरुपयोग करना निश्चित रूप से संभव है, लेकिन वे एक अविश्वसनीय रूप से उपयोगी उपकरण भी हैं! सी ++ 11 का उपयोग करने से पहले मैंने वेस्नोथ के कोडबेस में देखा एक सामान्य प्रतिमान यहां दिया गया है:

struct sort_helper {
    operator()(const T& a, const T& B) {
        return a < b;
    }
}

void init() const {
    std::vector<T> foo;
    foo.push_back(T(1));
    foo.push_back(T(2));
    foo.push_back(T(3));

    std::sort(foo.begin(), foo.end(), sort_helper);
}

लंबा, गन्दा, कोड ब्लोट। और यहाँ हमने C++ 11 के साथ प्रयोग किया है:

void init() const {
    std::vector<T> foo {
        T(1),
        T(2),
        T(3),
    };

    std::sort(foo.begin(), foo.end(), [](const T& a, const T& b) { return a < b; });
}

बस यही सबसे आम मामला है! और हाँ, मुझे पता है कि आप टी के लिए operator< भी लागू कर सकते हैं और std::sort डिफ़ॉल्ट रूप से इसका उपयोग करता है, लेकिन यह मेरी बात को दर्शाता है। दोबारा, हो सकता है कि यह केवल आधुनिक सी ++ के साथ केवल सीखा और लगभग विशेष रूप से काम कर रहा हो, लेकिन मुझे लगता है कि auto , रेंज-फॉर, और लैम्ब्डा जैसे उपकरणों को अनदेखा करना जहां उपयुक्त हो पैर में खुद को गोली मार रहा है।

जो मुझे मेरे अगले बिंदु पर ले जाता है। मैंने देखा है कि गोडोट एसटीएल के बजाय आंतरिक रूप से अपने स्वयं के कई कस्टम प्रकारों का उपयोग करता है। यदि आपकी चिंता auto जैसी चीजों के संबंध में कोड पठनीयता है, तो एसटीएल वाले पर कस्टम कोर प्रकारों का उपयोग करना बिल्कुल हानिकारक है! कुछ दिनों पहले, मैं कोडबेस के माध्यम से ब्राउज़ कर रहा था और बहुत सारे कोड इस तरह दिख रहे थे:

container.push_back(T(args));

अब, यह अक्षम है। push_back (कम से कम std::vector के संदर्भ में) एक कॉन्स संदर्भ लेता है; इसलिए, यह ऑपरेटर एक अनावश्यक प्रतिलिपि में परिणत होता है। मैं उन्हें emplace_back का उपयोग करने के लिए एक पैच बनाना चाहता था ... लेकिन तब मुझे एहसास हुआ कि पूरा कोडबेस कस्टम कंटेनर प्रकारों का उपयोग कर रहा था

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

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

इससे भी बड़ा मुद्दा यह है कि यह प्रवेश में बाधा उत्पन्न करता है। मैंने गोडोट कोडबेस को सी++ एसटीएल प्रकारों की अपेक्षा करते हुए देखा। उन साधनों को नहीं खोजने का मतलब है कि मुझे या किसी और को अब यह जानने की जरूरत है कि इंजन किस प्रकार प्रदान करता है और प्रत्येक के साथ कौन सा एपीआई जाता है। मुझे std::map चाहिए? नहीं, मुझे dictionary का उपयोग करने की आवश्यकता है। यह केवल अनुरक्षकों के लिए जीवन को कठिन बनाता है और नए योगदानकर्ताओं के लिए चीजों को जटिल बनाता है। और वास्तव में, वह कोड नहीं है जो एक चीज़ जैसा दिखता है लेकिन वास्तव में दूसरा है... अपठनीय?

लगभग एक साल पहले, जैसा कि हमने वेस्नोथ की 1.14 रिलीज़ को बंद कर दिया और स्टीम पर लॉन्च किया, मैंने एक कस्टम कंटेनर प्रकार को खत्म करने के लिए एक रिफैक्टरिंग प्रोजेक्ट शुरू किया जो अनिवार्य रूप से std::list था, सिवाय इसके कि erase() का उपयोग करने से अमान्य नहीं हुआ पुनरावर्तक यहाँ प्रश्न में सिद्धांत प्रतिबद्ध है । इसके बाद इसे सही करने के लिए और काम करने की आवश्यकता थी, लेकिन परिणाम कोड था जो बहुत सरल, समझने में आसान और कम अपारदर्शी था।

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

मुझे पता है कि मेरी राय का यहाँ बहुत मतलब नहीं है, लेकिन मुझे लगा कि मैं अपने विचार किसी ऐसे व्यक्ति के दृष्टिकोण से दूंगा जिसने एक बड़े C++ कोडबेस के साथ काम किया है जो C++03 से आधुनिक C++ में चला गया है। यह बहुत काम है, लेकिन लंबी अवधि में मुझे लगता है कि यह इसके लायक है।

बड़े पैमाने पर टेक्स्टवॉल क्षमा करें!

@Vultraz पूरी तरह से सहमत हैं।

जबकि मेरे पास C++ के साथ (लगभग कोई भी) अनुभव नहीं है, GDNative + C++ के साथ कुछ समय काम करने के बाद मैं आपके विचार साझा करता हूं।

अभी कुछ दिन पहले मैंने रेडिट पर पोस्ट किया था " क्या गोडोट में योगदान देना सी ++ सीखने का एक अच्छा तरीका है? " धागा:

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

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

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

@Vultraz एक अच्छी तरह से व्यक्त लेखन, बहुत अच्छा पढ़ा, इसके लिए धन्यवाद। ऐसा दृष्टिकोण सुनना अच्छा लगता है।

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

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

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

मुझे नहीं पता कि आपने इसे देखा है या नहीं, लेकिन जुआन ने जीडीसी में एक वार्ता की जिसे ऑनलाइन रखा गया था: https://www.youtube.com/watch?v=C0szslgA8VY
प्रश्नोत्तर के दौरान अंत में वह इस बारे में निर्णय लेने के बारे में कुछ बात करता है।
यह एक अच्छी घड़ी है।

GDNative पर ऊपर दी गई प्रतिक्रियाओं के लिए, सामान्य लोगों, GDNative एक हालिया जोड़ है जो एक विशेष आवश्यकता को पूरा करता है, यह इस बात का संकेत नहीं है कि मुख्य उत्पाद कैसे संरचित और निर्माण किया जाता है।
एक मॉड्यूल (https://docs.godotengine.org/en/3.1/Development/cpp/custom_modules_in_cpp.html) बनाने का प्रयास करें, हाँ इसके लिए आपके परिवर्तनों को मूल उत्पाद में संकलित करने की आवश्यकता है, जिसे GDNative हल करने का प्रयास करता है, लेकिन यह देता है आपको इस बात की बेहतर समझ है कि इंजन वास्तव में कैसे संरचित है। ऊपर दिए गए कई तर्क GDNative की कमियां हैं, स्वयं Godot की नहीं।
मुझे एक गतिशील मॉड्यूल समाधान के लिए अच्छा लगेगा जो मुझे उसी तरह मॉड्यूल बनाने की अनुमति देता है जैसे हम स्थिर मॉड्यूल बना रहे हैं, शायद किसी दिन यह संभव होगा, लेकिन तब तक GDNative पर्याप्त है।

@Vultraz @mnn मैं वास्तव में एसटीएल कंटेनरों के बारे में बिंदु देख सकता हूं, लेकिन पूरी तरह से क्योंकि कुछ कार्यान्वयन (एमएसवीसी, ज्यादातर) में डीबग मोड में बेहद धीमी गति से प्रदर्शन होता है। लेकिन कोई केवल ईए के एसटीएल का उपयोग कर सकता है और अच्छा हो सकता है (उनका तेज और पोर्टेबल है)।

इसके अलावा: मैंने व्यक्तिगत रूप से आरएआईआई की कमी को सबसे अधिक परेशान करने वाला पाया। पूरे कोड में अनावश्यक रूप से की जाने वाली मैन्युअल सफाई की मात्रा अजीब है, क्योंकि RAII C++ 11 के लिए नया नहीं है।

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

यह निश्चित रूप से सच है, लेकिन इंजन की तुलना में GDNative अधिक उपयोगकर्ता के अनुकूल नहीं होना चाहिए, क्योंकि GDNative का उपयोग "स्क्रिप्ट" बनाने के लिए किया जाता है, इसलिए ऐसे दर्शकों को लक्षित किया जाता है जिनके पास कम C++ कौशल होने की उम्मीद होती है जो कि आंतरिक में डूबने के इच्छुक हैं इंजन?

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

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

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

@ एमएनएन , जीडीएनेटिव सी आधारित मॉड्यूल के निर्माण को गतिशील पुस्तकालयों के रूप में सक्षम करने के लिए बनाया गया था ताकि आपको पूरे इंजन को पुन: संकलित करने की आवश्यकता न हो। उसके ऊपर कई भाषा बाइंडिंग बनाए गए थे ताकि आप सी ++, पायथन, जंग, आदि में मॉड्यूल लिख सकें, जिसे फिर से पूरे इंजन को संकलित करने की आवश्यकता नहीं थी।

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

तो हाँ, इसने संकलन और परिनियोजन के दृष्टिकोण से मॉड्यूल बनाना बहुत आसान और सरल बना दिया है। लेकिन अपने दृष्टिकोण के कारण इसकी सीमाएँ हैं। जब आप उन सीमाओं के भीतर रहते हैं तो GDNative में C++ कोड लिखना सरल रह सकता है, क्योंकि जहाँ तक आप जिस मॉड्यूल के लिए मॉड्यूल बना रहे हैं उसका विषय सरल है।

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

यह भी ध्यान दें कि GDNative GDScript कोड को फिर से लिखने के एक तरीके के रूप में था जिसे अधिक प्रदर्शन करने की आवश्यकता है। परिणामस्वरूप आप इंजन के अंदर कुछ भी एक्सेस नहीं कर सकते हैं, जिसमें GDScript के पास या तो एक्सेस नहीं है (जैसे OpenGL)

नवीनतम कोरआउट समर्थन के बारे में क्या है, अर्थात co_await ()? प्रोजेन के नजरिए से, यह बहुत बड़ा है।

Coroutine समर्थन C++20 मानक का हिस्सा है, जिसे रिकॉर्ड के लिए अभी तक अंतिम रूप नहीं दिया गया है।

मुझे इसमें शामिल होने की अनुमति दें, मैं वर्तमान में 3D स्थानिक संपादक के लिए उन्नत (थिंक सोर्स हैमर एडिटर) ब्रश/सीएसजी टूल लिख रहा हूं और ऑटो को अनुमति नहीं देने के बारे में यह बात वास्तव में मेरे लिए भ्रमित करने वाली है। कभी-कभी _ऑटो का भी उपयोग स्पष्ट_ हो सकता है। निम्न पर विचार करें:

मैं SpatialEditorViewportContainer के अंदर हूं और मैं SpatialEditor प्राप्त करना चाहता हूं, जो मूल पदानुक्रम में तीन आइटम है (इससे पहले कि कोई यह बताए कि व्यूपोर्ट कंटेनर से SpatialEditor तक पहुंचने के बेहतर तरीके हैं, कृपया विचार करें कि मैंने इस कोडबेस को देखना शुरू कर दिया है) बीता हुआ कल)

auto sp = Object::cast_to<SpatialEditor>(get_parent()->get_parent()->get_parent());

जैसा कि आप देख सकते हैं, डायनामिक डाउनकास्ट _पहले से ही SP_ के प्रकार को स्पष्ट रूप से बताता है। ऑटो के बिना, मुझे निरर्थक कबाड़ लिखना होगा जैसे:

SpatialEditor sp = Object::cast_to<SpatialEditor>(get_parent()->get_parent()->get_parent());

कृपया, भगवान के प्यार के लिए, ऑटो के उपयोग की अनुमति दें!

जिस विषय पर सी ++ मानक का उपयोग करना है: प्रस्तावित प्रतिबिंब और सी ++ 20 और उससे आगे की मेटा क्लास विशेषताएं मैक्रो अव्यवस्था को कम करने के लिए वास्तव में उपयोगी होंगी जैसे

GDCLASS(SpatialEditorViewportContainer, Container);

साथ ही, मैं यह प्रतिध्वनित करना चाहूंगा कि इन प्रतिबंधों ने मुझे वास्तव में योगदान देने के मेरे निर्णय का दूसरा अनुमान लगाया। 2012 के आसपास, मैंने खुद को सी ++ 11 सिखाया और इस मानक का उपयोग करने में सक्षम नहीं होने के कारण चेहरे पर एक थप्पड़ जैसा लगता है। सी ++ 11 और सी ++ 03 पूरी तरह से अलग-अलग भाषाएं हैं, और सी ++ को सीखना मुश्किल है, पढ़ना मुश्किल है और लिखना मुश्किल है, सी ++ 03 (या 98 बल्कि) की गलती है। बनाए रखने और पठनीयता के लिए कम से कम C++11 या 14 का उपयोग नहीं करना _detrimental_ है। मैं सी ++ 11 के साथ बड़ा हुआ और प्रोजेक्ट लीड स्पष्ट रूप से नहीं था (जब उन्होंने 2007 में गोडोट पर काम करना शुरू किया, तो मैं 12 साल का था), इसलिए मुझे लगता है कि यह वरीयता और बेबी डक सिंड्रोम का मामला है। मुझे लगता है कि सी ++ 11 का उपयोग न करना सिर्फ मेरे जैसे लोगों की कीमत पर पुराने स्कूल (उर्फ, भयानक) सी ++ के अभ्यस्त लोगों को आराम देने के लिए है, जिन्होंने आधुनिक सी ++ सीखने के लिए समय निकाला।

जैसे-जैसे समय बीतता है, मेरे जैसे अधिक से अधिक जूनियर प्रोग्रामर आधुनिक सी ++ 11 और उससे आगे बढ़ेंगे और इस तथ्य को पाएंगे कि परियोजना हमेशा के लिए एक ऐसे लैन्यूज में फंस गई है जिसमें लैम्ब्डा भी निराशाजनक नहीं है।

संक्षेप में: C++11 या बस्ट!

स्पष्ट होने के लिए, मैं एसटीएल के उपयोग की वकालत नहीं करता। अपने स्वयं के कंटेनरों को रोल करना ठीक है, लेकिन लैम्ब्डा और ऑटो जैसी सुविधाओं को अस्वीकार करना असिन लगता है।

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

हम केवल @hpvb पर हमारी सहमति के आधार पर उनके द्वारा लिखे जा रहे दिशानिर्देशों को अंतिम रूप देने के लिए समय की प्रतीक्षा कर रहे हैं, और फिर हम उन दिशानिर्देशों के बारे में कुछ और चर्चा कर सकते हैं जब वे प्रकाशित हो जाएं। तब तक, यह रचनात्मक नहीं है।