C++ रशिया: हे कसे घडले

जर नाटकाच्या सुरुवातीला तुम्ही म्हणाल की भिंतीवर C++ कोड टांगलेला आहे, तर शेवटी ते तुमच्या पायावर गोळ्या घालणार आहे.

Bjarne Stroustrup

31 ऑक्टोबर ते 1 नोव्हेंबर या कालावधीत, सेंट पीटर्सबर्ग येथे C++ रशिया पिटर परिषद आयोजित करण्यात आली होती - रशियामधील मोठ्या प्रमाणावरील प्रोग्रामिंग परिषदांपैकी एक, JUG Ru ग्रुपने आयोजित केली होती. अतिथी स्पीकर्समध्ये C++ मानक समितीचे सदस्य, CppCon स्पीकर, O'Reilly पुस्तकाचे लेखक आणि LLVM, libc++ आणि बूस्ट सारख्या प्रकल्पांचे देखभाल करणारे समाविष्ट आहेत. या परिषदेचे उद्दिष्ट अनुभवी C++ विकसकांसाठी आहे ज्यांना त्यांचे कौशल्य अधिक सखोल करायचे आहे आणि थेट संप्रेषणातील अनुभवांची देवाणघेवाण करायची आहे. विद्यार्थी, पदवीधर विद्यार्थी आणि विद्यापीठातील शिक्षकांना खूप छान सवलत दिली जाते.

परिषदेची मॉस्को आवृत्ती पुढील वर्षी एप्रिलच्या सुरुवातीला भेट देण्यासाठी उपलब्ध असेल, परंतु त्यादरम्यान आमचे विद्यार्थी तुम्हाला शेवटच्या कार्यक्रमात कोणत्या मनोरंजक गोष्टी शिकल्या ते सांगतील. 

पासून फोटो परिषद अल्बम

ओह

नॅशनल रिसर्च युनिव्हर्सिटी हायर स्कूल ऑफ इकॉनॉमिक्स - सेंट पीटर्सबर्गमधील दोन विद्यार्थ्यांनी या पोस्टवर काम केले:

• लिझा वासिलेंको ही 4 थी वर्षाची अंडरग्रेजुएट विद्यार्थिनी आहे जी अप्लाइड मॅथेमॅटिक्स आणि कॉम्प्युटर सायन्स प्रोग्रामचा भाग म्हणून प्रोग्रामिंग भाषांचा अभ्यास करते. विद्यापीठात माझ्या पहिल्या वर्षात C++ भाषेशी परिचित झाल्यानंतर, त्यानंतर उद्योगात इंटर्नशिपद्वारे मला तिच्यासोबत काम करण्याचा अनुभव मिळाला. सर्वसाधारणपणे प्रोग्रामिंग भाषा आणि विशेषतः कार्यात्मक प्रोग्रामिंगची आवड कॉन्फरन्समधील अहवालांच्या निवडीवर आपली छाप सोडली.
• Danya Smirnov ही मास्टर्स प्रोग्राम "प्रोग्रामिंग आणि डेटा विश्लेषण" ची 1ल्या वर्षाची विद्यार्थिनी आहे. शाळेत असताना, मी C++ मध्ये ऑलिम्पियाड समस्या लिहिल्या, आणि मग असे झाले की भाषा सतत शैक्षणिक क्रियाकलापांमध्ये आली आणि अखेरीस मुख्य कार्यरत भाषा बनली. माझे ज्ञान सुधारण्यासाठी आणि नवीन संधींबद्दल जाणून घेण्यासाठी मी परिषदेत सहभागी होण्याचे ठरवले.

वृत्तपत्रात, प्राध्यापक नेतृत्व अनेकदा आमच्या विशेषतेशी संबंधित शैक्षणिक कार्यक्रमांची माहिती सामायिक करते. सप्टेंबरमध्ये आम्ही C++ रशियाबद्दल माहिती पाहिली आणि श्रोते म्हणून नोंदणी करण्याचा निर्णय घेतला. अशा परिषदांमध्ये सहभागी होण्याचा आमचा हा पहिलाच अनुभव आहे.

परिषद रचना

• अहवाल

