Godot: GDScript: دوال متغيرة (عدد متغير من الوسائط / varargs)

تم إنشاؤها على ١١ فبراير ٢٠١٨  ·  29تعليقات  ·  مصدر: godotengine/godot

وصف المشكلة:
أضف دعمًا للوظائف المتغيرة إلى GDScript.

سيكون هذا في الغالب سكرًا نحويًا ، مما يؤدي إلى تحويل:

func f(args):
    for x in args:
        # Do something with x

f(["these", "are", "some", "arguments"])

إلى:

func f(args...):
    for x in args:
        # Do something with x

f("these", "are", "some", "arguments")
archived feature proposal gdscript

التعليق الأكثر فائدة

أعتقد أن هذه الميزة مطلوبة حقًا نظرًا لوجود بعض الوظائف بالفعل varargs ولكن ليس لدينا طريقة لتجاوزها.

image

ال 29 كومينتر

فقط حتى أفهم هذا بشكل صحيح ، هل نتحدث عن شيء مثل عامل splat روبي ؟

في المرة الأخيرة التي اقترحت فيها شيئًا ما لـ gdscript ، تم إيقافه وتجاهله بواسطة reduz سريعًا جدًا ، لذا مجرد تحذير (أنا أصوت نعم بالمناسبة ، gl!)

@ LikeLakers2 من نظرة موجزة ، نعم بالضبط.

girng حسنًا ، آمل أن يعتمد حقًا على الميزة المقترحة. بصراحة ، حتى هذا هو أكثر من لطيف أن يكون لديك واحدة ؛ يمكنني العيش بدونه ، لكنه سيجعل بعض الحالات الشائعة أجمل قليلاً.

آه ، حسنًا ، هذه الفكرة تحصل على دعمي. عامل تشغيل splat مفيد جدًا في Ruby.

وظيفة متعددة اللاعبين عالية المستوى rpc تقوم بهذا بالفعل. هل هي طريقة الوصول إليها بطريقة ما؟

هل ترغب في أن يكون هذا قادرًا على تنفيذ وظيفة تسجيل بسيطة ومخصصة.

يمكننا بالفعل القيام بما يلي:

print("Score: ", score)

ولكن سيكون من الجيد أن تكون قادرًا أيضًا على القيام بما يلي:

_log("Score: ", score)

حيث ينتج عن إخراج السجل:

[MyClass] Score: 500

هل ترغب في أن يكون هذا قادرًا على تنفيذ وظيفة تسجيل بسيطة ومخصصة.

يمكننا بالفعل القيام بما يلي:

print("Score: ", score)

ولكن سيكون من الجيد أن تكون قادرًا أيضًا على القيام بما يلي:

_log("Score: ", score)

حيث ينتج عن إخراج السجل:

[MyClass] Score: 500

هل يمكنني إضافة واحدة إلى هذا ... أريد أيضًا إنشاء وظيفة طباعة تطبع بشكل طبيعي كما هو الحال في Python (سلاسل وأرقام إلخ) لأنني أجد الطباعة غير مرغوب فيها ولكن ربما يحبها أشخاص آخرون

أعتقد أن هذه ستكون ميزة رائعة حقًا في gdscript. امتلاك القدرة على تمرير عدة وسيطات بدون مصفوفة سيكون مفيدًا جدًا في حالات مثل وظائف السجل المخصصة!

بينما يمكنك أن تجادل بأنه يمكنك التخلص من هذا بقدر ما تجعل اللعبة تسير (وستكون على حق تمامًا) ، ستكون ميزة مفيدة رائعة لصانعي الأدوات لـ Godot نفسه الذين يريدون "" "فضح" "" واجهة برمجة تطبيقات مرنة لمستخدميها.

فضح هو في اقتباسات لأنه من الناحية الفنية كل شيء مكشوف بمعنى ما.

أعتقد أن هذه الميزة مطلوبة حقًا نظرًا لوجود بعض الوظائف بالفعل varargs ولكن ليس لدينا طريقة لتجاوزها.

image

أنا أحب varargs في gdscript. انصح:

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

الطريقة الوحيدة التي يمكنني بها التفكير في تنفيذ هذا حاليًا ، هي نسخ ولصق السطرين في كل مكان يمكن استدعاء rpc_game_info بطريقة أخرى وتوفير طريقة args كقائمة مفصولة بفاصلة.

