ओवरलोड रिज़ॉल्यूशन में "स्पष्ट" कन्स्ट्रक्टर का प्रभाव

Question

निम्न कोड संकलित क्यों नहीं करता है, और जब मैं कक्षा ए में कन्स्ट्रक्टर से पहले स्पष्ट कीवर्ड हटा देता हूं, तो यह संकलित करता है?

विजुअल स्टूडियो 2013 का उपयोग करना:

enum E { e1_0, e1_1 }; 

template<typename T> 
struct A 
{ 
    A() {} 
    explicit A(unsigned long) {} 
    A(T) {} 
}; 

struct B 
{ 
    B() {} 
    B(E) {} 
}; 


void F(B) {}; 
void F(A<short>) {}; 

void test() 
{ 
    F(e1_0); 
} 

त्रुटि:

1>------ Build started: Project: exp_construct_test, Configuration: Debug Win32 ------ 
1> exp_construct_test.cpp 
1>e:\exp_construct_test\exp_construct_test.cpp(23): error C2668: 'F' : ambiguous call to overloaded function 
1>   e:\exp_construct_test\exp_construct_test.cpp(19): could be 'void F(A<short>)' 
1>   e:\exp_construct_test\exp_construct_test.cpp(18): or  'void F(B)' 
1>   while trying to match the argument list '(E)' 
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== 

संपादित करें: मैं बजना डाउनलोड किया है और बजना-सीएल जो दोनों ही मामलों के लिए त्रुटि की सूचना के साथ संकलित। इसलिए टिप्पणियों में बताया गया है, अस्पष्टता A<short>(short) और B(E) के बीच है।

तो शायद वीसी ++ में एक बग है, जब मैं को A(unsigned long) से हटा देता हूं, तो संकलक किसी भी अस्पष्टता को बढ़ाने के बजाय बी (ई) चुनने के द्वारा चुनता है। क्या कोई मानक अनुपालन के रूप में क्लैंग व्यवहार की पुष्टि कर सकता है, और वीसी ++ छोटी गाड़ी के रूप में?

G(e1_0); 

जो किसी भी त्रुटि को उठाने नहीं करता है:

मैं

void G(E) {}; 
void G(short) {}; 

और इस तरह जी के लिए एक कॉल गयी। यहां क्यों G(E) prefferred है, और उम्मीदवारों के मामले में A<short>::A(short) और B::B(E), वे संदिग्ध हैं?

समाप्ति संपादित

धन्यवाद --joja

Answer 1

के बाद अपने उदाहरण एक के विभिन्न रूपों पर नजर डालते हैं।

1. मूल उदाहरण f(e0) पर कॉल करना।

   enum E {e0, e1}; 
   
   template<typename T> 
   struct A 
   { 
       A(); // (1) 
       explicit A(unsigned long); // (2) 
       A(T); // (3) 
   }; 
   
   struct B 
   { 
       B(); // (4) 
       B(E); // (5) 
   }; 
   
   void f(A<short>); // (6) 
   void f(B); // (7) 
   
   void g(E); // (8) 
   void g(short); // (9) 
   

   तीन संभावनाएं

   • एक unsigned long करने के लिए e0 कन्वर्ट के अलावा, (2) और फोन अधिभार (6) इसमें से एक A<short> बनाने निर्माता के माध्यम से,
   • short करने के लिए e0 कनवर्ट करते हैं, एक बनाने A<hort> कन्स्ट्रक्टर (3) और कॉल ओवरलोड (6) और
   • e0 से कन्स्ट्रक्टर के माध्यम सेबनाएं (5) और कॉल ओवरलोड (7)

   पहला विकल्प लागू नहीं है क्योंकि (2) explicit है। शेष दो में उपयोगकर्ता द्वारा परिभाषित रूपांतरण शामिल है जिसे समान रूप से अच्छा माना जाता है और किसी के पक्ष में कोई भी नहीं लिया जाता है। कॉल संदिग्ध है और कार्यक्रम खराब हो गया है।

2. चलिए कन्स्ट्रक्टर से explicit हटा दें और f(e0) पर कॉल करें।

   template<typename T> 
   struct A 
   { 
       A(); // (1) 
       A(unsigned long); // (2) 
       A(T); // (3) 
   }; 
   
   struct B 
   { 
       B(); // (4) 
       B(E); // (5) 
   }; 
   

   तीन विकल्प, एक ही लेकिन इस बार रहने के सभी तीन लागू होते हैं और कॉल (और भी अधिक) है अस्पष्ट और कार्यक्रम बीमार का गठन किया।

3. चलिए दोनों रचनाकार explicit बनाते हैं और f(e0) पर कॉल करते हैं।

   template<typename T> 
   struct A 
   { 
       A(); // (1) 
       explicit A(unsigned long); // (2) 
       explicit A(T); // (3) 
   }; 
   
   struct B 
   { 
       B(); // (4) 
       B(E); // (5) 
   }; 
   

   यह यह असंभव परोक्ष एक A<short> निर्माण करने के लिए और कॉल स्पष्ट रूप से अधिभार (5) को संदर्भित करता है बनाता है।

4. के B के निर्माता भी कर explicit और f(e0) कहते हैं।

   template<typename T> 
   struct A 
   { 
       A(); // (1) 
       explicit A(unsigned long); // (2) 
       explicit A(T); // (3) 
   }; 
   
   struct B 
   { 
       B(); // (4) 
       explicit B(E); // (5) 
   }; 
   

   इस बार, तीन रूपांतरण पथों के कोई भी लागू क्योंकि हर एक एक explicit निर्माता के माध्यम से जाना होगा। f का कोई अधिभार नहीं है जो लागू है और कार्यक्रम खराब है।

5. कॉल g(e0)।

   • कॉल अधिभार (8) किसी भी रूपांतरण के बिना या
   • एक short करने के लिए e0 बदलने और अधिभार (9) फोन:

     हम यहाँ दो संभावनाएं है।

   इन दोनों में से, पहला विकल्प स्पष्ट रूप से अनुकूल है क्योंकि इसमें रूपांतरण शामिल नहीं है। कॉल अस्पष्ट है। (यहां तक ​​कि अगर निर्माता (5) explicit नहीं है।)

ध्यान दें कि डिफ़ॉल्ट कंस्ट्रक्टर्स (1) और (4) वास्तव में कुछ भी इस चर्चा में योगदान नहीं है। जीसीसी 4.9.1 के साथ परीक्षण, सभी पांच उदाहरण अपेक्षित व्यवहार करते हैं।