Godot: GDScript: विविध कार्य (तर्कों/varargs की चर संख्या)

बस इसलिए मैं इसे सही ढंग से समझ रहा हूं, क्या हम रूबी के स्प्लैट ऑपरेटर की तरह कुछ बात कर रहे हैं?

पिछली बार जब मैंने जीडीस्क्रिप्ट के लिए कुछ सुझाया था तो इसे बंद कर दिया गया था और रेडज़ द्वारा बहुत जल्दी छोड़ दिया गया था, इसलिए बस एक चेतावनी (मैं हां बीटीडब्ल्यू, जीएल मतदान कर रहा हूं!)

@ LikeLakers2 एक संक्षिप्त रूप से, हाँ बिल्कुल।

@girng वैसे मुझे उम्मीद है कि वास्तव में सुझाई गई सुविधा पर निर्भर करता है। ईमानदारी से, यहां तक ​​कि एक के लिए यह और भी अच्छा है ; मैं इसके बिना रह सकता हूं, लेकिन यह कुछ सामान्य मामलों को थोड़ा अच्छा बना देगा।

आह, ठीक है तो इस विचार को मेरा समर्थन मिलता है। वह स्प्लैट ऑपरेटर रूबी में बहुत उपयोगी है।

उच्च स्तरीय मल्टीप्लेयर rpc फ़ंक्शन पहले से ही ऐसा करता है। क्या जिस तरह से यह किसी तरह से सुलभ है?

क्या यह एक सरल, कस्टम लॉगिंग फ़ंक्शन को कार्यान्वित करने में सक्षम होना चाहता है।

हम पहले से ही निम्नलिखित कर सकते हैं:

print("Score: ", score)

लेकिन निम्न कार्य करने में सक्षम होना अच्छा होगा:

_log("Score: ", score)

जहां लॉग का उत्पादन होगा:

[MyClass] Score: 500

क्या यह एक सरल, कस्टम लॉगिंग फ़ंक्शन को कार्यान्वित करने में सक्षम होना चाहता है।

हम पहले से ही निम्नलिखित कर सकते हैं:

print("Score: ", score)

लेकिन निम्न कार्य करने में सक्षम होना अच्छा होगा:

_log("Score: ", score)

जहां लॉग का उत्पादन होगा:

[MyClass] Score: 500

क्या मैं इसे प्लस वन कर सकता हूं ... मैं एक प्रिंट फ़ंक्शन भी बनाना चाहता हूं जो सामान्य रूप से पाइथन (स्ट्रिंग्स और नंबर इत्यादि) की तरह प्रिंट करेगा क्योंकि मुझे प्रिंटिंग असहनीय लगती है लेकिन शायद अन्य लोग इसे पसंद करते हैं

मुझे लगता है कि यह वास्तव में gdscript में एक अद्भुत विशेषता होगी। एक सरणी के बिना कई तर्कों को पारित करने की क्षमता होने से कस्टम लॉग फ़ंक्शंस जैसे मामलों में बहुत मददगार होगा!

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

एक्सपोज़ उद्धरणों में है क्योंकि तकनीकी रूप से सब कुछ एक अर्थ में उजागर होता है।

मुझे लगता है कि यह सुविधा वास्तव में आवश्यक है क्योंकि कुछ फ़ंक्शन पहले से ही varargs लेकिन हमारे पास उन्हें ओवरराइड करने का कोई तरीका नहीं है।

मुझे gdscript में varargs पसंद हैं। विचार करना:

func rpc_game_info(node:Node, method:String, args:vararg):
    for id in players:
        node.rpc_id(id, method, args)

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

क्या किसी सरणी को अनियंत्रित/फैलाने/विस्तार करने का कम से कम एक तरीका है? दूसरे शब्दों में, क्या ऐसा कुछ काम करने का कोई तरीका है ?:

func foo(bar: String, args = []):
  baz(bar, ...args)

@rosshadden आप Object::callv("method", [..args]) उपयोग कर सकते हैं