هل هناك على الأقل طريقة لفك / انتشار / توسيع مصفوفة؟ بمعنى آخر ، هل هناك طريقة لجعل شيء مثل هذا يعمل ؟:

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

rosshadden يمكنك استخدام Object::callv("method", [..args])

لقد كنت أكتب الكثير من أكواد C / C ++ / Js لمواقع الويب ، والخلفيات ، والألعاب منذ عام 2012 ، ولا أتذكر موقفًا احتجت فيه تمامًا إلى استخدام varargs. إنها ميزة رائعة لتسجيل رسائل تصحيح الأخطاء ، لكن بخلاف ذلك ، لا يمكنني رؤية أي حاجة إليها. في الواقع ، لقد كنت أصنع ألعاب Godot منذ أكثر من عام الآن ، وأنا سعيد جدًا بمكان gdscript الآن: إنه يفعل كل ما أحتاجه وأكثر. بدلاً من قضاء الوقت في إضافة أجراس وصفارات إضافية إلى اللغة ، أفضل التصويت لتحسين كفاءة الوظائف الحالية. مع أطيب التحيات - الكسندر خارلاموف

لقد كنت أكتب الكثير من أكواد C / C ++ / Js لمواقع الويب ، والخلفيات ، والألعاب منذ عام 2012 ، ولا أتذكر موقفًا احتجت فيه تمامًا إلى استخدام varargs. إنها ميزة رائعة لتسجيل رسائل تصحيح الأخطاء ، لكن بخلاف ذلك ، لا يمكنني رؤية أي حاجة إليها. في الواقع ، لقد كنت أصنع ألعاب Godot منذ أكثر من عام الآن ، وأنا سعيد جدًا بمكان gdscript الآن: إنه يفعل كل ما أحتاجه وأكثر. بدلاً من قضاء الوقت في إضافة أجراس وصفارات إضافية إلى اللغة ، أفضل التصويت لتحسين كفاءة الوظائف الحالية. مع أطيب التحيات - الكسندر خارلاموف

هذا لطيف ، ولكن يؤسفني أن أقول إن تصويتك لا يعني شيئًا في حين أنه من المحتمل أن يقوم المتطوع بتنفيذ هذا بمحض إرادته.

mitchcurtis من فضلك ، امتنع عن الإدلاء بتعليقات لا تتعلق بالمسألة التي تمت مناقشتها. التقليل من شأن الآخرين لا يساهم بشكل إيجابي في المناقشة.

كيف يطلق على ميزة يطلبها الكثيرون "أجراس وصفارات" لا تقلل من شأن الآخرين؟ تعليقي مرتبط بشكل مباشر بالمسألة المطروحة - إنه مشروع مفتوح المصدر والكثير من الالتزامات تأتي من مساهمين يختارون ما يريدون العمل عليه.

دعنا نغير الأمر: هل يساهم تعليق ألكسندر بشكل إيجابي في المناقشة؟ ألم يكن من الأفضل له أن يجد ميزة معينة كان مهتمًا بها ويظهر الدعم لها بدلاً من التقليل من أهمية الميزات التي يريدها الآخرون؟

لا يقتصر تطبيق الميزات على "من يريدها" و "من يمكنه تنفيذها" فقط. من المهم أيضًا معرفة "من يعتقد أنه ليس ضروريًا (ولماذا)" ، حيث يجب أن نتجنب تنفيذ الميزات إذا لم نكن في حاجة إليها بالفعل. إنها تجعل صيانة الكود أكثر صعوبة ، ويمكن أن تؤثر على الأداء ، وتقلل من إمكانيات التحسين ، وما إلى ذلك (خاصة في لغة البرمجة النصية).

لذا ، نعم ، ملاحظاتalexkh مثيرة للاهتمام ، حتى لو كنت لا توافق عليها. يمكن لأي شخص أن يأتي بعلاقات عامة مثالية لهذه الميزة غدًا ، سيظل المساهمون الأساسيون بحاجة إلى قضاء بعض الوقت في التفكير والمناقشة فيما إذا كان هذا يستحق الإضافة من وجهة نظر التصميم الفني وواجهة برمجة التطبيقات.