दोन दिवसांच्या कालावधीत, तज्ञांनी 30 अहवाल वाचले, ज्यात अनेक चर्चेत विषय समाविष्ट आहेत: लागू केलेल्या समस्यांचे निराकरण करण्यासाठी भाषेच्या वैशिष्ट्यांचा कल्पक वापर, नवीन मानकांच्या संदर्भात आगामी भाषा अद्यतने, C++ डिझाइनमधील तडजोड आणि त्यांच्या परिणामांसह कार्य करताना खबरदारी, उदाहरणे मनोरंजक प्रकल्प आर्किटेक्चर, तसेच भाषेच्या पायाभूत सुविधांचे काही तपशील. एकाच वेळी तीन प्रदर्शने झाली, बहुतेकदा दोन रशियन आणि एक इंग्रजीमध्ये.

• चर्चा झोन

भाषणानंतर, सर्व न विचारलेले प्रश्न आणि अपूर्ण चर्चा मार्कर बोर्डसह सुसज्ज स्पीकर्सशी संवाद साधण्यासाठी खास नियुक्त केलेल्या भागात हस्तांतरित करण्यात आल्या. आनंददायी संभाषणांसह भाषणांमधील ब्रेक दूर करण्याचा एक चांगला मार्ग.

• लाइटनिंग चर्चा आणि अनौपचारिक चर्चा

जर तुम्हाला एक छोटासा अहवाल द्यायचा असेल, तर तुम्ही संध्याकाळच्या लाइटनिंग टॉकसाठी व्हाईटबोर्डवर साइन अप करू शकता आणि कॉन्फरन्स विषयावरील कोणत्याही गोष्टीबद्दल बोलण्यासाठी पाच मिनिटे वेळ मिळवू शकता. उदाहरणार्थ, C++ साठी सॅनिटायझर्सचा त्वरित परिचय (काहींसाठी ते नवीन होते) किंवा साइन वेव्ह जनरेशनमधील बगबद्दलची कथा जी फक्त ऐकली जाऊ शकते, परंतु पाहिली जात नाही.

दुसरा फॉरमॅट म्हणजे "विथ अ हार्ट टू हार्ट कमिटी" हे पॅनल डिस्कशन. स्टेजवर स्टँडर्डायझेशन कमिटीचे काही सदस्य आहेत, प्रोजेक्टरवर एक फायरप्लेस आहे (अधिकृतपणे - प्रामाणिक वातावरण तयार करण्यासाठी, परंतु कारण "सर्व काही आगीत आहे" हे मजेदार दिसते), मानक आणि C++ च्या सामान्य दृष्टीबद्दल प्रश्न. , गरमागरम तांत्रिक चर्चा आणि होलीवारांशिवाय. असे दिसून आले की समितीमध्ये जिवंत लोक देखील आहेत ज्यांना एखाद्या गोष्टीबद्दल पूर्णपणे खात्री नसते किंवा कदाचित काहीतरी माहित नसते.

हॉलिव्हरच्या चाहत्यांसाठी, तिसरा कार्यक्रम केसवर राहिला - बीओएफ सत्र “गो विरुद्ध सी++”. आम्ही एक गो प्रेमी, एक C++ प्रेमी घेतो, सत्र सुरू होण्यापूर्वी ते एकत्रितपणे एका विषयावर 100500 स्लाइड्स तयार करतात (जसे की C++ मधील पॅकेजमधील समस्या किंवा Go मधील जेनेरिकची कमतरता), आणि नंतर ते आपापसात सजीव चर्चा करतात आणि प्रेक्षकांसह, आणि प्रेक्षक एकाच वेळी दोन दृष्टिकोन समजून घेण्याचा प्रयत्न करतात. हॉलिव्हर संदर्भाबाहेर सुरू झाल्यास, नियंत्रक हस्तक्षेप करतो आणि पक्षांमध्ये समेट करतो. हे स्वरूप व्यसनाधीन आहे: सुरुवातीच्या काही तासांनंतर, फक्त अर्ध्या स्लाइड पूर्ण झाल्या. शेवटाला खूप गती द्यावी लागली.

• भागीदार उभा आहे

कॉन्फरन्सच्या भागीदारांचे प्रतिनिधित्व हॉलमध्ये केले गेले - स्टँडवर त्यांनी सध्याच्या प्रकल्पांबद्दल बोलले, इंटर्नशिप आणि रोजगाराची ऑफर दिली, क्विझ आणि लहान स्पर्धा आयोजित केल्या आणि छान बक्षिसे देखील दिली. त्याच वेळी, काही कंपन्यांनी मुलाखतीच्या सुरुवातीच्या टप्प्यात जाण्याची ऑफर देखील दिली, जे केवळ अहवाल ऐकण्यासाठी आले नाहीत त्यांच्यासाठी उपयुक्त ठरू शकतात.

