वैरिएडिक टेम्पलेट्स में घोषणाकर्ता संशोधक स्थिति

Question

घोषणाकर्ता। हां, घोषणाकर्ता। वे बहुत सारे कोडिंग सम्मेलन बहस का स्रोत हैं। तर्कों के लिए यह वास्तव में एक अच्छा विषय है - सी ++ इस बात पर शासन नहीं करता कि कौन सा दूसरे से बेहतर है (यह परवाह नहीं करता है!)। और इसलिए हम किसी को चिंता आप का मज़ाक बना सकता है बिना इन लिख सकते हैं:

int x; 

int& a = x; 
int &b = x; 

int* c = &x; 
int *d = &x; 

वाक्य संदर्भ में, b और d "अधिक मान्य" दूसरों की तुलना में कर रहे हैं। हमें नाम से पहले घोषणाकर्ता संशोधक डालना होगा:

int m, *n; // m is an int; n is a pointer to int 

लेकिन ज्वार एक के पक्ष में बदल गया है।

template<typename... Ts> 
void VariadicFuncRef(const Ts... &args) { } 

template<typename... Ts> 
void VariadicFuncPtr(Ts... *args) { } 

:

template<typename... Ts> 
void VariadicFuncRef(const Ts&... args) { } 
          ^
template<typename... Ts> 
void VariadicFuncPtr(Ts*... args) { } 
        ^

यह इन रूपों को लिखने के लिए एक त्रुटि है: सी ++ 11 के variadic टेम्पलेट्स के साथ, declarators की स्थिति प्रपत्र जहां संशोधक आधार प्रकार के करीब हैं के लिए प्रतिबंधित किया जा रहा है

एक ठोस उदाहरण के लिए, here पर क्लिक करें।

और इसलिए, मेरा प्रश्न यह है: हम इस (कानूनी) फॉर्म तक सीमित क्यों हैं और दूसरे का उपयोग नहीं कर सकते हैं?

कोई विचार लोग?

अतिरिक्त 1: मुझे इस "नियम" को लागू करने के तरीके पर डिजाइन निर्णय में भी रूचि है।

Answer 1

सबसे पहले, मैं यह नहीं कहूंगा कि int &aअधिक मान्यint& a से है। आप कह सकते हैं कि यह अधिक पठनीय, या एक अच्छा अभ्यास है, लेकिन यह पूरी तरह से एक अलग बात है।

दूसरा, पैरामीटर खोल वाक्य रचना T...के रूप में पढ़ा जा सकता है "... की बाईं ओर प्रकार पैटर्न का विस्तार होता है, प्रकार-पैटर्न के रूप मिलान उसी या अन्य वास्तविक समारोह पैरामीटर प्रकार के गठन"। तो जब आप f(T&...) लिखते हैं, तो इसे f(int&, float&, double&, Xyz&, Abc&) तक बढ़ाया जा सकता है। लेकिन यह इतना स्पष्ट नहीं है (कम से कम मेरे लिए) जब वाक्यविन्यास T...& है। तो शायद, यह में से एक है अन्य कई संभावित कारणों ने मानक इसे क्यों बनाया।

यह भी ध्यान दें कि argsT&...argsवैकल्पिक है। तो यदि आप इसे नहीं लिखते हैं, तो void f(T...&) अजीब लग रहा है (मेरे लिए, कम से कम) और void f(T&...) कम से कम सौंदर्य रूप से बेहतर दिखता है।

आप T * const & ... जैसे T... * const & के साथ वाक्यविन्यास की तुलना भी कर सकते हैं। टाइप-पैटर्न बाद वाले की तुलना में पूर्व वाक्यविन्यास में अधिक स्पष्ट है।

Answer 2

पुराना घोषणाकर्ता सिंटैक्स केवल सफेद नियम के साथ एक नियम था, लेकिन आपका विचार दो है। मुझे संदेह है कि समिति दो नियम होने के पक्ष में होगी जब कोई पर्याप्त होगा।

बाईं तरफ declarator डालने के चुनाव की संभावना सबसे अधिक दो कारणों से किया गया था:

• मुहावरेदार सी ++ आजकल पसंद int* x बजाय int *x (Bjarne उदाहरण के लिए पूर्व का उपयोग करता है)। अधिकतर घोषणाकर्ता सिंटैक्स को गलती मानते हैं।
• पैरामीटर पैक विस्तार ... के बाईं ओर चीजें फैलाता है, दाईं ओर नहीं।

Answer 3

पूर्णता हासिल की जाती है, न कि जब जोड़ने के लिए और कुछ नहीं है, लेकिन जब कुछ भी नहीं निकाला जाता है।

- एंटोनी डे सेंट-एक्सुपेरी

सुविधाओं को जोड़ने के लिए नहीं है प्रोग्रामिंग भाषा डिजाइन करने में कठिनाई, यह उन्हें जोड़ने से बचना है। हर सुविधा, वाक्य रचना के हर बदलाव, एक लागत है:

• वे विशेष रूप से संकलक में कोडित किया जाना चाहिए
• वे शुरू कीड़ों का खतरा पैदा
• वे एक और सुविधा के साथ बुरी तरह से बातचीत का खतरा उत्पन्न/भिन्नता
• ...

सी और C++ वाक्य रचना (अधिकतर) खाली स्थान के असंवेदनशील, इसलिए यह कोई फर्क नहीं पड़ता है जहाँ आप & या * जगह और दोनों प्राथमिकताओं अतिरिक्त बोझ के बिना coexist कर सकते हैं; हालांकि विविध टेम्पलेट्स के मामले में यह ... टोकन की वजह से मायने रखता है। इस प्रकार समिति ने एक को चुनने का फैसला किया, और उन्होंने सी ++ में सबसे बेवकूफ चुना (जो मूल प्रकार के बजाय पूर्ण प्रकार पर जोर देता है)।