يعد الحفاظ على نطاق GDScript صغيرًا وسهل الصيانة أحد مبادئ التصميم الأساسية للغة. أنا لا أقول أن هذه الميزة المحددة لن تكون إضافة جيدة ، ولكن علينا أن نزن الإيجابيات والسلبيات ، مما يعني الاستماع إلى أولئك الذين لا يوافقون على الاقتراح.

لا يقتصر تطبيق الميزات على "من يريدها" و "من يمكنه تنفيذها" فقط. من المهم أيضًا معرفة "من يعتقد أنه ليس ضروريًا (ولماذا)" ، حيث يجب أن نتجنب تنفيذ الميزات إذا لم نكن في حاجة إليها بالفعل. إنها تجعل صيانة الكود أكثر صعوبة ، ويمكن أن تؤثر على الأداء ، وتقلل من إمكانيات التحسين ، وما إلى ذلك (خاصة في لغة البرمجة النصية).

لذا ، نعم ، ملاحظاتalexkh مثيرة للاهتمام ، حتى لو كنت لا توافق عليها. يمكن لأي شخص أن يأتي بعلاقات عامة مثالية لهذه الميزة غدًا ، سيظل المساهمون الأساسيون بحاجة إلى قضاء بعض الوقت في التفكير والمناقشة فيما إذا كان هذا يستحق الإضافة من وجهة نظر التصميم الفني وواجهة برمجة التطبيقات.

يعد الحفاظ على نطاق GDScript صغيرًا وسهل الصيانة أحد مبادئ التصميم الأساسية للغة. أنا لا أقول أن هذه الميزة المحددة لن تكون إضافة جيدة ، ولكن علينا أن نزن الإيجابيات والسلبيات ، مما يعني الاستماع إلى أولئك الذين لا يوافقون على الاقتراح.

نقاط عادلة.

أعتقد أن عدد الأصوات لهذه القضايا يتحدث عن نفسه ، لكنني سأحاول الامتناع عن الإدلاء بمثل هذه التعليقات في المستقبل.

لقد كنت أكتب الكثير من أكواد C / C ++ / Js لمواقع الويب ، والخلفيات ، والألعاب منذ عام 2012 ، ولا أتذكر موقفًا احتجت فيه تمامًا إلى استخدام varargs. إنها ميزة رائعة لتسجيل رسائل تصحيح الأخطاء ، لكن بخلاف ذلك ، لا يمكنني رؤية أي حاجة إليها. في الواقع ، لقد كنت أصنع ألعاب Godot منذ أكثر من عام الآن ، وأنا سعيد جدًا بمكان gdscript الآن: إنه يفعل كل ما أحتاجه وأكثر. بدلاً من قضاء الوقت في إضافة أجراس وصفارات إضافية إلى اللغة ، أفضل التصويت لتحسين كفاءة الوظائف الحالية. مع أطيب التحيات - الكسندر خارلاموف

أنا أبرمج على العديد من الألعاب والبرامج وكذلك في المنزل كما في العمل لأكثر من 15 عامًا حتى الآن ، ولكن فقط لمدة شهر واحد في godot يمكنني القول أنني أفتقد العديد من الميزات ، وهي مفتوحة بالفعل حسب طلب الميزة على وجه الخصوص هذه الميزة. أن تكون قادرًا على قبول وإرسال أعداد متغيرة من الوسائط هو أمر أحتاج إليه كثيرًا ويقلل من جودة الكود بشكل كبير إذا كان عليك حله.

مثال واحد: => الميراث

class A
_init(arg0, arg1, arg2)

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

تخيل الآن أنه عليك تغيير قائمة حجج الفئة أ. سيكون عليك أن تجد كل فئة ترث هذه الفئة ، وهذا أمر خطير. على الرغم من عدم وجود حجج محددة ، لذا فإن الخلط بين قائمة الحجج يمثل مشكلة في حد ذاته

مثال آخر هو عمليات الاسترجاعات ، أعتقد أن هذا يذهب بدون رمز ...

لذا فإن وجهة نظري هي: لا يقوم godot بكل ما تحتاجه حتى الآن ، فهو يقوم بكل ما هو بالغ الأهمية (حسنًا وبالطبع أكثر من ذلك :) ...). لكنها لم تصل بعد إلى النقطة التي يكون فيها التوقف لإضافة ميزات هو أفضل حالة. ومع ذلك ، فإن توخي الحذر بشأن ما يجب إضافته هو قرار جيد.

