هل هناك أي سبب لعدم دعم C# للطرق اليدوية المضمنة؟وماذا عن المعلمات الاختيارية؟

Question

هل هناك أي سبب تصميمي لذلك (مثل سبب تخليهم عن الميراث المتعدد)؟

أو أنها لم تكن مهمة بما فيه الكفاية؟

وينطبق نفس السؤال على المعلمات الاختيارية في الطرق ...كان هذا بالفعل في الإصدار الأول من vb.net...لذلك فمن المؤكد أنه لا يوجد كسل هو الذي يجعل MS لا يسمح بالمعلمات الاختيارية، وربما قرار الهندسة المعمارية ..ويبدو أنهم غيروا رأيهم بشأن ذلك، لأن C# 4 سوف يتضمن ذلك..

هل يعرف أحد ما هو القرار ولماذا تخلوا عنه؟

يحرر:

ربما لم تفهمني بشكل كامل.أنا أعمل مؤخرًا على برنامج حسابي (دعم الأرقام من أي حجم، حتى الرقم الأخير)، حيث يتم استخدام بعض الطرق حرفيًا ملايين المرات في الثانية.

لنفترض أن لدي طريقة تسمى Add(int num)، ويتم استخدام هذه الطريقة كثيرًا مع 1 كمعلمة (Add(1);)، لقد اكتشفت أنه من الأسرع تنفيذ طريقة خاصة خاصة لشخص واحد.ولا أقصد التحميل الزائد - كتابة طريقة جديدة تسمى AddOne، ونسخ طريقة Add فيها حرفيًا، باستثناء أنه بدلاً من استخدامها num انا اكتب 1.قد يبدو هذا غريبًا جدًا بالنسبة لك، لكنه في الواقع أسرع.

(بقدر ما هو قبيح)

هذا جعلني أتساءل لماذا لا يدعم C# دليلًا يدويًا والذي يمكن أن يكون مفيدًا بشكل مثير للدهشة هنا.

شكرًا.(ولماذا قمت بالتصويت لي:S)

تحرير 2:

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

Answer 1

للإجابة على جزء من سؤالك، راجع مشاركة مدونة Eric Gunnerson: لماذا لا يحتوي C# على كلمة رئيسية "مضمنة"؟

اقتباس من تدوينته:

For C#, inlining happens at the JIT level, and the JIT generally makes a decent decision.

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

Answer 2

سيكون التضمين اليدوي عديم الفائدة تقريبًا.يقوم مترجم JIT بتضمين الأساليب أثناء تجميع التعليمات البرمجية الأصلية حيثما كان ذلك مناسبًا، وأعتقد أنه في جميع الحالات تقريبًا يكون مترجم JIT أفضل في التخمين عندما يكون ذلك مناسبًا من المبرمج.

أما بالنسبة للمعلمات الاختيارية، فلا أعرف سبب عدم وجودها في الإصدارات السابقة.ومع ذلك، لا أحب وجودها في C# 4، لأنني أعتبرها ضارة إلى حد ما لأن المعلمة يتم دمجها في التجميع المستهلك ويجب عليك إعادة ترجمتها إذا قمت بتغيير القيم القياسية في ملف DLL وتريد الاستهلاك التجمع لاستخدام تلك الجديدة.

يحرر:

بعض المعلومات الإضافية حول البطانة.على الرغم من أنه لا يمكنك إجبار برنامج التحويل البرمجي JIT على تضمين استدعاء أسلوب، إلا أنه يمكنك إجباره على عدم تضمين استدعاء أسلوب.لهذا، يمكنك استخدام System.Runtime.CompilerServices.MethodImplAttribute، كما يلي:

internal static class MyClass
{
    [System.Runtime.CompilerServices.MethodImplAttribute(MethodImplOptions.NoInlining)]
    private static void MyMethod()
    {
        //Powerful, magical code
    }

    //Other code
}

Answer 3

تخميني المتعلم:السبب وراء عدم احتواء الإصدارات السابقة من C# على معلمات اختيارية هو التجارب السيئة معها في C++.على السطح، تبدو واضحة بما فيه الكفاية، ولكن هناك عدد قليل من الحالات الزاوية المزعجة.أعتقد أن أحد كتب هيرب سوتر يصف هذا الأمر بمزيد من التفصيل؛بشكل عام، يتعلق الأمر بالتجاوز virtual طُرق. ماكسيميليان لقد ذكر إحدى حالات ركن .NET في إجابته.

يمكنك أيضًا الاستغناء عنها عن طريق كتابة العديد من التحميلات الزائدة يدويًا؛قد لا يكون ذلك لطيفًا جدًا بالنسبة لـ مؤلف للفئة، ولكن من الصعب أن يلاحظ العملاء الفرق بين التحميل الزائد والمعلمات الاختيارية.

لذا، بعد كل هذه السنوات بدونها، لماذا أضافها الإصدار C# 4.0؟1) تحسين التكافؤ مع VB.NET، و2) سهولة التفاعل مع COM.

Answer 4

أنا أعمل مؤخرًا على برنامج حسابي (دعم الأرقام من أي حجم، حتى الرقم الأخير)، حيث يتم استخدام بعض الطرق حرفيًا ملايين المرات في الثانية.

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

إذا كان هذا صحيحًا، فلا تستخدم .NET.إذا كنت تعتقد أنه يمكنك اكتساب السرعة في التخصص الجزئي، فانتقل إلى Haskell أو C أو Fortran أو أي لغة أخرى تقوم بذلك تلقائيًا، أو يمكن أن تعرض لك التضمين للقيام بذلك يدويًا.

لو Add(1) يهمك حقًا، فإن تخصيصات الكومة ستكون مهمة أيضًا.

ومع ذلك، يجب عليك حقًا أن تنظر إلى ما يمكن أن يخبرك به المحلل...

Answer 5

أضافها C# في الإصدار 4.0: http://msdn.microsoft.com/en-us/library/dd264739(VS.100).aspx

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

Answer 6

حتى في لغات مثل C++، فإن تضمين شيء ما لا يضمن حدوثه؛إنها تلميح للمترجم. يمكن للمترجم إما أن يأخذ التلميح، أو أن يفعل الشيء الخاص به.

تعد لغة #C خطوة أخرى تمت إزالتها من كود التجميع الذي تم إنشاؤه (عبر IL + JIT)، لذلك يصبح من الصعب ضمان تضمين شيء ما.علاوة على ذلك، لديك مشكلات مثل اختلاف تطبيقات x86 + x64 لـ JIT في السلوك.

Answer 7

جافا لا تتضمن ملف في النسق الكلمة الرئيسية سواء.يمكن لـ Java JITs الأفضل تضمين الأساليب الافتراضية، ولا يحب استخدام الكلمات الرئيسية خاص أو أخير لن يحدث أي فرق (كان الأمر كذلك، ولكن هذا أصبح الآن تاريخًا قديمًا).