मैं 2012 से वेबसाइटों, बैकएंड, गेम के लिए बहुत सारे सी/सी ++/जेएस कोड लिख रहा हूं, और मुझे ऐसी स्थिति याद नहीं है जहां मुझे पूरी तरह से varargs का उपयोग करने की आवश्यकता है। डीबग संदेशों को लॉग करने के लिए यह एक अच्छी सुविधा है, लेकिन इसके अलावा, मुझे इसकी कोई आवश्यकता नहीं दिख रही है। वास्तव में, मैं अब एक साल से अधिक समय से गोडोट गेम बना रहा हूं, और मैं अब जहां gdscript से काफी खुश हूं: यह वह सब कुछ करता है जो मुझे चाहिए और बहुत कुछ। भाषा में अतिरिक्त घंटियाँ और सीटी जोड़ने में समय बिताने के बजाय, मैं मौजूदा कार्यक्षमता की दक्षता में सुधार के लिए वोट देना चाहूंगा। सादर, - अलेक्जेंड्रे खारलामोव

मैं 2012 से वेबसाइटों, बैकएंड, गेम के लिए बहुत सारे सी/सी ++/जेएस कोड लिख रहा हूं, और मुझे ऐसी स्थिति याद नहीं है जहां मुझे पूरी तरह से varargs का उपयोग करने की आवश्यकता है। डीबग संदेशों को लॉग करने के लिए यह एक अच्छी सुविधा है, लेकिन इसके अलावा, मुझे इसकी कोई आवश्यकता नहीं दिख रही है। वास्तव में, मैं अब एक साल से अधिक समय से गोडोट गेम बना रहा हूं, और मैं अब जहां gdscript से काफी खुश हूं: यह वह सब कुछ करता है जो मुझे चाहिए और बहुत कुछ। भाषा में अतिरिक्त घंटियाँ और सीटी जोड़ने में समय बिताने के बजाय, मैं मौजूदा कार्यक्षमता की दक्षता में सुधार के लिए वोट देना चाहूंगा। सादर, - अलेक्जेंड्रे खारलामोव

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

@mitchcurtis कृपया, ऐसी टिप्पणी करने से बचें जो चर्चा किए गए मुद्दे से संबंधित नहीं हैं। दूसरों को नीचा दिखाने से चर्चा में सकारात्मक योगदान नहीं होता है।

एक सुविधा को कैसे कॉल किया जा रहा है कि कई लोग "घंटियाँ और सीटी" मांग रहे हैं, दूसरों को कम नहीं कर रहे हैं? मेरी टिप्पणी सीधे तौर पर इस मुद्दे से संबंधित है - यह एक ओपन सोर्स प्रोजेक्ट है और बहुत सारे काम उन योगदानकर्ताओं से हैं जो चुनते हैं कि वे क्या काम करना चाहते हैं।

आइए इसे पलट दें: क्या अलेक्जेंड्रे की टिप्पणी चर्चा में सकारात्मक योगदान देती है? क्या उसके लिए यह बेहतर नहीं होता कि वह एक विशिष्ट विशेषता ढूंढे जिसमें वह रुचि रखता था और दूसरों की चाहत को कम करने के बजाय उसके लिए समर्थन दिखाता था?

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

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

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

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

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

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

उचित अंक।

मुझे लगता है कि इस मुद्दे के लिए वोटों की मात्रा अपने लिए बोलती है, लेकिन मैं भविष्य में इस तरह की टिप्पणी करने से बचने की कोशिश करूंगा।

मैं 2012 से वेबसाइटों, बैकएंड, गेम के लिए बहुत सारे सी/सी ++/जेएस कोड लिख रहा हूं, और मुझे ऐसी स्थिति याद नहीं है जहां मुझे पूरी तरह से varargs का उपयोग करने की आवश्यकता है। डीबग संदेशों को लॉग करने के लिए यह एक अच्छी सुविधा है, लेकिन इसके अलावा, मुझे इसकी कोई आवश्यकता नहीं दिख रही है। वास्तव में, मैं अब एक साल से अधिक समय से गोडोट गेम बना रहा हूं, और मैं अब जहां gdscript से काफी खुश हूं: यह वह सब कुछ करता है जो मुझे चाहिए और बहुत कुछ। भाषा में अतिरिक्त घंटियाँ और सीटी जोड़ने में समय बिताने के बजाय, मैं मौजूदा कार्यक्षमता की दक्षता में सुधार के लिए वोट देना चाहूंगा। सादर, - अलेक्जेंड्रे खारलामोव

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

एक उदाहरण: => विरासत

class A
_init(arg0, arg1, arg2)

class B extends A
_init(arg0, arg1, arg2, arg4).(arg0, arg1, arg2)