अहवालांचे तांत्रिक तपशील

आम्ही दोन्ही दिवस अहवाल ऐकले. कधीकधी समांतर अहवालांमधून एक अहवाल निवडणे कठीण होते - आम्ही विभक्त होण्यास आणि विश्रांती दरम्यान मिळालेल्या ज्ञानाची देवाणघेवाण करण्यास सहमती दिली. आणि असे असतानाही बरेच काही शिल्लक राहिलेले दिसते. येथे आम्ही काही अहवालांच्या सामग्रीबद्दल बोलू इच्छितो जे आम्हाला सर्वात मनोरंजक वाटले

कम्पायलर ऑप्टिमायझेशनच्या प्रिझमद्वारे C++ मधील अपवाद, रोमन रुस्याएव

पासून स्लाइड करा सादरीकरणे

शीर्षकात सुचविल्याप्रमाणे, रोमनने उदाहरण म्हणून LLVM वापरून अपवादांसह काम करण्याकडे पाहिले. त्याच वेळी, जे लोक त्यांच्या कामात क्लॅंग वापरत नाहीत त्यांच्यासाठी, कोड संभाव्यतः कसा ऑप्टिमाइझ केला जाऊ शकतो याची काही कल्पना या अहवालात दिली जाऊ शकते. हे असे आहे कारण कंपायलर आणि संबंधित मानक लायब्ररींचे विकसक एकमेकांशी संवाद साधतात आणि अनेक यशस्वी निराकरणे एकरूप होऊ शकतात.

म्हणून, अपवाद हाताळण्यासाठी, तुम्हाला बर्‍याच गोष्टी कराव्या लागतील: हँडलिंग कोड (असल्यास) किंवा सध्याच्या स्तरावर विनामूल्य संसाधनांवर कॉल करा आणि स्टॅकला अधिक स्पिन करा. हे सर्व या वस्तुस्थितीकडे नेत आहे की कॉम्पायलर संभाव्यत: अपवाद टाकणाऱ्या कॉलसाठी अतिरिक्त सूचना जोडतो. म्हणून, जर अपवाद प्रत्यक्षात उपस्थित केला गेला नाही, तर कार्यक्रम तरीही अनावश्यक क्रिया करेल. कोणत्याही प्रकारे ओव्हरहेड कमी करण्यासाठी, LLVM मध्ये अपवाद हाताळणी कोड जोडण्याची आवश्यकता नाही किंवा "अतिरिक्त" सूचनांची संख्या कमी केली जाऊ शकते अशा परिस्थितीचे निर्धारण करण्यासाठी अनेक हेरिस्टिक्स आहेत.

स्पीकर त्यापैकी सुमारे एक डझन तपासतो आणि दोन्ही परिस्थिती दाखवतो जेथे ते प्रोग्रामच्या अंमलबजावणीला गती देण्यास मदत करतात आणि जेथे या पद्धती लागू नाहीत.

अशा प्रकारे, रोमन रुस्याएव विद्यार्थ्यांना या निष्कर्षापर्यंत पोहोचवतात की अपवाद हाताळणी असलेला कोड नेहमी शून्य ओव्हरहेडसह कार्यान्वित केला जाऊ शकत नाही आणि खालील सल्ला देतो:

• लायब्ररी विकसित करताना, तत्त्वतः अपवाद सोडून देणे योग्य आहे;
• अपवाद अजूनही आवश्यक असल्यास, जेव्हा शक्य असेल तेव्हा सर्वत्र noexcept (आणि const) मॉडिफायर्स जोडणे फायदेशीर आहे जेणेकरून कंपाइलर शक्य तितके ऑप्टिमाइझ करू शकेल.

सर्वसाधारणपणे, स्पीकरने या मताची पुष्टी केली की अपवाद कमीतकमी वापरले जातात किंवा पूर्णपणे सोडून दिले जातात.

अहवालाच्या स्लाइड्स पुढील लिंकवर उपलब्ध आहेत: [“LLVM कंपाइलर ऑप्टिमायझेशनच्या लेन्सद्वारे C++ अपवाद”]

