5

बेहतर क्या है (यदि कोई है)?बार्टन-नाकमैन बनाम std :: enable_if

संस्करण ए (बार्टन-Nackman):

template<class T> 
struct equal_comparable { 
    friend bool operator == (const T & t1, const T & t2) { 
     return t1.equalTo (t2); 
    } 
}; 

class MyClass : private equal_comparable<MyClass> { 
    bool equalTo (const MyClass & other) //... 
}; 

संस्करण बी (std :: enable_if):

struct MyClass { 
    static const bool use_my_equal = true; 
    bool equalTo (const MyClass & other) //... 
}; 

template<class T> 
typename std::enable_if< 
    T::use_my_equal, 
    bool 
>::type 
operator == (const T & t1, const T & t2) { return t1.equalTo (t2); } 
+0

व्यक्तिगत रूप से मैं पूर्व को पसंद करता हूं। 'equal_comparable' को उपयुक्त नेमस्पेस में रखा जा सकता है, लेकिन कौन जानता है कि सदस्य 'use_my_equal' का उपयोग किसी प्रकार के' टी' द्वारा किया जाता है जिसे आपने कभी नहीं सुना है। निस्संदेह यह समस्या 'enable_if' के अन्य समान उपयोगों पर लागू होती है - सिर्फ इसलिए कि एक आश्रित नाम हल करता है * जरूरी नहीं है * इसका अर्थ यह है कि नाम का उपयोग आपके विचार के लिए किया जाता है, यदि आप इसे किसी नामस्थान से बाहर खींच रहे हैं नियंत्रण मत करो। आप इसके बजाय एक प्रकार की विशेषता का उपयोग कर सकते हैं। –

+0

एक टेम्पलेट का उपयोग क्यों करें? क्यों न केवल 'बूल ऑपरेटर == (कॉन्स माईक्लास और,/* आदि * /) ;? – GManNickG

+0

@GManNickG: मेरा मानना ​​है कि चाल का उद्देश्य प्रति वर्ग की तुलना में बॉयलरप्लेट को कम करना है जो समानता-तुलनीय है। –

उत्तर

4

मैं Boost.Operators टिप्पणी में @SteveJessop ने उल्लेख उपयोग करने के लिए पसंद करते हैं, जो आपके पहले दृष्टिकोण को औपचारिक और स्वचालित करता है। यदि आपको ऑपरेटरों के कई सेट की आवश्यकता होती है तो वे खाली आधार अनुकूलन का भी ख्याल रखते हैं (और इसलिए एकाधिक विरासत की आवश्यकता होगी)। टाइपिंग में बचत इतनी अधिक नहीं है, बल्कि कोड प्रलेखन/प्रवर्तन मूल्य भी है, क्योंकि ये आधार वर्ग वर्ग इंटरफ़ेस के सामने सही हैं। उस अर्थ में, यह अवधारणाओं का एक प्राचीन तरीका है।

संबंधित मुद्दे