अब कल्पना करें कि आपको कक्षा ए की तर्क सूची बदलनी है। आपको हर वर्ग को ढूंढना होगा जो इस वर्ग को विरासत में मिला है, जो खतरनाक है। इस तथ्य के बावजूद कि कोई नामित तर्क नहीं है, इसलिए तर्क सूची को मिलाना अपने आप में एक समस्या है

एक और उदाहरण कॉलबैक हैं, मुझे लगता है कि यह कोड के बिना जाता है ...

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

संपादित करें: बस एक और अच्छा उदाहरण महसूस किया गया है कि Godots का अपना Object.call() तरीका है;)

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

जैसा कि इस धागे में पहले संदेश में कहा गया है, पूरी चर्चा वास्तव में वाक्यात्मक चीनी के बारे में है जिसे पहले से ही एक वैरिएडिक फ़ंक्शन को लागू करने के स्थान पर एक सरणी का उपयोग करके आसानी से लागू किया जा सकता है।

@alexkh

जैसा कि इस धागे में पहले संदेश में कहा गया है, पूरी चर्चा वास्तव में वाक्यात्मक चीनी के बारे में है जिसे पहले से ही एक वैरिएडिक फ़ंक्शन को लागू करने के स्थान पर एक सरणी का उपयोग करके आसानी से लागू किया जा सकता है।

जैसा कि पहले Geequlim द्वारा कहा गया था , यह न केवल वाक्यात्मक चीनी है, बल्कि वास्तव में varargs का उपयोग करने वाले कार्यों को ओवरराइड करने की क्षमता को तोड़ता है, जैसे rpc , emit_signal , ... मैं बस उस मुद्दे में भाग गया जब मैंने अपनी जरूरतों के लिए rpc को बदलने की कोशिश की।

हाँ, यह वाक्यात्मक चीनी है। हालांकि, वाक्यात्मक चीनी होने का मतलब यह नहीं है कि वे अच्छे या बुरे हैं। नियंत्रण प्रवाह जैसे if , else और यहां तक ​​कि फ़ंक्शंस केवल GOTO शीर्ष पर केवल चीनी हैं, यदि आप करेंगे। इसका मतलब यह नहीं है कि आप उन्हें नहीं चाहते हैं।

कभी-कभी, थोड़ी सी वाक्यात्मक चीनी जोड़ने से कोड तरीका अधिक पठनीय हो जाता है और अतिरिक्त जटिलता के लायक होता है।

लेकिन वास्तव में उन कार्यों को ओवरराइड करने की क्षमता को तोड़ देता है जो varargs का उपयोग करते हैं, जैसे rpc, emit_signal

जिज्ञासु, कि वे कार्य varargs का उपयोग करते हैं न कि सरणियों का। ;-) ध्यान दें कि गोडोट एपीआई स्वयं विभिन्न स्थानों पर varargs का उपयोग कैसे करता है? इसका शायद कोई कारण है।

यह भी उत्सुक है कि कितनी भाषाएं विविध कार्यों को लागू करती हैं। हो सकता है कि वे उपयोगी हों, भले ही उन्हें "सरणी का उपयोग करके आसानी से कार्यान्वित किया जा सके"?

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

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

मैं यह नहीं आंक सकता कि यह जीडीस्क्रिप्ट बैकएंड में कितनी जटिलता जोड़ देगा, और इस प्रकार जटिलता ट्रेडऑफ़ के बारे में बहुत कुछ नहीं कह सकता है, लेकिन उन्हें लिखना क्योंकि वे "सिर्फ वाक्य रचनात्मक चीनी" गलत हैं, क्योंकि इसके बारे में कहा जा सकता है बहुत सी चीज़ें।

दोबारा, ध्यान दें कि गोडोट में कितनी चीजें उनका उपयोग करती हैं।

हाँ, यह वाक्यात्मक चीनी है। हालांकि, वाक्यात्मक चीनी होने का मतलब यह नहीं है कि वे अच्छे या बुरे हैं। नियंत्रण प्रवाह जैसे if , else और यहां तक ​​कि फ़ंक्शंस केवल GOTO शीर्ष पर केवल चीनी हैं, यदि आप करेंगे। इसका मतलब यह नहीं है कि आप उन्हें नहीं चाहते हैं।

GOTO प्रतिस्थापित नहीं करता है, क्योंकि यह एक बिना शर्त छलांग है। क्या आप भी एक प्रोग्रामर हैं?

लेकिन वास्तव में उन कार्यों को ओवरराइड करने की क्षमता को तोड़ देता है जो varargs का उपयोग करते हैं, जैसे rpc, emit_signal