जनरेटर, कोरोटीन आणि इतर मेंदू-अनरोलिंग गोडपणा, आदि शवित

पासून स्लाइड करा सादरीकरणे

C++20 मधील नवकल्पनांना समर्पित या परिषदेतील अनेक अहवालांपैकी एक अहवाल केवळ त्याच्या रंगीत सादरीकरणासाठीच नव्हे, तर संग्रह प्रक्रिया तर्कशास्त्रातील (लूप, कॉलबॅकसाठी) विद्यमान समस्यांच्या स्पष्ट ओळखीसाठी देखील संस्मरणीय होता.

आदि शवित खालील गोष्टींवर प्रकाश टाकतात: सध्या उपलब्ध पद्धती संपूर्ण संग्रहातून जातात आणि काही अंतर्गत मध्यवर्ती स्थितीत प्रवेश प्रदान करत नाहीत (किंवा ते कॉलबॅकच्या बाबतीत करतात, परंतु मोठ्या संख्येने अप्रिय दुष्परिणामांसह, जसे की कॉलबॅक हेल) . असे दिसते की तेथे पुनरावृत्ती करणारे आहेत, परंतु त्यांच्यासह सर्व काही इतके गुळगुळीत नाही: तेथे कोणतेही सामान्य प्रवेश आणि निर्गमन बिंदू नाहीत (प्रारंभ → शेवट विरुद्ध rbegin → रेंड आणि असेच), हे स्पष्ट नाही की आपण किती वेळ पुनरावृत्ती करू? C++ 20 सह प्रारंभ करून, या समस्या सोडवल्या जातात!

पहिला पर्याय: श्रेणी. पुनरावृत्त्यांना गुंडाळल्याने, आम्हाला पुनरावृत्तीच्या सुरूवातीस आणि शेवटी एक सामान्य इंटरफेस मिळतो आणि आम्हाला रचना करण्याची क्षमता देखील मिळते. हे सर्व पूर्ण डेटा प्रोसेसिंग पाइपलाइन तयार करणे सोपे करते. परंतु सर्व काही इतके गुळगुळीत नाही: गणना लॉजिकचा एक भाग विशिष्ट पुनरावृत्तीच्या अंमलबजावणीमध्ये स्थित आहे, जो कोड समजून घेण्यासाठी आणि डीबग करण्यासाठी गुंतागुंत करू शकतो.

पासून स्लाइड करा सादरीकरणे

बरं, या प्रकरणात, C++20 ने कोरोटिन जोडले (ज्यांचे वर्तन पायथनमधील जनरेटरसारखे कार्य करते): इंटरमीडिएट स्टेट जतन करून काही वर्तमान मूल्य परत करून अंमलबजावणी पुढे ढकलली जाऊ शकते. अशाप्रकारे, आम्ही केवळ डेटा दिसतो त्याप्रमाणे कार्य करत नाही तर विशिष्ट कॉरोटिनमध्ये सर्व तर्क अंतर्भूत देखील करतो.

परंतु मलममध्ये एक माशी आहे: याक्षणी ते विद्यमान कंपाइलर्सद्वारे केवळ अंशतः समर्थित आहेत आणि आम्हाला पाहिजे तितक्या सुबकपणे अंमलात आणले जात नाहीत: उदाहरणार्थ, कोरोटिनमध्ये संदर्भ आणि तात्पुरती वस्तू वापरणे अद्याप योग्य नाही. शिवाय, coroutines काय असू शकतात यावर काही निर्बंध आहेत आणि constexpr फंक्शन्स, कन्स्ट्रक्टर/डिस्ट्रक्टर आणि मुख्य यांचा या यादीमध्ये समावेश नाही.

अशाप्रकारे, डेटा प्रोसेसिंग लॉजिकच्या साधेपणासह कोरोटीन समस्यांचे महत्त्वपूर्ण भाग सोडवतात, परंतु त्यांच्या सध्याच्या अंमलबजावणीमध्ये सुधारणा आवश्यक आहे.

सामुग्री:

• C++ रशियाच्या स्लाइड्स - ["जनरेटर, कोरोटीन आणि इतर मेंदू-अनरोलिंग गोडपणा"]
• CppCon 2019 च्या अहवालाचे व्हिडिओ रेकॉर्डिंग

