لماذا تعمل وظائف أعضاء الفصل على وظائف الظل المجانية بنفس الاسم؟

Question

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

void f();

struct S
{
    void f();

    void g()
    {
        f(); // calls S::f instead of ::f
    }
};

عندما تكون الوظائف لها توقيعات متطابقة، فمن الطبيعي أن يعمل النطاق المتغير بنفس الطريقة.ولكن لماذا يتم حظر المكالمات التي لا لبس فيها حيث يكون للوظيفة الحرة توقيع مختلف مثل هذا:

void f();

struct S
{
    void f(int x);

    void g()
    {
        f(); // fails to compile attempting to call S::f, which has wrong signature
    }
};

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

Answer 1

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

ولكن لماذا يتم حظر المكالمات التي لا لبس فيها حيث يكون للوظيفة الحرة توقيع مختلف مثل هذا:

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

Answer 2

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

giveacodicetagpre.

imo، هذا هو الجنون.

ولكن لماذا تحظر المكالمات غير المبادلة حيث يوجد وظيفة مجانية توقيع مختلف مثل هذا:

بحث الاسم يحدث قبل دقة التحميل الزائد:

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

القواعد معقدة بما فيه الكفاية بدون "ردود الفعل" بين البحث عن التحميل الزائد والاسم.أود أن أقترح تبسيط (مثل إزالة العضو يخفي قاعدة اسم مساحة الاسم، وإزالة بحث اسم غامض) بدلا من التعداد.

Answer 3

لا أستطيع تقديم إجابة موثوقة (ربما يتذكر البعض اقتباسًا من Design and Evolution of C++ أو كان بالفعل عضوًا في اللجنة في ذلك الوقت)، لكن تخميني الأول هو الفشل تمامًا في الحالات التي تظهرها.من السهل أن ننسى عدد الأشياء الموجودة في النطاق في وقت معين.بالإضافة إلى ذلك، يمكن أن يكون حل التحميل الزائد معقدًا جدًا ويمكن أن يكون هناك وسائط وتحويلات افتراضية.لذلك أفضّل أن يكون النطاق محدودًا للغاية في هذه الحالة لأتأكد دائمًا من الاسم الذي يتم استدعاؤه بالضبط.