تحرير: أدركت للتو مثالًا جيدًا آخر هو طريقة Object.call () الخاصة بـ godots ؛)

DamKoVosh ، أخبرني من فضلك ، كم عدد سطور الكود كانت أكبر لعبة لديك؟ في كل مرة أصنع لعبة ، أشعر بخيبة أمل من قلة الترميز الذي تتطلبه. يتمثل الجزء الأكبر من العمل دائمًا في المحتوى والاختبار وتحقيق التوازن في طريقة اللعب. أنت تقول أن إعادة الكتابة أمر خطير. إذا لم يكن هناك شيء آخر ، فإن إعادة كتابة الكود الخاص بك يجعلك أفضل في كتابة واجهات وهياكل بيانات واقية من المستقبل!

كما هو مذكور في الرسالة الأولى في هذا الموضوع ، فإن المناقشة بأكملها تدور بالضبط حول السكر النحوي لشيء يمكن تنفيذه بسهولة بالفعل باستخدام مصفوفة بدلاً من تنفيذ دالة متغيرة.

تضمين التغريدة

كما هو مذكور في الرسالة الأولى في هذا الموضوع ، فإن المناقشة بأكملها تدور بالضبط حول السكر النحوي لشيء يمكن تنفيذه بسهولة بالفعل باستخدام مصفوفة بدلاً من تنفيذ دالة متغيرة.

كما ذكر Geequlim سابقًا ، هذا ليس فقط سكر نحوي ، ولكنه في الواقع يكسر القدرة على تجاوز الوظائف التي تستخدم varargs ، مثل rpc ، emit_signal ، ... لقد واجهت هذه المشكلة عندما حاولت تغيير rpc لاحتياجاتي.

نعم ، إنه سكر نحوي. ومع ذلك ، فإن كونه سكرًا نحويًا لا يعني أنه جيد أو سيئ. تدفق التحكم مثل if ، else وحتى الوظائف ليست سوى سكر فوق GOTO أيضًا إذا أردت. هذا لا يعني أنك لا تريد هؤلاء.

في بعض الأحيان ، فإن إضافة القليل من السكر التركيبي يجعل طريقة الشفرة أكثر قابلية للقراءة وتستحق التعقيد الإضافي.

ولكن في الواقع يكسر القدرة على تجاوز الوظائف التي تستخدم varargs ، مثل rpc ، emit_signal

من الغريب أن هذه الوظائف تستخدم varargs وليس المصفوفات. ؛-) لاحظ كيف أن Godot API نفسها تستخدم varargs في أماكن مختلفة؟ ربما يكون هناك سبب لذلك.

من الغريب أيضًا معرفة عدد اللغات التي تنفذ وظائف متنوعة. ربما تكون مفيدة حتى إذا كان من الممكن "تنفيذها بسهولة باستخدام مصفوفة"؟

أفتقدهم كثيرًا في GDScript عندما أستخدمه ، وهذا أحد الأسباب التي تجعلني أفضل C #. أو C ++. أو جافا. أو بايثون. أو إذهب.

بصراحة ، أعتقد أن GDScript هي اللغة الوحيدة التي عملت بها والتي لا تحتوي عليها. الى جانب ذلك ، ربما ، لوا؟ آه ، لقد تحققت ويبدو أنهم موجودون هناك أيضًا. لا نقول إننا يجب أن نهدف إلى إضافة كل ما تملكه هذه اللغات إلى GDScript ، ولكن إذا كانت كل هذه اللغات تشترك في سمة مشتركة ، فقد يكون هناك شيء يستحق ذلك.

لا يمكنني الحكم على مقدار التعقيد الذي ستضيفه إلى الواجهة الخلفية لـ GDScript ، وبالتالي لا يمكنني قول الكثير عن مقايضة التعقيد ، ولكن شطبها لأنها "مجرد سكر نحوي" خطأ ، لأنه يمكن قول ذلك عن الكثير من الأشياء.

مرة أخرى ، لاحظ عدد الأشياء التي تستخدمها في Godot.