Yandex.Taxi, Anton Polukhin कडून C++ युक्त्या

माझ्या व्यावसायिक क्रियाकलापांमध्ये, कधीकधी मला पूर्णपणे सहाय्यक गोष्टी लागू कराव्या लागतात: अंतर्गत इंटरफेस आणि काही लायब्ररीचे API, लॉगिंग किंवा पार्सिंग दरम्यान एक आवरण. या प्रकरणात, सहसा कोणत्याही अतिरिक्त ऑप्टिमायझेशनची आवश्यकता नसते. परंतु हे घटक RuNet वरील काही सर्वात लोकप्रिय सेवांमध्ये वापरले असल्यास काय? अशा परिस्थितीत, आपल्याला एकट्या लॉगच्या प्रति तास टेराबाइट्सवर प्रक्रिया करावी लागेल! मग प्रत्येक मिलीसेकंद मोजला जातो आणि म्हणून आपल्याला विविध युक्त्या वापराव्या लागतील - अँटोन पोलुखिन त्यांच्याबद्दल बोलले.

कदाचित सर्वात मनोरंजक उदाहरण म्हणजे पॉइंटर-टू-इंप्लिमेंटेशन (पिंपल) पॅटर्नची अंमलबजावणी. 

#include <third_party/json.hpp> //PROBLEMS! 
struct Value { 
    Value() = default; 
    Value(Value&& other) = default; 
    Value& operator=(Value&& other) = default; 
    ~Value() = default; 

    std::size_t Size() const { return data_.size(); } 

private: 
    third_party::Json data_; 
};

या उदाहरणात, प्रथम मला बाह्य लायब्ररीच्या शीर्षलेख फायलींपासून मुक्त करायचे आहे - हे जलद संकलित करेल आणि आपण संभाव्य नाव विवाद आणि इतर तत्सम त्रुटींपासून स्वतःचे संरक्षण करू शकता. 

ठीक आहे, आम्ही #include .cpp फाईलमध्ये हलवले: आम्हाला गुंडाळलेल्या API चे फॉरवर्ड-डिक्लेरेशन तसेच std::unique_ptr आवश्यक आहे. आता आमच्याकडे डायनॅमिक ऍलोकेशन्स आणि इतर अप्रिय गोष्टी आहेत जसे की डेटाच्या समूहामध्ये विखुरलेला डेटा आणि कमी हमी. std::aligned_storage हे सर्व मदत करू शकते. 

struct Value { 
// ... 
private: 
    using JsonNative = third_party::Json; 
    const JsonNative* Ptr() const noexcept; 
    JsonNative* Ptr() noexcept; 

    constexpr std::size_t kImplSize = 32; 
    constexpr std::size_t kImplAlign = 8; 
    std::aligned_storage_t<kImplSize, kImplAlign> data_; 
};

फक्त समस्या: आम्हाला प्रत्येक रॅपरसाठी आकार आणि संरेखन निर्दिष्ट करणे आवश्यक आहे - चला आमचे पिंपल टेम्पलेट पॅरामीटर्ससह बनवूया , काही अनियंत्रित मूल्ये वापरू आणि डिस्ट्रक्टरला एक चेक जोडू ज्याचा आम्ही सर्व काही बरोबर अंदाज केला आहे. : 

~FastPimpl() noexcept { 
    validate<sizeof(T), alignof(T)>(); 
    Ptr()->~T(); 
}

template <std::size_t ActualSize, std::size_t ActualAlignment>
static void validate() noexcept { 
    static_assert(
        Size == ActualSize, 
        "Size and sizeof(T) mismatch"
    ); 
    static_assert(
        Alignment == ActualAlignment, 
        "Alignment and alignof(T) mismatch"
    ); 
}

डिस्ट्रक्टरवर प्रक्रिया करताना T आधीच परिभाषित केले असल्याने, हा कोड योग्यरित्या पार्स केला जाईल आणि संकलनाच्या टप्प्यावर तो आवश्यक आकार आणि संरेखन मूल्ये आउटपुट करेल जे त्रुटी म्हणून प्रविष्ट करणे आवश्यक आहे. अशा प्रकारे, एका अतिरिक्त संकलनाच्या खर्चावर, आम्ही गुंडाळलेल्या वर्गांच्या डायनॅमिक वाटपापासून मुक्त होतो, अंमलबजावणीसह .cpp फाइलमध्ये API लपवतो आणि प्रोसेसरद्वारे कॅशिंगसाठी अधिक योग्य डिझाइन देखील मिळवतो.