साल में एक बार कोई न कहीं आरपीसी फ़ंक्शन को ओवरराइड करना चाहेगा। जबकि हर दिन हजारों अन्य लोग गोडोट 4 को रिलीज होते देखना चाहते हैं।

यह भी उत्सुक है कि कितनी भाषाएं विविध कार्यों को लागू करती हैं। हो सकता है कि वे उपयोगी हों, भले ही उन्हें "सरणी का उपयोग करके आसानी से कार्यान्वित किया जा सके"?

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

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

दोबारा, ध्यान दें कि गोडोट में कितनी चीजें उनका उपयोग करती हैं।

डिबग आउटपुट के लिए - हर तरह से! लेकिन अगर प्रिंट () प्रिंट ("हैलो", "वर्ल्ड) के बजाय वैरिएडिक नहीं था, तो आपको प्रिंट (["हैलो", "वर्ल्ड"]) टाइप करना होगा - बिल्कुल भी बड़ा अंतर नहीं ...

GOTO प्रतिस्थापित नहीं करता है, क्योंकि यह एक बिना शर्त छलांग है

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

C++ में एक मानक सरणी प्रकार नहीं है जो विभिन्न प्रकार के मानों को संग्रहीत कर सकता है जैसे GDscript करता है।

ठीक है, पायथन, लुआ या गो (या अन्य भाषाओं के किसी भी मेजबान) के खिलाफ बहस करें, फिर उनमें वे हैं और अभी भी विविध कार्य हैं।

लेकिन अगर प्रिंट () प्रिंट ("हैलो", "वर्ल्ड) के बजाय वैरिएडिक नहीं था, तो आपको प्रिंट (["हैलो", "वर्ल्ड"]) टाइप करना होगा - कोई बड़ा अंतर नहीं

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

परंतु...

लेकिन क्या आपने कभी C या C++ में अपना खुद का वैरिएडिक फंक्शन लिखा है?

क्या आप भी एक प्रोग्रामर हैं?

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

GOTO प्रतिस्थापित नहीं करता है, क्योंकि यह एक बिना शर्त छलांग है। क्या आप भी एक प्रोग्रामर हैं?

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

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

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

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

GOTO प्रतिस्थापित नहीं करता है, क्योंकि यह एक बिना शर्त छलांग है। क्या आप भी एक प्रोग्रामर हैं?

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

के, मैं उन लोगों का अनादर करता हूं जो मेरा समय बर्बाद करते हैं। उनका कहना था: अगर के बजाय GOTO का उपयोग क्यों न करें, और मैंने कहा कि GOTO if को प्रतिस्थापित नहीं करता है। गोटो एक सशर्त बयान नहीं है और यदि आप सशर्त बयान को बदलना चाहते हैं, तो बस टाइप करें कि आप इसे वास्तव में किससे बदलना चाहते हैं। पहले से ही कोई उदाहरण?

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

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

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

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

के, मैं उन लोगों का अनादर करता हूं जो मेरा समय बर्बाद करते हैं।

फिर मैं आपको अन्य परियोजनाओं पर अपना समय बर्बाद करने दूंगा क्योंकि अब आपको 30 दिनों के लिए @godotengine रिपॉजिटरी पर बातचीत करने से रोक दिया गया है।

हमारे पास एक आचार संहिता है , और यह निश्चित रूप से किसी के प्रति अनादर की अनुमति नहीं देती

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

मुख्य ( godotengine/godot ) ट्रैकर अब पूरी तरह से बग रिपोर्ट और पुल अनुरोधों के लिए समर्पित है, जिससे योगदानकर्ताओं को बग फिक्सिंग कार्य पर बेहतर ध्यान केंद्रित करने में मदद

यदि आप इस सुविधा प्रस्ताव में रुचि रखते हैं, तो कृपया दिए गए समस्या टेम्पलेट का अनुसरण करते हुए GIP ट्रैकर पर एक नया प्रस्ताव खोलें (यह जाँचने के बाद कि यह पहले से मौजूद नहीं है)। इस बंद मुद्दे को संदर्भित करना सुनिश्चित करें यदि इसमें कोई प्रासंगिक चर्चा शामिल है (जिसे आपको नए प्रस्ताव में सारांशित करने के लिए भी प्रोत्साहित किया जाता है)। अग्रिम में धन्यवाद!