यह सर्वविदित है कि आरंभीकरण शब्दार्थ C ++ के सबसे जटिल भागों में से एक है। कई प्रकार के आरंभीकरण हैं, जो विभिन्न वाक्यविन्यास द्वारा वर्णित हैं, और वे सभी एक जटिल और चुनौतीपूर्ण तरीके से बातचीत करते हैं। C ++ 11 "सार्वभौमिक प्रारंभ" की अवधारणा लाया। दुर्भाग्य से, उसने और भी जटिल नियम पेश किए, और बदले में, उन्हें C ++ 14, C ++ 17 में ब्लॉक कर दिया गया और C ++ 20 में फिर से बदल दिया गया।

सी ++ रूस सम्मेलन से तैमूर डौमलर की रिपोर्ट के कट - वीडियो और अनुवाद के तहत। तैमूर पहली बार C ++ में इनिशियलाइज़ेशन के विकास के ऐतिहासिक परिणामों को बताता है, इनिशियलाइज़ेशन रूल के वर्तमान संस्करण का एक व्यवस्थित अवलोकन देता है, विशिष्ट समस्याएं और आश्चर्य, इन सभी नियमों का प्रभावी ढंग से उपयोग करने का तरीका बताता है, और अंत में मानक में नए प्रस्तावों के बारे में बात करता है जो इनिशियलाइज़ेशन शब्दार्थ कर सकते हैं। C ++ 20 थोड़ा अधिक सुविधाजनक है। आगे की कहानी उसकी ओर से है।

सामग्री की तालिका

• डिफ़ॉल्ट प्रारंभ (C)
• प्रतिलिपि प्रारंभ (C)
• एग्रीगेट इनिशियलाइज़ेशन (C)
• स्टेटिक इनिशियलाइज़ेशन (C)
• प्रत्यक्ष प्रारंभ (C ++ 98)
• वैल्यू इनिशियलाइज़ेशन (C ++ 03)
• यूनिवर्सल इनिशियलाइज़ेशन (C ++ 11)
• C ++ 14 में सुधार
• C ++ में सही तरीके से इनिशियलाइज़ कैसे करें
• निरुपित प्रारंभ (C ++ 20)
• C ++ 20 में सुधार
• कुल प्रकारों की प्रत्यक्ष आरंभीकरण (C ++ 20)

अब आप जो जिफ देखते हैं, वह रिपोर्ट के मुख्य संदेश को बहुत अच्छी तरह से बताता है। मैंने इसे लगभग छह महीने पहले इंटरनेट पर पाया, और इसे अपने ट्विटर पर पोस्ट किया। उसे टिप्पणियों में, किसी ने कहा कि तीन और प्रकार के आरंभीकरण गायब हैं। एक चर्चा शुरू हुई, जिसके दौरान मुझे इस पर रिपोर्ट करने के लिए आमंत्रित किया गया था। और इसलिए यह सब शुरू हुआ।

आरंभीकरण के बारे में निकोले युसुटिस ने पहले ही बताया था । उनकी रिपोर्ट में एक स्लाइड को सूचीबद्ध करने के लिए एक अंतर को शुरू करने के 19 अलग-अलग तरीके शामिल थे:

int i1; //undefined value int i2 = 42; //note: inits with 42 int i3(42); //inits with 42 int i4 = int(); //inits with 42 int i5{42}; //inits with 42 int i6 = {42}; //inits with 42 int i7{}; //inits with 0 int i8 = {}; //inits with 0 auto i9 = 42; //inits with 42 auto i10{42}; //C++11: std::initializer_list<int>, C++14: int auto i11 = {42}; //inits std::initializer_list<int> with 42 auto i12 = int{42}; //inits int with 42 int i13(); //declares a function int i14(7, 9); //compile-time error int i15 = (7, 9); //OK, inits int with 9 (comma operator) int i16 = int(7, 9); //compile-time error int i17(7, 9); //compile-time error auto i18 = (7, 9); //OK, inits int with 9 (comma operator) auto i19 = int(7, 9); //compile-time error 

यह मुझे लगता है कि यह एक प्रोग्रामिंग भाषा के लिए एक अनूठी स्थिति है। एक वैरिएबल को प्रारंभ करना सबसे सरल क्रियाओं में से एक है, लेकिन C ++ में यह करना आसान नहीं है। यह संभावना नहीं है कि इस भाषा का कोई अन्य क्षेत्र है जिसमें हाल के वर्षों में मानक, सुधारों और परिवर्तनों से विचलन की कई रिपोर्टें मिली होंगी। प्रारंभिक नियम मानक से मानक में बदलते हैं, और इंटरनेट पर अनगिनत पोस्ट हैं कि C ++ में कैसे इनिशियलाइज़ किया जाए। इसलिए, इसकी व्यवस्थित समीक्षा करना गैर-तुच्छ कार्य है।