نعم ، إنه سكر نحوي. ومع ذلك ، فإن كونه سكرًا نحويًا لا يعني أنه جيد أو سيئ. تدفق التحكم مثل if ، else وحتى الوظائف ليست سوى سكر فوق GOTO أيضًا إذا أردت. هذا لا يعني أنك لا تريد هؤلاء.

لا يحل GOTO محل إذا لأنه قفزة غير مشروطة. هل أنت حتى مبرمج؟

ولكن في الواقع يكسر القدرة على تجاوز الوظائف التي تستخدم varargs ، مثل rpc ، emit_signal

مرة واحدة في السنة ، سيرغب شخص ما في مكان ما في تجاوز وظيفة rpc. بينما يتمنى آلاف الأشخاص الآخرين يوميًا رؤية Godot 4 وهو يطلق سراحه.

من الغريب أيضًا معرفة عدد اللغات التي تنفذ وظائف متنوعة. ربما تكون مفيدة حتى إذا كان من الممكن "تنفيذها بسهولة باستخدام مصفوفة"؟

أفتقدهم كثيرًا في GDScript عندما أستخدمه ، وهذا أحد الأسباب التي تجعلني أفضل C #. أو C ++. أو جافا. أو بايثون. أو إذهب.

لا يحتوي C ++ على نوع مصفوفة قياسي يمكنه تخزين قيم من أنواع مختلفة مثل GDscript. على الرغم من أن C ++ تدعم الوظائف المتنوعة ، إلا أنه لا يُنصح باستخدامها لأنها من النوع غير الآمن. إنه تراث C ، وفي C نفسه كان سكرًا نحويًا ، لأنه تم استخدام printf كثيرًا ، خاصةً لتصحيح الأخطاء - حيث تريد كتابة رمز مؤقت بسرعة لإخراج بعض البيانات. لقد كان مبررًا تمامًا ، لأنه تم استخدامه طوال الوقت - توفيرًا حقيقيًا للوقت! ولكن هل سبق لك أن كتبت دالة متغيرة خاصة بك في C أو C ++؟

مرة أخرى ، لاحظ عدد الأشياء التي تستخدمها في Godot.