लॉगिंग आणि पार्सिंग कमी प्रभावी वाटले आणि म्हणून या पुनरावलोकनात उल्लेख केला जाणार नाही.

अहवालाच्या स्लाइड्स पुढील लिंकवर उपलब्ध आहेत: ["टॅक्सीच्या C++ युक्त्या"]

तुमचा कोड ड्राय ठेवण्यासाठी आधुनिक तंत्रे, ब्योर्न फाहलर

या चर्चेत, ब्योर्न फॅहलर वारंवार स्थिती तपासणीच्या शैलीत्मक दोषांचा सामना करण्यासाठी अनेक भिन्न मार्ग दर्शवितो:

assert(a == IDLE || a == CONNECTED || a == DISCONNECTED);

परिचित आवाज? अलीकडील मानकांमध्ये सादर केलेल्या अनेक शक्तिशाली C++ तंत्रांचा वापर करून, तुम्ही कोणत्याही कामगिरीच्या दंडाशिवाय समान कार्यक्षमतेची अंमलबजावणी करू शकता. तुलना करा:   

assert(a == any_of(IDLE, CONNECTED, DISCONNECTED));

अनिश्चित संख्येच्या तपासण्या हाताळण्यासाठी, तुम्हाला ताबडतोब विविध टेम्पलेट्स आणि फोल्ड एक्सप्रेशन्स वापरण्याची आवश्यकता आहे. आपण enum च्या state_type घटकातील अनेक व्हेरिएबल्सची समानता तपासू इच्छितो असे गृहीत धरू. सर्वात पहिली गोष्ट जी मनात येते ती म्हणजे हेल्पर फंक्शन लिहिणे is_any_of:

enum state_type { IDLE, CONNECTED, DISCONNECTED };

template <typename ... Ts>
bool is_any_of(state_type s, const Ts& ... ts) { 
    return ((s == ts) || ...); 
}

मध्यंतरीचा हा निकाल निराशाजनक आहे. आतापर्यंत कोड अधिक वाचनीय होत नाही:

assert(is_any_of(state, IDLE, DISCONNECTING, DISCONNECTED)); 

नॉन-टाइप टेम्पलेट पॅरामीटर्स परिस्थिती थोडी सुधारण्यास मदत करतील. त्यांच्या मदतीने, आम्ही enum चे असंख्य घटक टेम्पलेट पॅरामीटर्सच्या सूचीमध्ये हस्तांतरित करू: 

template <state_type ... states>
bool is_any_of(state_type t) { 
    return ((t == states) | ...); 
}
	
assert(is_any_of<IDLE, DISCONNECTING, DISCONNECTED>(state)); 

नॉन-टाइप टेम्प्लेट पॅरामीटर (C++17) मध्ये ऑटो वापरून, दृष्टीकोन फक्त स्टेट_टाइप घटकांसोबतच नव्हे तर नॉन-टाइप टेम्प्लेट पॅरामीटर्स म्हणून वापरल्या जाऊ शकणार्‍या आदिम प्रकारांसह तुलना करण्यासाठी सामान्यीकरण करतो:

template <auto ... alternatives, typename T>
bool is_any_of(const T& t) {
    return ((t == alternatives) | ...);
}

या क्रमिक सुधारणांद्वारे, तपासण्यांसाठी इच्छित प्रवाही वाक्यरचना साध्य केली जाते:

template <class ... Ts>
struct any_of : private std::tuple<Ts ...> { 
// поленимся и унаследуем конструкторы от tuple 
        using std::tuple<Ts ...>::tuple;
        template <typename T>
        bool operator ==(const T& t) const {
                return std::apply(
                        [&t](const auto& ... ts) {
                                return ((ts == t) || ...);
                        },
                        static_cast<const std::tuple<Ts ...>&>(*this));
        }
};

template <class ... Ts>
any_of(Ts ...) -> any_of<Ts ... >;
 
assert(any_of(IDLE, DISCONNECTING, DISCONNECTED) == state);

या उदाहरणामध्ये, वजावट मार्गदर्शक कंपायलरला इच्छित संरचना टेम्पलेट पॅरामीटर्स सुचवण्यासाठी कार्य करते, ज्याला कन्स्ट्रक्टर वितर्कांचे प्रकार माहित असतात. 

पुढे - अधिक मनोरंजक. ब्योर्न == च्या पलीकडे तुलना ऑपरेटरसाठी परिणामी कोडचे सामान्यीकरण कसे करावे आणि नंतर अनियंत्रित ऑपरेशन्ससाठी शिकवते. मार्गात, lambda फंक्शन्स (C++20) मधील no_unique_address विशेषता (C++20) आणि टेम्प्लेट पॅरामीटर्स सारखी वैशिष्ट्ये वापरण्याची उदाहरणे वापरून स्पष्ट केली आहेत. (होय, आता लॅम्बडा वाक्यरचना लक्षात ठेवणे आणखी सोपे आहे - हे सर्व प्रकारच्या कंसाच्या सलग चार जोड्या आहेत.) फंक्शन्सचा कन्स्ट्रक्टर तपशील म्हणून वापर केलेला अंतिम उपाय खरोखरच माझ्या आत्म्याला उबदार करतो, लॅम्बडाच्या सर्वोत्तम परंपरांमध्ये टपल या अभिव्यक्तीचा उल्लेख न करता कॅल्क्युलस

शेवटी, ते पॉलिश करण्यास विसरू नका:

• लक्षात ठेवा की lambdas विनामूल्य आहेत constexpr; 
• चला परिपूर्ण फॉरवर्डिंग जोडू आणि लॅम्बडा क्लोजरमधील पॅरामीटर पॅकच्या संबंधात त्याचे कुरूप वाक्यरचना पाहू;
• कंपाइलरला कंडिशनल नोएक्‍स्‍प्‍प्‍टसह ऑप्टिमायझेशनसाठी अधिक संधी देऊ या; 
• लॅम्बडासच्या स्पष्ट रिटर्न व्हॅल्यूजमुळे टेम्पलेट्समध्ये अधिक समजण्यायोग्य त्रुटी आउटपुटची काळजी घेऊया. हे कंपाइलरला टेम्प्लेट फंक्शन प्रत्यक्षात कॉल करण्यापूर्वी अधिक तपासण्या करण्यास भाग पाडेल - टाइप तपासण्याच्या टप्प्यावर. 

तपशीलांसाठी, कृपया व्याख्यान सामग्री पहा: 

• स्लाइड्सचा अहवाल द्या: [तुमचा कोड कोरडा ठेवण्यासाठी आधुनिक तंत्र]
• Github वर स्त्रोत कोड
• लेखकाचा ब्लॉग लेख

आमचे इंप्रेशन

C++ रशियामधील आमचा पहिला सहभाग त्याच्या तीव्रतेसाठी संस्मरणीय होता. मला C++ रशियाचा एक प्रामाणिक कार्यक्रम म्हणून ठसा मिळाला, जिथे प्रशिक्षण आणि थेट संप्रेषण यांच्यातील ओळ जवळजवळ अगोदरच आहे. सर्व काही, स्पीकर्सच्या मूडपासून ते इव्हेंट पार्टनर्सच्या स्पर्धांपर्यंत, जोरदार चर्चेसाठी अनुकूल आहे. कॉन्फरन्सच्या सामग्रीमध्ये अहवालांचा समावेश आहे, ज्यामध्ये C++ नवकल्पना, मोठ्या प्रकल्पांचे केस स्टडी आणि वैचारिक वास्तुशास्त्रीय विचारांचा समावेश आहे. परंतु कार्यक्रमाच्या सामाजिक घटकाकडे दुर्लक्ष करणे अयोग्य ठरेल, जे केवळ C++ च्या संबंधात भाषेतील अडथळे दूर करण्यास मदत करतात.

अशा कार्यक्रमात सहभागी होण्याची संधी दिल्याबद्दल आम्ही संमेलन आयोजकांचे आभार मानतो!
तुम्ही C++ रशियाच्या भूतकाळ, वर्तमान आणि भविष्याविषयी आयोजकांची पोस्ट पाहिली असेल JUG Ru ब्लॉगवर.

वाचल्याबद्दल धन्यवाद, आणि आम्हाला आशा आहे की आमचे कार्यक्रम पुन्हा सांगणे उपयुक्त ठरले!

स्त्रोत: www.habr.com