मैं सामग्री को कालानुक्रमिक क्रम में प्रस्तुत करूंगा: पहले हम बात करेंगे कि सी से विरासत में क्या मिला था, फिर सी ++ 98 के बारे में, फिर सी ++ 03, सी ++ 11, सी ++ 14 और सी ++ 17 के बारे में। हम सामान्य त्रुटियों पर चर्चा करेंगे, और मैं उचित आरंभीकरण के संबंध में अपनी सिफारिशें दूंगा। मैं C ++ 20 में नवाचारों के बारे में भी बात करूंगा। रिपोर्ट के अंत में एक अवलोकन तालिका प्रस्तुत की जाएगी।

डिफ़ॉल्ट प्रारंभ (C)

C ++ में, बहुत सारी चीजें C से विरासत में मिली हैं, इसीलिए हम इसके साथ शुरुआत करेंगे। C में वेरिएबल्स को इनिशियलाइज़ करने के कई तरीके हैं। हो सकता है कि उन्हें बिल्कुल भी आरंभीकृत न किया गया हो और इसे डिफ़ॉल्ट आरंभीकरण कहा जाता है । मेरी राय में, यह एक दुर्भाग्यपूर्ण नाम है। तथ्य यह है कि किसी भी चर को एक डिफ़ॉल्ट मान नहीं सौंपा गया है, यह बस आरंभिक नहीं है। यदि आप C ++ और C में एक अनइंस्टाल्यूटेड वैरिएबल की ओर मुड़ते हैं, तो आपको अपरिभाषित व्यवहार मिलता है:

 int main() { int i; return i; // undefined behaviour } 

यही बात कस्टम प्रकारों पर भी लागू होती है: यदि किसी struct में असिंचित क्षेत्र हैं, तो उन्हें एक्सेस करते समय, अपरिभाषित परिवर्तन भी:

 struct Widget { int i; int j; }; int main() { Widget widget; return widget.i; //   } 

कई नए निर्माणों को C ++ में जोड़ा गया है: कक्षाएं, कंस्ट्रक्टर, सार्वजनिक, निजी, विधियाँ, लेकिन इनमें से कोई भी केवल वर्णित व्यवहार को प्रभावित नहीं करता है। यदि कुछ तत्व को कक्षा में आरंभ नहीं किया जाता है, तो इसे एक्सेस करते समय, अपरिभाषित व्यवहार होता है:

 class Widget { public: Widget() {} int get_i() const noexcept { return i; } int get_j() const noexcept { return j; } private: int i; int j; }; int main() { Widget widget; return widget.get_i(); // Undefined behaviour! } 

डिफ़ॉल्ट रूप से C ++ में एक क्लास एलिमेंट को इनिशियलाइज़ करने का कोई जादुई तरीका नहीं है। यह एक दिलचस्प बिंदु है, और C ++ के साथ अपने करियर के पहले कुछ वर्षों के दौरान, मुझे यह नहीं पता था। न तो संकलक और न ही आईडीई, जो मैंने तब उपयोग किया था, मुझे किसी भी तरह से यह याद दिलाया। मेरे सहयोगियों ने कोड की जाँच करते समय इस सुविधा पर ध्यान नहीं दिया। मुझे पूरा यकीन है कि उसकी वजह से, इन वर्षों के दौरान लिखे गए मेरे कोड में कुछ बहुत ही अजीब कीड़े हैं। मुझे यह स्पष्ट प्रतीत हुआ कि वर्गों को अपने चर का आरंभ करना चाहिए।

C ++ 98 में, आप सदस्य initializer सूची का उपयोग करके चर को इनिशियलाइज़ कर सकते हैं। लेकिन समस्या का ऐसा समाधान इष्टतम नहीं है, क्योंकि यह प्रत्येक निर्माता में किया जाना चाहिए, और यह भूलना आसान है। इसके अलावा, आरंभीकरण उस क्रम में होता है जिसमें चर घोषित किए जाते हैं, और सदस्य आरंभीकरण सूची के क्रम में नहीं:

 // C++98: member initialiser list class Widget { public: Widget() : i(0), j(0) {} // member initialiser list int get_i() const noexcept { return i; } int get_j() const noexcept { return j; } private: int i; int j; }; int main() { Widget widget; return widget.get_i(); } 

सी ++ 11 में, प्रत्यक्ष सदस्य इनिशियलाइज़र जोड़े गए थे, जो उपयोग करने के लिए बहुत अधिक सुविधाजनक हैं। वे आपको एक ही समय में सभी चर आरंभ करने की अनुमति देते हैं, और यह विश्वास दिलाता है कि सभी तत्व प्रारंभिक हैं:

 // C++11: default member initialisers class Widget { public: Widget() {} int get_i() const noexcept { return i; } int get_j() const noexcept { return j; } private: int i = 0; // default member initialisers int j = 0; }; int main() { Widget widget; return widget.get_i(); } 

मेरी पहली सिफारिश: जब भी आप कर सकते हैं, हमेशा डीएमआई (प्रत्यक्ष सदस्य इनिशियलाइज़र) का उपयोग करें। उनका उपयोग अंतर्निहित प्रकार ( float और int ) और वस्तुओं के साथ दोनों के साथ किया जा सकता है। प्रारंभिक तत्वों की आदत हमें इस मुद्दे को और अधिक सचेत रूप से पेश करती है।

प्रतिलिपि प्रारंभ (C)

तो, सी से विरासत में मिली पहली आरंभीकरण विधि डिफ़ॉल्ट रूप से आरंभीकरण है, और इसका उपयोग नहीं किया जाना चाहिए। दूसरा तरीका है कॉपी इनिशियलाइज़ेशन । इस मामले में, हम चर और बराबर चिह्न के माध्यम से संकेत देते हैं - इसका मूल्य:

 // copy initialization int main() { int i = 2; } 

जब किसी फ़ंक्शन को मान द्वारा पास किया जाता है, या जब किसी ऑब्जेक्ट को मान द्वारा फ़ंक्शन से लौटाया जाता है, तो कॉपी इनिशियलाइज़ेशन का उपयोग किया जाता है:

 // copy initialization int square(int i) { return i * i; } 

एक समान चिह्न यह मान दे सकता है कि एक मान असाइन किया जा रहा है, लेकिन ऐसा नहीं है। कॉपी आरंभीकरण एक मूल्य असाइनमेंट नहीं है। इस रिपोर्ट में विनियोग के बारे में कुछ भी नहीं होगा।

प्रतिलिपि आरंभीकरण की एक और महत्वपूर्ण संपत्ति: यदि मूल्यों के प्रकार मेल नहीं खाते हैं, तो रूपांतरण अनुक्रम निष्पादित किया जाता है। रूपांतरण अनुक्रम के कुछ नियम हैं, उदाहरण के लिए, यह स्पष्ट निर्माणकर्ताओं को नहीं कहता है, क्योंकि वे निर्माणकर्ता नहीं बदल रहे हैं। इसलिए, यदि आप किसी ऑब्जेक्ट के लिए प्रतिलिपि आरंभीकरण करते हैं जिसका निर्माता स्पष्ट रूप में चिह्नित है, तो संकलन त्रुटि उत्पन्न होती है:

 struct Widget { explicit Widget(int) {} }; Widget w1 = 1; // ERROR 

इसके अलावा, अगर कोई अन्य कंस्ट्रक्टर है जो स्पष्ट नहीं है, लेकिन यह प्रकार में बदतर है, तो कॉपी इनिशियलाइज़ेशन इसे स्पष्ट निर्माता की अनदेखी करेगा:

 struct Widget { explicit Widget(int) {} Widget(double) {} }; Widget w1 = 1; //  Widget(double) 

एग्रीगेट इनिशियलाइज़ेशन (C)

तीसरे प्रकार की इनिशियलाइज़ेशन जिसके बारे में मैं बात करना चाहूंगा, वह है एग्रीगेट इनिशियलाइज़ेशन । इसे तब निष्पादित किया जाता है जब सरणी को ब्रेसिज़ में मानों की एक श्रृंखला के साथ आरंभ किया जाता है:

 int i[4] = {0, 1, 2, 3}; 

यदि आप सरणी का आकार निर्दिष्ट नहीं करते हैं, तो यह कोष्ठक में संलग्न मानों की संख्या से लिया गया है:

 int j[] = {0, 1, 2, 3}; // array size deduction 

समान आरंभ का उपयोग कुल वर्गों के लिए किया जाता है, अर्थात, वे कक्षाएं जो केवल सार्वजनिक तत्वों का संग्रह हैं (कुल वर्गों की परिभाषा में कुछ और नियम हैं, लेकिन अब हम उन पर ध्यान नहीं देंगे):

 struct Widget { int i; float j; }; Widget widget = {1, 3.14159}; 

इस सिंटैक्स ने C और C ++ 98 में भी काम किया, और, C ++ 11 से शुरू करके, आप इसमें समान चिह्न छोड़ सकते हैं:

 Widget widget{1, 3.14159}; 

एकत्रीकरण आरंभीकरण वास्तव में प्रत्येक तत्व के लिए प्रतिलिपि आरंभीकरण का उपयोग करता है। इसलिए, यदि आप स्पष्ट कंस्ट्रक्टर्स के साथ कई ऑब्जेक्ट्स के लिए एग्रीगेट इनिशियलाइज़ेशन (दोनों एक समान चिह्न के साथ और इसके बिना) का उपयोग करने का प्रयास करते हैं, तो प्रत्येक ऑब्जेक्ट के लिए इनिशियलाइज़ेशन कॉपी किया जाता है और एक संकलन त्रुटि होती है:

 struct Widget { explicit Widget(int) {} }; struct Thingy { Widget w1, w2; }; int main() { Thingy thingy = {3, 4}; // ERROR Thingy thingy {3, 4}; // ERROR } 

और अगर इन वस्तुओं के लिए कोई अन्य कंस्ट्रक्टर गैर-स्पष्ट है, तो इसे कहा जाता है, भले ही वह टाइप करने के लिए बदतर हो:

 struct Widget { explicit Widget(int) {} Widget(double) {} }; struct Thingy { Widget w1, w2; }; int main() { Thingy thingy = {3, 4}; //  Widget(double) Thingy thingy {3, 4}; //  Widget(double) } 

आइए समग्र आरंभ के एक और गुण पर विचार करें। प्रश्न: यह कार्यक्रम किस मूल्य पर लौटता है?

 struct Widget { int i; int j; }; int main() { Widget widget = {1}; return widget.j; } 

 //     int[100] = {}; 

एग्रीगेट इनिशियलाइज़ेशन की एक अन्य महत्वपूर्ण संपत्ति ब्रैकेट्स (ब्रेस एलिसेंस) की चूक है। आपको क्या लगता है कि यह कार्यक्रम क्या रिटर्न देता है? इसमें एक Widget , जो दो int मूल्यों का एक समूह है, और Thingy , Widget और int का एक समूह है। यदि हम इसके लिए दो आरंभीकरण मान पास करते हैं तो क्या मिलता है: {1, 2} ?

 struct Widget { int i; int j; }; struct Thingy { Widget w; int k; }; int main() { Thingy t = {1, 2}; return tk; //   ? } 

स्टेटिक इनिशियलाइज़ेशन (C)

अंत में, स्थैतिक आरंभीकरण भी C से विरासत में मिला है: स्थैतिक चर हमेशा आरंभिक होते हैं। यह कई तरीकों से किया जा सकता है। स्थिर चर को एक स्थिर अभिव्यक्ति के साथ आरंभ किया जा सकता है। इस मामले में, संकलन समय पर शुरू होता है। यदि आप वैरिएबल को कोई मान असाइन नहीं करते हैं, तो इसे शून्य पर आरंभीकृत किया जाता है:

 static int i = 3; //   statit int j; //   int main() { return i + j; } 

यह प्रोग्राम 3 देता है, भले ही j इनिशियलाइज़ न किया गया हो। यदि चर को एक स्थिर द्वारा नहीं, बल्कि किसी ऑब्जेक्ट द्वारा प्रारंभ किया जाता है, तो समस्याएं उत्पन्न हो सकती हैं।

यहाँ एक वास्तविक पुस्तकालय से एक उदाहरण है जिस पर मैं काम कर रहा था:

 static Colour red = {255, 0, 0}; 

इसमें एक रंग वर्ग था, और प्राथमिक रंग (लाल, हरा, नीला) को स्थिर वस्तुओं के रूप में परिभाषित किया गया था। यह एक मान्य कार्रवाई है, लेकिन जैसे ही एक और स्थिर वस्तु दिखाई देती है जिसके प्रारंभिक में red का उपयोग किया जाता है, अनिश्चितता प्रकट होती है क्योंकि कोई कठोर क्रम नहीं होता है जिसमें चर आरंभिक होते हैं। आपका एप्लिकेशन अनइंस्टॉल किए गए वैरिएबल तक पहुंच सकता है, और फिर यह क्रैश हो जाता है। सौभाग्य से, सी ++ 11 में constexpr कंस्ट्रक्टर का उपयोग करना संभव हो गया, और फिर हम निरंतर प्रारंभ के साथ काम कर रहे हैं। इस मामले में, आरंभीकरण आदेश के साथ कोई समस्या नहीं हैं।

तो, चार प्रकार के आरंभीकरण C भाषा से विरासत में मिले हैं: डिफ़ॉल्ट आरंभीकरण, प्रतिलिपि बनाना, समुच्चय और स्थैतिक आरंभीकरण।

प्रत्यक्ष प्रारंभ (C ++ 98)

चलो C ++ 98 पर चलते हैं। शायद C से C ++ को अलग करने वाली सबसे महत्वपूर्ण विशेषता कंस्ट्रक्टर है। यहाँ एक निर्माता कॉल का एक उदाहरण है:

 Widget widget(1, 2); int(3); 

एक ही वाक्यविन्यास का उपयोग करके, आप अंतर्निर्मित और float जैसे अंतर्निहित प्रकारों को प्रारंभ कर सकते हैं। इस वाक्यविन्यास को प्रत्यक्ष आरंभीकरण कहा जाता है । इसे हमेशा तब निष्पादित किया जाता है जब हमारे पास कोष्ठक में एक तर्क होता है।

अंतर्निहित प्रकारों ( int , bool , float ) के लिए यहां कॉपी आरंभीकरण से कोई अंतर नहीं है। यदि हम उपयोगकर्ता प्रकारों के बारे में बात कर रहे हैं, तो, प्रतिलिपि आरंभीकरण के विपरीत, प्रत्यक्ष आरंभीकरण के साथ, आप कई तर्क पारित कर सकते हैं। दरअसल, इसके लिए प्रत्यक्ष आरंभीकरण का आविष्कार किया गया था।

इसके अलावा, एक प्रत्यक्ष आरंभीकरण एक रूपांतरण अनुक्रम निष्पादित नहीं करता है। इसके बजाय, निर्माणकर्ता को अधिभार संकल्प का उपयोग करके कहा जाता है। प्रत्यक्ष आरंभीकरण में फ़ंक्शन कॉल के समान सिंटैक्स होता है, और अन्य C ++ फ़ंक्शन के समान तर्क का उपयोग करता है।

इसलिए, एक स्पष्ट निर्माता के साथ स्थिति में, प्रत्यक्ष आरंभीकरण ठीक काम करता है, हालांकि प्रतिलिपि आरंभीकरण एक त्रुटि फेंकता है:

 struct Widget { explicit Widget(int) {} }; Widget w1 = 1; //  Widget w2(1); //    

दो बिल्डरों के साथ एक स्थिति में, जिनमें से एक स्पष्ट है, और दूसरा प्रकार में कम उपयुक्त है, पहले को प्रत्यक्ष आरंभीकरण के साथ कहा जाता है, और दूसरे को प्रतिलिपि के साथ कहा जाता है। इस स्थिति में, सिंटैक्स को बदलने से किसी अन्य निर्माता को कॉल करना होगा - यह अक्सर भूल जाता है:

 struct Widget { explicit Widget(int) {} Widget(double) {} }; Widget w1 = 1; //  Widget(double) Widget w2(1); //  Widget(int) 

कोष्ठक का उपयोग करते समय प्रत्यक्ष आरंभीकरण का उपयोग हमेशा किया जाता है, जिसमें एक अस्थायी वस्तु को आरम्भ करने के लिए, साथ ही साथ कोष्ठक में और cast भावों में इनिशियलाइज़र के साथ new एक्सप्रेशंस में कंस्ट्रक्टर इनवोकेशन नोटेशन का उपयोग किया जाता है:

 useWidget(Widget(1, 2)); //   auto* widget_ptr = new Widget(2, 3); // new-expression with (args) static_cast<Widget>(thingy); // cast 

यह सिंटैक्स तब तक मौजूद है जब तक C ++ स्वयं मौजूद है, और इसका एक महत्वपूर्ण दोष है कि निकोलाई ने अपने मुख्य भाषण में उल्लेख किया है: सबसे अधिक डरावने पार्स । इसका मतलब यह है कि संकलक जो कुछ भी घोषणा (घोषणा) के रूप में पढ़ सकता है, वह बिल्कुल एक घोषणा के रूप में पढ़ता है।

एक उदाहरण पर विचार करें जिसमें एक Widget वर्ग और एक Thingy वर्ग है, और एक Thingy निर्माता जो एक Widget प्राप्त करता है:

 struct Widget {}; struct Thingy { Thingy(Widget) {} }; int main () { Thingy thingy(Widget()); } 

पहली नज़र में, ऐसा लगता है कि Thingy प्रारंभ पर, डिफ़ॉल्ट Widget बनाया गया था, लेकिन इसे वास्तव में यहां फ़ंक्शन घोषित किया गया है। यह कोड एक फ़ंक्शन की घोषणा करता है जो इनपुट के रूप में एक और फ़ंक्शन प्राप्त करता है, जो इनपुट के रूप में कुछ भी प्राप्त नहीं करता है और एक Widget लौटाता है, और पहला फ़ंक्शन Thingy देता है। कोड त्रुटियों के बिना संकलित करता है, लेकिन यह संभावना नहीं है कि हमने ऐसा व्यवहार मांगा।

वैल्यू इनिशियलाइज़ेशन (C ++ 03)

चलो अगले संस्करण पर चलते हैं - C ++ 03। यह आमतौर पर स्वीकार किया जाता है कि इस संस्करण में कोई महत्वपूर्ण बदलाव नहीं हुए थे, लेकिन ऐसा नहीं है। C ++ 03 में, मान आरंभीकरण दिखाई दिया, जिसमें खाली कोष्ठक लिखे गए हैं:

 int main() { return int(); // UB  C++98, 0   C++03 } 

C ++ 98 में, अपरिभाषित व्यवहार यहां होता है क्योंकि प्रारंभ डिफ़ॉल्ट रूप से होता है, और C ++ 03 से शुरू होकर यह कार्यक्रम शून्य हो जाता है।

नियम यह है: यदि कोई उपयोगकर्ता-निर्धारित डिफ़ॉल्ट निर्माता है, तो मूल्य के साथ आरंभीकरण इस निर्माता को कॉल करता है, अन्यथा शून्य वापस कर दिया जाता है।

कस्टम निर्माता के साथ स्थिति पर अधिक विस्तार से विचार करें:

 struct Widget { int i; }; Widget get_widget() { return Widget(); // value initialization } int main() { return get_widget().i; } 

इस कार्यक्रम में, फ़ंक्शन नए Widget लिए मूल्य को इनिशियलाइज़ करता है और उसे लौटाता है। हम इस फ़ंक्शन को कॉल करते हैं और Widget ऑब्जेक्ट के तत्व i तक Widget । C ++ 03 के बाद से, यहां लौटा मूल्य शून्य है, क्योंकि कोई उपयोगकर्ता-निर्धारित डिफ़ॉल्ट निर्माता नहीं है। और अगर ऐसा कोई निर्माता मौजूद है, लेकिन i इनिशियलाइज़ नहीं करता, तो हमें अपरिभाषित व्यवहार मिलता है:

 struct Widget { Widget() {} //   int i; }; Widget get_widget() { return Widget(); // value initialization } int main() { return get_widget().i; //   ,  UB } 

यह ध्यान देने योग्य है कि "उपयोगकर्ता-परिभाषित" का अर्थ "उपयोगकर्ता-परिभाषित" नहीं है। इसका मतलब यह है कि उपयोगकर्ता को कंस्ट्रक्टर का शरीर प्रदान करना चाहिए, अर्थात् घुंघराले ब्रेसिज़। यदि ऊपर के उदाहरण में, कंस्ट्रक्टर बॉडी को = default साथ बदलें (यह सुविधा C ++ 11 में जोड़ी गई थी), तो प्रोग्राम का अर्थ बदल जाता है। अब हमारे पास उपयोगकर्ता (उपयोगकर्ता द्वारा परिभाषित) द्वारा परिभाषित एक कंस्ट्रक्टर है, लेकिन उपयोगकर्ता (उपयोगकर्ता द्वारा प्रदान) द्वारा प्रदान नहीं किया जाता है, इसलिए प्रोग्राम शून्य हो जाता है:

 struct Widget { Widget() = default; // user-defined,   user-provided int i; }; Widget get_widget() { return Widget(); // value initialization } int main() { return get_widget().i; //  0 } 

अब क्लास से बाहर Widget() = default करने की कोशिश करते Widget() = default । प्रोग्राम का अर्थ फिर से बदल गया है: Widget() = default को उपयोगकर्ता द्वारा प्रदान किया गया कंस्ट्रक्टर माना जाता है यदि यह कक्षा के बाहर है। कार्यक्रम फिर से अपरिभाषित व्यवहार देता है।

 struct Widget { Widget(); int i; }; Widget::Widget() = default; //  ,  user-provided Widget get_widget() { return Widget(); // value initialization } int main() { return get_widget().i; //    , UB } 

एक निश्चित तर्क है: एक वर्ग के बाहर परिभाषित एक कंस्ट्रक्टर किसी अन्य अनुवाद इकाई के अंदर हो सकता है। कंपाइलर इस कंस्ट्रक्टर को नहीं देख सकता है, क्योंकि यह किसी अन्य .cpp फ़ाइल में हो सकता है। इसलिए, कंपाइलर इस तरह के कंस्ट्रक्टर के बारे में कोई निष्कर्ष नहीं निकाल सकता है, और यह एक कंस्ट्रक्टर को एक कंस्ट्रक्टर से = default साथ अलग नहीं कर सकता है।

यूनिवर्सल इनिशियलाइज़ेशन (C ++ 11)

C ++ 11 में कई बहुत महत्वपूर्ण परिवर्तन थे। विशेष रूप से, सार्वभौमिक एकरूपता पेश की गई थी, जिसे मैं "गेंडा इनिशियलाइज़ेशन" कहना पसंद करता हूं क्योंकि यह सिर्फ जादुई है। आइए देखें कि वह क्यों दिखाई दी।

जैसा कि आप पहले ही देख चुके हैं, C ++ में विभिन्न व्यवहारों के साथ कई अलग-अलग आरंभीकरण वाक्यविन्यास हैं। कोष्ठक के साथ वेक्सिंग पार्स ने बहुत असुविधा का कारण बना। डेवलपर्स को यह भी पसंद नहीं था कि कुल संयोजन का उपयोग केवल सरणियों के साथ किया जा सकता है, लेकिन std::vector जैसे कंटेनरों के साथ नहीं। इसके बजाय, आपको .push_back और .push_back को निष्पादित .push_back , या सभी प्रकार के डरावना पुस्तकालयों का उपयोग करना होगा:

 //    ,  : std::vector<int> vec = {0, 1, 2, 3, 4}; //   : std::vector<int> vec; vec.reserve(5); vec.push_back(0); vec.push_back(1); vec.push_back(2); vec.push_back(3); vec.push_back(4); 

भाषा के रचनाकारों ने घुंघराले ब्रेसिज़ के साथ सिंटेक्स को पेश करके इन सभी समस्याओं को हल करने की कोशिश की लेकिन एक समान संकेत के बिना। यह माना जाता था कि यह सभी प्रकारों के लिए एक एकल वाक्यविन्यास होगा, जिसमें घुंघराले ब्रेसिज़ का उपयोग किया जाता है और इसमें कोई विकट समस्या नहीं होती है। ज्यादातर मामलों में, यह सिंटैक्स अपना काम करता है।

इस नए आरंभीकरण को सूची आरंभीकरण कहा जाता है , और यह दो प्रकारों में आता है: प्रत्यक्ष और प्रतिलिपि। पहले मामले में, बस घुंघराले ब्रेसिज़ का उपयोग किया जाता है, दूसरे में - एक समान चिह्न के साथ घुंघराले ब्रेसिज़:

 // direct-list-initialization Widget widget{1, 2}; // copy-list-initialization Widget widget = {1, 2}; 

आरंभीकरण के लिए प्रयुक्त सूची को ब्रेडेड-इनिट-सूची कहा जाता है। यह महत्वपूर्ण है कि यह सूची एक वस्तु नहीं है, इसका कोई प्रकार नहीं है। पूर्व संस्करणों से C ++ 11 पर स्विच करने से कुल प्रकार के साथ कोई समस्या नहीं होती है, इसलिए यह परिवर्तन महत्वपूर्ण नहीं है। लेकिन अब ब्रेसिज़ की सूची में नई विशेषताएं हैं। हालाँकि इसका कोई प्रकार नहीं है, इसे std::initializer_list रूपांतरित किया जा सकता std::initializer_list , यह एक विशेष प्रकार का नया प्रकार है। और अगर कोई कंस्ट्रक्टर है जो std::initializer_list को इनपुट के रूप में स्वीकार करता है, तो इस कंस्ट्रक्टर को कहा जाता है:

 template <typename T> class vector { //... vector(std::initializer_list<T> init); //   initializer_list }; std::vector<int> vec{0, 1, 2, 3, 4}; //  ^  

यह मुझे लगता है कि C ++ समिति के पक्ष से, std::initializer_list सबसे सफल समाधान नहीं था। उससे अच्छे से ज्यादा नुकसान।

के साथ शुरू करने के लिए, std::initializer_list एक निश्चित आकार का वेक्टर है जिसमें const एलिमेंट्स हैं। यही है, यह एक प्रकार है, इसमें कार्य begin और end हैं जो पुनरावृत्तियां वापस आती हैं, इसका अपना प्रकार का पुनरावृत्ति है, और इसका उपयोग करने के लिए, आपको एक विशेष शीर्ष लेख शामिल करना होगा। चूंकि std::initializer_list तत्व const , इसलिए इसे स्थानांतरित नहीं किया जा सकता है, इसलिए यदि उपरोक्त कोड में T केवल प्रकार की चाल का है, तो कोड निष्पादित नहीं किया जाएगा।

अगला, std::initializer_list एक वस्तु है। इसका उपयोग करना, हम, वास्तव में, वस्तुओं को बनाते हैं और स्थानांतरित करते हैं। एक नियम के रूप में, संकलक इसे अनुकूलित कर सकता है, लेकिन शब्दार्थ के दृष्टिकोण से, हम अभी भी अनावश्यक वस्तुओं से निपटते हैं।

कुछ महीने पहले ट्विटर पर एक पोल हुआ था: यदि आप समय में वापस जा सकते हैं और सी ++ से कुछ निकाल सकते हैं, तो आप क्या हटाएंगे? सभी वोटों में से अधिकांश को बिल्कुल initializer_list प्राप्त हुआ।

https://twitter.com/shafikyaghmour/status/1058031143935561728

, initializer_list . , .

, . , initializer_list , . :

 std::vector<int> v(3, 0); //   0, 0, 0 std::vector<int> v{3, 0}; //   3, 0 

vector int , , , — . . , initializer_list , 3 0.

:

 std::string s(48, 'a'); // "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" std::string s{48, 'a'}; // "0a" 

48 «», «0». , string initializer_list . 48 , . ASCII 48 — «0». , , , int char . . , , .

. , ? ?

 template <typename T, size_t N> auto test() { return std::vector<T>{N}; } int main () { return test<std::string, 3>().size(); } 

, .

.
— ( {a} )
( = {a} );
:

1. «» , std::initializer_list .
   — .
2. ,
   () .

.

1: = {a} , a ,
.

2: , {} .
, initializer_list .
Widget<int> widget{}\ ?

 template Typename<T> struct Widget { Widget(); Widget(std::initializer_list<T>); }; int main() { Widget<int> widget{}; //    ? } 

, , initializer_list , initializer_list . . , , initializer_list . , . , .

{} . , -, , Widget() = default Widget() {} — .

Widget() = default :

 struct Widget { Widget() = default; int i; }; int main() { Widget widget{}; //   (),   vexing parse return widget.i; //  0 } 

Widget() {} :

 struct Widget { Widget() {}; // user-provided  int i; }; int main() { Widget widget{}; //  ,    return widget.i; //  ,  UB } 

: , (narrowing conversions). int double , , :

 int main() { int i{2.0}; // ! } 

, double . C++11, , . :

 struct Widget { int i; int j; }; int main() { Widget widget = {1.0, 0.0}; //   ++11    C++98/03 } 

, , , , (brace elision). , , . , map . map , — :

 std::map<std::string, std::int> my_map {{"abc", 0}, {"def", 1}}; 

, . :

 std::vector<std::string> v1 {"abc", "def"}; // OK std::vector<std::string> v2 {{"abc", "def"}}; // ?? 

, , initializer_list . initializer_list , , , . , . , .

initializer_list — initializer_list , . , const char* . , string , char . . , , .

:

• ;
• .

. braced-init-list . :

 Widget<int> f1() { return {3, 0}; // copy-list    } void f2(Widget); f2({3, 0}); // copy-list   

, , braced-init-list . braced-init-list , .

, . StackOverflow , . , . , , :

 #include <iostream> struct A { A() {} A(const A&) {} }; struct B { B(const A&) {} }; void f(const A&) { std::cout << "A" << std::endl; } void f(const B&) { std::cout << "B" << std::endl; } int main() { A a; f( {a} ); // A f( {{a}} ); // ambiguous f( {{{a}}} ); // B f({{{{a}}}}); // no matching function } 

++14

, C++11 . , , . C++14. , .

, ++11 direct member initializers, . , direct member initializers . ++14, direct member initializers:

 struct Widget { int i = 0; int j = 0; }; Widget widget{1, 2}; //    C++14 

, auto . ++11 auto braced-init-list, std::initializer_list :

 int i = 3; // int int i(3); // int int i{3}; // int int i = {3}; // int auto i = 3; // int auto i(3); // int auto i{3}; //  ++11 — std::initializer_list<int> auto i = {3}; //  ++11 — std::initializer_list<int> 

: auto i{3} , int , std::initializer_list<int> . ++14 , auto i{3} int . , . , auto i = {3} std::initializer_list<int> . , : int , — initializer_list .

 auto i = 3; // int auto i(3); // int auto i{3}; //  ++14 — int,         auto i = {3}; //    std::initializer_list<int> 

, C++14 , , , , . , .

, ++14 :

• , , std::initializer_list .

  
  

• std::initializer_list move-only .

  
  

• c , emplace make_unique .

  
  

• , :

  
  
  • , -;
  • ;
  • auto .
  
  

• , , .

  
  

: assert(Widget(2,3)) , assert(Widget{2,3}) . , , , . , . .

C++

, ++.

int , . . — , .

: , , std::initializer_list , direct member initializers. , .

, é . .

 struct Point { int x = 0; int y = 0; }; setPosition(Point{2, 3}); takeWidget(Widget{}); 

braced-init-list — .

 setPosition({2, 3}); takeWidget({}); 

, , . , — , . , , , , , . , , initializer_list . : , , .

:

• = value

  
  

• = {args} = {} :

  
  
  • std::initializer_list
  • direct member initialisation ( (args) )
  
  

• {args} {} é

  
  

• (args)

  
  

, (args) vexing parse. . 2013 , , auto . , : auto i; — . , :

 auto widget = Widget(2, 3); 

, . , , vexing parse:

 auto thingy = Thingy(); 

« auto» («almost always auto», AAA), ++11 ++14 , , , std::atomic<int> :

 auto count = std::atomic<int>(0); // C++11/14:  // std::atomic is neither copyable nor movable 

, atomic . , , , , . ++17 , , (guaranteed copy elision):

 auto count = std::atomic<int>(0); // C++17: OK, guaranteed copy elision 

auto . — direct member initializers. auto .

++17 CTAD (class template argument deduction). , . . , CppCon, CTAD , . , ++17 , ++11 ++14, , . , , , , .

(++20)

++20, . , , : (designated initialization):

 struct Widget { int a; int b; int c; }; int main() { Widget widget{.a = 3, .c = 7}; }; 

, . , , . , . , b .

, , , . , .

, , 99, :

• , , . ++ , , . :

  
  

   Widget widget{.c = 7, .a = 3}; //  

  
  

  , .

  
  

• ++ , {.ce = 7}; , {.c{.e = 7}} :

  
  

   Widget widget{.ce = 7}; //  

  
  

• ++ , , :

  
  

   Widget widget{.a = 3, 7}; //  

  
  

• ++ . , -, , .

  
  

   int arr[3]{.[1] = 7}; //  

  
  

C++20

++20 , . ( wg21.link/p1008 ).

++17 , , . , , , :

 struct Widget { Widget() = delete; int i; int j; }; Widget widget1; //  Widget widget2{}; //   C++17,     C++20 

, , . ++20 . , . , . , , , .

( wg21.link/p1009 ). Braced-init-list new , : , ? — , : braced-init-list new :

 double a[]{1, 2, 3}; // OK double* p = new double[]{1, 2, 3}; //   C++17,   C++20 

, ++11 braced-init-list. ++ . , .

(C++20)

, ++20 . , . ++20 : ( wg21.link/p0960 ).

 struct Widget { int i; int j; }; Widget widget(1, 2); //   C++20 

. , emplace make_unique . . : auto , : 58.11 .

 struct Widget { int i; int j; }; auto widget = Widget(1, 2); 

, :

 int arr[3](0, 1, 2); 

, : uniform 2.0. . , , , , . — initializer_list : , , — . , . , - , — . .

, . direct member initializers. auto . direct member initializers — , . , . — , .

, , . — , — . , .

, , C++ Russia 2019 Piter «Type punning in modern C++» . , ++20, , , «» ++ , .