لإخراج التصحيح - بكل الوسائل! ولكن إذا لم تكن print () متغيرة ، فبدلاً من الطباعة ("Hello" ، "World) ، يجب عليك كتابة print ([" Hello "،" World "]) - ليس فرقًا كبيرًا على الإطلاق ...

لا يحل GOTO محل إذا لأنه قفزة غير مشروطة

حسنًا ، صحيح. كنت أتحدث عن القفزات المشروطة بالطبع. الذي ... ربما يمكنك الاستدلال. ومع ذلك ، لا تزال النقاط قائمة: لقد قمنا ببناء وظائف ذات مستوى أعلى في الأعلى لنكون قادرين على نقل بعض الأشياء بشكل أكثر نظافة.

لا يحتوي C ++ على نوع مصفوفة قياسي يمكنه تخزين قيم من أنواع مختلفة مثل GDscript.

حسنًا ، جادل ضد Python أو Lua أو Go (أو أي مجموعة من اللغات الأخرى) إذن التي لديها هذه ولا تزال لها وظائف متنوعة.

ولكن إذا لم تكن print () متغيرة ، فبدلاً من الطباعة ("Hello" ، "World) ، يجب عليك كتابة print ([" Hello "،" World "]) - ليس فرقًا كبيرًا على الإطلاق

بالتأكيد ، في حالة الاختبار البسيطة هذه. في الحالات الأكثر تعقيدًا ، يصبح الأمر أكثر قبحًا ، خاصةً بمجرد أن تبدأ في الحصول على بيانات من مصادر متعددة وتحتاج الآن إلى تجميعها يدويًا في مصفوفة أولاً. أوافق على أنها ليست خسارة كبيرة ؛ ومع ذلك ، فإن الدوال المتباينة تجعل كود أنظف في بعض الحالات.

لكن...

ولكن هل سبق لك أن كتبت دالة متغيرة خاصة بك في C أو C ++؟

هل أنت حتى مبرمج؟

على النحو الوارد أعلاه ، لا أشعر أنك تتجادل بحسن نية. في هذه الحالة ، لم أعد مهتمًا بالتحدث إليك بعد الآن ، لذا ... لا ، لقد تم إدراجي للتو كمساهم في المحرك لأنني أصنع تعويذة جيدة ، يرجى المضي قدمًا.

لا يحل GOTO محل إذا لأنه قفزة غير مشروطة. هل أنت حتى مبرمج؟

بالنسبة للجزء الأكبر من العبارات الشرطية ، خاصة الحلقات ، هي مجرد تعليمة قفزة متخصصة ، والتي هي في الغالب نفس تعليمة goto ، من الناحية العملية ، فإن معظم عبارات التحكم في التسلسل الأساسية التي تجدها هي امتداد لذلك. هذه حجة حمقاء لدعم نفسك منها ، (لأنها لا تقدم حجة في الواقع ، إنها تجادل فقط في الدلالات التي لا فائدة منها) وهذا الجزء الثاني غير محترم.

لا يحتوي C ++ على نوع مصفوفة قياسي يمكنه تخزين قيم من أنواع مختلفة مثل GDscript. على الرغم من أن C ++ تدعم الوظائف المتنوعة ، إلا أنه لا يُنصح باستخدامها لأنها من النوع غير الآمن. إنه تراث C ، وفي C نفسه كان سكرًا نحويًا ، لأنه تم استخدام printf كثيرًا ، خاصةً لتصحيح الأخطاء - حيث تريد كتابة رمز مؤقت بسرعة لإخراج بعض البيانات. لقد كان مبررًا تمامًا ، لأنه تم استخدامه طوال الوقت - توفيرًا حقيقيًا للوقت! ولكن هل سبق لك أن كتبت دالة متغيرة خاصة بك في C أو C ++؟

على الرغم من أن C ++ لا تحتوي على نوع مصفوفة قياسية لـ varargs (أو المصفوفات غير المصنفة عمومًا) ، إلا أن هناك طرقًا أولية للتعامل مع هذا لمدة عقد تقريبًا الآن ، (من الناحية الفنية ، يمكنك القيام بذلك حتى قبل C ++ 11 ، إلا أنه كان ثقيلًا جدًا وبدلاً من الاختراق) وثانيًا باستخدام القوالب المتنوعة ، يمكنك تخطي مشكلات الكتابة تمامًا. هناك طرق للتعامل مع varargs في C ++ باستخدام قوالب متنوعة. أولئك الذين ما زالوا يؤمنون بـ varargs في C ++ ربما بدأوا من النقطة الخطأ هذه الأيام.

لا أهتم كثيرًا بالمناقشة شخصيًا (بصرف النظر عن أنني شخصياً أجد أنه أكثر نظافة وتنظيمًا للحصول على نوع من الحجج المتنوعة القائمة على المصفوفة في GDScript بدلاً من الجلوس في الواجهة الخلفية ، أعتقد أنه يجب تنفيذ ميزات اللغة من أجل اللغة ، ليس فقط تنفيذها ، ولكن هذا أنا فقط) ولكن هذه التعليقات كانت بحاجة إلى تصحيح ، وبغض النظر عن أنك تتصرف بوقاحة في هذه الحالة ، فأنت لا تقوي وجهة نظرك في أذهان جمهورك عندما الرد بشكل سلبي على المعارضة التي يجب التعامل معها بموضوعية كهذه.

لا يحل GOTO محل إذا لأنه قفزة غير مشروطة. هل أنت حتى مبرمج؟

بالنسبة للجزء الأكبر من العبارات الشرطية ، خاصة الحلقات ، هي مجرد تعليمة قفزة متخصصة ، والتي هي في الغالب نفس تعليمة goto ، من الناحية العملية ، فإن معظم عبارات التحكم في التسلسل الأساسية التي تجدها هي امتداد لذلك. هذه حجة حمقاء لدعم نفسك منها ، (لأنها لا تقدم حجة في الواقع ، إنها تجادل فقط في الدلالات التي لا فائدة منها) وهذا الجزء الثاني غير محترم.

K ، أنا غير محترم للأشخاص الذين يضيعون وقتي. كانت وجهة نظره: لماذا لا تستخدم GOTO بدلاً من إذا ، وقلت إن GOTO لا يحل محل إذا. GOTO ليست جملة شرطية وإذا كنت تريد استبدال العبارة الشرطية ، فما عليك سوى كتابة ما تريد استبداله به بالضبط. أي أمثلة بالفعل؟

لا يحتوي C ++ على نوع مصفوفة قياسي يمكنه تخزين قيم من أنواع مختلفة مثل GDscript. على الرغم من أن C ++ تدعم الوظائف المتنوعة ، إلا أنه لا يُنصح باستخدامها لأنها من النوع غير الآمن. إنه تراث C ، وفي C نفسه كان سكرًا نحويًا ، لأنه تم استخدام printf كثيرًا ، خاصةً لتصحيح الأخطاء - حيث تريد كتابة رمز مؤقت بسرعة لإخراج بعض البيانات. لقد كان مبررًا تمامًا ، لأنه تم استخدامه طوال الوقت - توفيرًا حقيقيًا للوقت! ولكن هل سبق لك أن كتبت دالة متغيرة خاصة بك في C أو C ++؟

على الرغم من أن C ++ لا تحتوي على نوع مصفوفة قياسية لـ varargs (أو المصفوفات غير المصنفة عمومًا) ، إلا أن هناك طرقًا أولية للتعامل مع هذا لمدة عقد تقريبًا الآن ، (من الناحية الفنية ، يمكنك القيام بذلك حتى قبل C ++ 11 ، إلا أنه كان ثقيلًا جدًا وبدلاً من الاختراق) وثانيًا باستخدام القوالب المتنوعة ، يمكنك تخطي مشكلات الكتابة تمامًا. هناك طرق للتعامل مع varargs في C ++ باستخدام قوالب متنوعة. أولئك الذين ما زالوا يؤمنون بـ varargs في C ++ ربما بدأوا من النقطة الخطأ هذه الأيام.

لا أهتم كثيرًا بالمناقشة شخصيًا (بصرف النظر عن أنني شخصياً أجد أنه أكثر نظافة وتنظيمًا للحصول على نوع من الحجج المتنوعة القائمة على المصفوفة في GDScript بدلاً من الجلوس في الواجهة الخلفية ، أعتقد أنه يجب تنفيذ ميزات اللغة من أجل اللغة ، ليس فقط تنفيذها ، ولكن هذا أنا فقط) ولكن هذه التعليقات كانت بحاجة إلى تصحيح ، وبغض النظر عن أنك تتصرف بوقاحة في هذه الحالة ، فأنت لا تقوي وجهة نظرك في أذهان جمهورك عندما الرد بشكل سلبي على المعارضة التي يجب التعامل معها بموضوعية كهذه.

K ، ولكن هذه هي وجهة نظري بالضبط: يحتوي GDscript على نوع قياسي يمكنك تكراره بحيث يمكنه الاحتفاظ بأنواع مختلفة فيه ، لذلك لا تحتاج إلى العبث بكل الاختراق المطلوب لتشغيل الوظائف المتنوعة في C ++ ، ولهذا السبب ، ربما ، في قوالب المتغيرات C ++ لها ما يبررها.

K ، أنا غير محترم للأشخاص الذين يضيعون وقتي.

ثم سأدعك تضيع وقتك في مشاريع أخرى لأنك الآن ممنوع من التفاعل على مستودعات

لدينا مدونة قواعد سلوك ، وهي بالتأكيد لا تسمح بعدم احترام أي شخص .

تتم الآن مناقشة مقترحات الميزات والتحسين الخاصة بمحرك Godot ومراجعتها في أداة تعقب المشكلات الخاصة بمقترحات تحسين Godot (GIP) ( godotengine / godot- مقترحات ). يحتوي متتبع GIP على نموذج مشكلة مفصل مصمم بحيث تتضمن المقترحات جميع المعلومات ذات الصلة لبدء مناقشة مثمرة ومساعدة المجتمع على تقييم صحة الاقتراح الخاص بالمحرك.

المتتبع الرئيسي (

إذا كنت مهتمًا بمقترح الميزة هذا ، فيرجى فتح اقتراح جديد على متتبع GIP باتباع نموذج المشكلة المحدد (بعد التحقق من عدم وجوده بالفعل). تأكد من الإشارة إلى هذه المشكلة المغلقة إذا كانت تتضمن أي مناقشة ذات صلة (والتي نشجعك أيضًا على تلخيصها في الاقتراح الجديد). شكرا لك مقدما!

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات