C++ रूस: यो कसरी भयो

यदि नाटकको सुरुमा तपाईंले भित्तामा C++ कोड झुण्डिएको छ भनी भन्नुभयो भने अन्त्यमा तपाईंलाई खुट्टामा गोली हान्न बाध्य हुन्छ।

Bjarne Stroustrup

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

सम्मेलनको मस्को संस्करण अर्को वर्ष अप्रिलको सुरुमा भ्रमण गर्न उपलब्ध हुनेछ, तर यस बीचमा हाम्रा विद्यार्थीहरूले तपाईंलाई अन्तिम कार्यक्रममा के सिकेका रोचक कुराहरू बताउनेछन्। 

बाट फोटो सम्मेलन एल्बम

О нас

नेशनल रिसर्च युनिभर्सिटी हायर स्कूल अफ इकोनोमिक्स - सेन्ट पीटर्सबर्गका दुई विद्यार्थीहरूले यस पोस्टमा काम गरे:

• Liza Vasilenko एप्लाइड गणित र कम्प्यूटर विज्ञान कार्यक्रम को एक भाग को रूप मा प्रोग्रामिंग भाषाहरु को अध्ययन को 4th वर्ष स्नातक विद्यार्थी हो। विश्वविद्यालयमा मेरो पहिलो वर्षमा C++ भाषासँग परिचित भएपछि, मैले पछि उद्योगमा इन्टर्नशिपहरू मार्फत यससँग काम गर्ने अनुभव प्राप्त गरें। सामान्यतया प्रोग्रामिङ भाषाहरू र विशेष गरी कार्यात्मक प्रोग्रामिङको लागि जुनूनले सम्मेलनमा रिपोर्टहरूको छनोटमा आफ्नो छाप छोड्यो।
• Danya Smirnov मास्टर कार्यक्रम "प्रोग्रामिङ र डाटा विश्लेषण" को 1st वर्ष विद्यार्थी हो। स्कूलमा छँदा, मैले C++ मा ओलम्पियाड समस्याहरू लेखें, र त्यसपछि यो कुनै न कुनै रूपमा भयो कि भाषा निरन्तर शैक्षिक गतिविधिहरूमा आयो र अन्ततः मुख्य कार्य भाषा बन्यो। मैले आफ्नो ज्ञान सुधार गर्न र नयाँ अवसरहरूको बारेमा पनि जान्नको लागि सम्मेलनमा भाग लिने निर्णय गरें।

न्यूजलेटरमा, संकाय नेतृत्वले प्रायः हाम्रो विशेषतासँग सम्बन्धित शैक्षिक घटनाहरूको बारेमा जानकारी साझा गर्दछ। सेप्टेम्बरमा हामीले C++ रूसको बारेमा जानकारी देख्यौं र श्रोताहरूको रूपमा दर्ता गर्ने निर्णय गर्यौं। यस्ता सम्मेलनमा भाग लिने हाम्रो पहिलो अनुभव हो ।

सम्मेलन संरचना

• रिपोर्टहरू

दुई दिनको अवधिमा, विशेषज्ञहरूले धेरै तातो विषयहरू समेटेर 30 वटा रिपोर्टहरू पढे: लागू समस्याहरू समाधान गर्न भाषा सुविधाहरूको सरल प्रयोग, नयाँ मानकको सम्बन्धमा आगामी भाषा अद्यावधिकहरू, C++ डिजाइनमा सम्झौता र तिनीहरूका परिणामहरूसँग काम गर्दा सावधानीहरू, उदाहरणहरू। रोचक परियोजना वास्तुकलाको, साथै भाषा पूर्वाधारको केही अन्डर-द-हुड विवरणहरू। तीन प्रदर्शनहरू एकैसाथ भए, प्रायः दुई रूसी र एक अंग्रेजीमा।

• छलफल क्षेत्रहरू

भाषण पछि, सबै न सोधिएका प्रश्नहरू र अधूरा छलफलहरू मार्कर बोर्डहरूसँग सुसज्जित स्पिकरहरूसँग सञ्चारको लागि विशेष रूपमा तोकिएको क्षेत्रमा स्थानान्तरण गरियो। रमाइलो कुराकानीको साथ भाषणहरू बीचको ब्रेकलाई टाढा राख्नको लागि राम्रो तरिका।

• बिजुली वार्ता र अनौपचारिक छलफल

यदि तपाइँ छोटो रिपोर्ट दिन चाहानुहुन्छ भने, तपाइँ साँझको लाइटनिङ टकको लागि व्हाइटबोर्डमा साइन अप गर्न सक्नुहुन्छ र सम्मेलनको विषयमा कुनै पनि कुराको बारेमा कुरा गर्न पाँच मिनेट समय प्राप्त गर्न सक्नुहुन्छ। उदाहरणका लागि, C++ को लागि सेनिटाइजरहरूको द्रुत परिचय (केहीका लागि यो नयाँ थियो) वा साइन वेभ जेनरेशनमा बगको बारेमा कथा जुन सुन्न सकिन्छ, तर देख्न सकिँदैन।

अर्को ढाँचा प्यानल छलफल हो "हार्ट टु हार्ट कमिटीसँग।" स्टेजमा मानकीकरण समितिका केही सदस्यहरू छन्, प्रोजेक्टरमा फायरप्लेस छ (आधिकारिक रूपमा - एक निष्कपट वातावरण सिर्जना गर्न, तर कारण "किनकि सबै कुरा आगोमा छ" रमाईलो देखिन्छ), मानक र C++ को सामान्य दृष्टिकोणको बारेमा प्रश्नहरू। , तातो प्राविधिक छलफल र होलिवार बिना। यो बाहिरियो कि समितिमा जीवित व्यक्तिहरू पनि छन् जो पूर्ण रूपमा निश्चित हुन सक्दैनन् वा केहि थाहा नहुन सक्छ।

होलिभर्सका प्रशंसकहरूका लागि, तेस्रो घटना केसमा रह्यो - BOF सत्र "गो बनाम C++"। हामी एक गो प्रेमी, एक C++ प्रेमी लिन्छौं, सत्र सुरु हुनु अघि तिनीहरूले 100500 स्लाइडहरू तयार पार्छन् (जस्तै C++ मा प्याकेजहरूमा समस्या वा Go मा जेनेरिकको अभाव), र त्यसपछि तिनीहरूले आपसमा जीवन्त छलफल गर्छन् र। दर्शकहरूसँग, र दर्शकहरूले एकैचोटि दुईवटा दृष्टिकोण बुझ्न प्रयास गर्छन्। यदि होलिभर सन्दर्भ बाहिर सुरु हुन्छ भने, मध्यस्थकर्ताले हस्तक्षेप गर्दछ र पक्षहरूलाई मिलाउँछ। यो ढाँचा लत छ: सुरु भएको धेरै घण्टा पछि, स्लाइडको आधा मात्र पूरा भयो। अन्त धेरै छिटो हुनुपर्यो।

• साझेदार खडा छ

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

प्रतिवेदनको प्राविधिक विवरण

हामीले दुवै दिन रिपोर्टहरू सुन्यौं। कहिलेकाहीं समानान्तर रिपोर्टहरूबाट एउटा प्रतिवेदन छनोट गर्न गाह्रो हुन्थ्यो - हामी विभाजित गर्न र ब्रेकको समयमा प्राप्त ज्ञान आदानप्रदान गर्न सहमत भयौं। र तैपनि, यो धेरै छोडिएको देखिन्छ। यहाँ हामी केहि प्रतिवेदनहरु को बारे मा कुरा गर्न चाहन्छौं जुन हामीलाई सबैभन्दा रोचक लाग्यो

कम्पाइलर अप्टिमाइजेसनको प्रिज्म मार्फत C++ मा अपवादहरू, रोमन रुस्याएभ

बाट स्लाइड गर्नुहोस् प्रस्तुतिकरण

शीर्षकले सुझाव दिएझैं, रोमनले उदाहरणको रूपमा LLVM प्रयोग गरेर अपवादहरूसँग काम गर्ने कुरालाई हेरे। एकै समयमा, आफ्नो काममा क्ल्याङ्ग प्रयोग नगर्नेहरूका लागि, रिपोर्टले कोडलाई कसरी सम्भावित रूपमा अनुकूलित गर्न सकिन्छ भन्ने बारे केही विचार दिन सक्छ। यो यसकारण हो किनभने कम्पाइलरहरू र सम्बन्धित मानक पुस्तकालयहरूको विकासकर्ताहरू एकअर्कासँग कुराकानी गर्छन् र धेरै सफल समाधानहरू मिल्न सक्छन्।

त्यसोभए, अपवाद ह्यान्डल गर्न, तपाईंले धेरै चीजहरू गर्न आवश्यक छ: ह्यान्डलिंग कोड (यदि कुनै हो भने) वा हालको स्तरमा नि: शुल्क स्रोतहरू कल गर्नुहोस् र स्ट्याकलाई उच्च स्पिन गर्नुहोस्। यो सबैले यस तथ्यलाई निम्त्याउँछ कि कम्पाइलरले कलहरूको लागि थप निर्देशनहरू थप्छ जुन सम्भावित रूपमा अपवादहरू फाल्छ। त्यसकारण, यदि अपवाद वास्तवमा उठाइएको छैन भने, कार्यक्रमले अझै पनि अनावश्यक कार्यहरू गर्नेछ। कुनै न कुनै रूपमा ओभरहेड घटाउनको लागि, LLVM सँग अपवाद ह्यान्डलिंग कोड थप्न आवश्यक पर्दैन वा "अतिरिक्त" निर्देशनहरूको संख्या घटाउन सकिने अवस्थाहरू निर्धारण गर्नका लागि धेरै हेरिस्टिक्सहरू छन्।

स्पिकरले ती मध्ये एक दर्जनको बारेमा जाँच गर्दछ र दुबै अवस्थाहरू देखाउँदछ जहाँ उनीहरूले कार्यक्रम कार्यान्वयनको गति बढाउन मद्दत गर्दछ, र जहाँ यी विधिहरू लागू हुँदैनन्।

तसर्थ, रोमन रुस्याएभले विद्यार्थीहरूलाई अपवाद ह्यान्डलिङ भएको कोड सधैं शून्य ओभरहेडसँग कार्यान्वयन गर्न सकिँदैन भन्ने निष्कर्षमा पुग्छन् र निम्न सल्लाह दिन्छन्:

• पुस्तकालयहरू विकास गर्दा, यो सिद्धान्तमा अपवादहरू त्याग्न लायक छ;
• यदि अपवादहरू अझै आवश्यक छ भने, जब सम्भव भएसम्म यो सबै ठाउँमा noexcept (र const) परिमार्जनहरू थप्न लायक छ ताकि कम्पाइलरले सकेसम्म अनुकूलन गर्न सक्छ।

सामान्यतया, वक्ताले यो दृश्य पुष्टि गरे कि अपवादहरू न्यूनतममा प्रयोग गरिन्छ वा पूर्ण रूपमा परित्याग गरिन्छ।

रिपोर्ट स्लाइडहरू निम्न लिङ्कमा उपलब्ध छन्: ["LLVM कम्पाइलर अप्टिमाइजेसनको लेन्स मार्फत C++ अपवादहरू"]

जेनरेटरहरू, कोरुटिनहरू र अन्य मस्तिष्क-अनरोलिङ मिठास, आदि शवित

बाट स्लाइड गर्नुहोस् प्रस्तुतिकरण

C++20 मा आविष्कारहरूका लागि समर्पित यस सम्मेलनमा धेरै रिपोर्टहरू मध्ये एउटा यसको रंगीन प्रस्तुतिको लागि मात्र होइन, तर सङ्कलन प्रक्रिया तर्क (लूप, कलब्याकहरूको लागि) सँग विद्यमान समस्याहरूको स्पष्ट पहिचानको लागि पनि यादगार थियो।

Adi Shavit ले निम्नलाई हाइलाइट गर्दछ: हाल उपलब्ध विधिहरूले सम्पूर्ण सङ्कलनमा जान्छन् र केही आन्तरिक मध्यवर्ती अवस्थाहरूमा पहुँच प्रदान गर्दैनन् (वा तिनीहरू कलब्याकको मामलामा गर्छन्, तर ठूलो संख्यामा अप्रिय साइड इफेक्टहरू, जस्तै कलब्याक नरक)। । यस्तो देखिन्छ कि त्यहाँ पुनरावृत्तिहरू छन्, तर तिनीहरूसँग पनि सबै कुरा त्यति सहज छैन: त्यहाँ कुनै सामान्य प्रवेश र बाहिर निस्कने बिन्दुहरू छैनन् (सुरु → अन्त्य बनाम 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 फाइलमा सार्यौं: हामीलाई र्‍याप गरिएको एपीआई, साथै 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++ चालहरू"]

तपाईंको कोड DRY, Björn Fahller राख्नको लागि आधुनिक प्रविधिहरू

यस वार्तामा, Björn Fahller बारम्बार अवस्था जाँचको शैलीगत त्रुटि विरुद्ध लड्न विभिन्न तरिकाहरू देखाउँछन्:

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) मा स्वत: प्रयोग गरेर, दृष्टिकोणले केवल state_type तत्वहरूसँग मात्र होइन, तर गैर-प्रकार टेम्प्लेट प्यारामिटरहरूको रूपमा प्रयोग गर्न सकिने आदिम प्रकारहरूसँग पनि तुलना गर्न सामान्य बनाउँछ:

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);

यस उदाहरणमा, कटौती गाइडले कम्पाइलरलाई चाहिएको संरचना टेम्प्लेट प्यारामिटरहरू सुझाव दिन्छ, जसले कन्स्ट्रक्टर आर्गुमेन्टका प्रकारहरू जान्दछ। 

थप - थप रोचक। ब्योर्नले तुलनात्मक अपरेटरहरूका लागि == भन्दा बाहिर र त्यसपछि स्वेच्छाचारी अपरेसनहरूको लागि नतिजा कोड कसरी सामान्यीकरण गर्ने भनेर सिकाउँछ। बाटोमा, no_unique_address विशेषता (C++20) र lambda प्रकार्यहरूमा टेम्प्लेट प्यारामिटरहरू (C++20) जस्ता सुविधाहरू प्रयोगका उदाहरणहरू प्रयोग गरी व्याख्या गरिएको छ। (हो, अब lambda वाक्यविन्यास सम्झन अझ सजिलो छ - यी सबै प्रकारका कोष्ठकहरूको चार लगातार जोडीहरू हुन्।) कन्स्ट्रक्टर विवरणहरूको रूपमा प्रकार्यहरू प्रयोग गर्ने अन्तिम समाधानले वास्तवमै मेरो आत्मालाई तातो बनाउँछ, lambda को उत्कृष्ट परम्पराहरूमा अभिव्यक्ति टपल उल्लेख नगर्ने। क्याल्कुलस।

अन्त्यमा, यसलाई पालिश गर्न नबिर्सनुहोस्:

• याद गर्नुहोस् कि lambdas नि: शुल्क constexpr छन्; 
• सही फर्वार्डिङ थपौं र lambda क्लोजरमा प्यारामिटर प्याकको सम्बन्धमा यसको बदसूरत वाक्य रचना हेरौं;
• सशर्त noexcept को साथ अनुकूलनका लागि कम्पाइलरलाई थप अवसरहरू दिनुहोस्; 
• टेम्प्लेटहरूमा थप बुझ्न सकिने त्रुटि आउटपुटको ख्याल राखौं, lambdas को स्पष्ट फिर्ता मानहरूका लागि धन्यवाद। यसले कम्पाइलरलाई टेम्प्लेट प्रकार्य वास्तवमा कल गर्नु अघि थप जाँचहरू गर्न बाध्य पार्छ - टाइप जाँच चरणमा। 

विवरणहरूको लागि, कृपया व्याख्यान सामग्रीहरू हेर्नुहोस्: 

• रिपोर्ट स्लाइडहरू: [तपाईको कोड DRY राख्नको लागि आधुनिक प्रविधिहरू]
• Github मा स्रोत कोड
• लेखकको ब्लग लेख

हाम्रा छापहरू

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

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

पढ्नको लागि धन्यवाद, र हामी आशा गर्छौं कि हाम्रो घटनाहरूको पुन: वर्णन उपयोगी थियो!

स्रोत: www.habr.com