C++ Ռուսաստան. ինչպես դա տեղի ունեցավ

Եթե ​​պիեսի սկզբում ասում եք, որ պատից կախված է C++ ծածկագիրը, ապա մինչև վերջ այն անպայման կրակելու է ձեր ոտքին։

Բյարնե Ստրուստրուփ

Հոկտեմբերի 31-ից նոյեմբերի 1-ը Սանկտ Պետերբուրգում կայացավ C++ Russia Piter կոնֆերանսը՝ Ռուսաստանում ծրագրավորման լայնածավալ համաժողովներից մեկը, որը կազմակերպել էր JUG Ru Group-ը։ Հրավիրված բանախոսները ներառում են C++ ստանդարտների կոմիտեի անդամներ, CppCon խոսնակներ, Օ'Ռեյլիի գրքերի հեղինակներ և այնպիսի նախագծերի սպասարկողներ, ինչպիսիք են LLVM, libc++ և Boost: Համաժողովը ուղղված է փորձառու C++ ծրագրավորողներին, ովքեր ցանկանում են խորացնել իրենց փորձը և փորձի փոխանակում կատարել կենդանի հաղորդակցության մեջ: Ուսանողներին, ասպիրանտներին և բուհերի ուսուցիչներին տրամադրվում են շատ գեղեցիկ զեղչեր։

Համաժողովի մոսկովյան տարբերակը հասանելի կլինի արդեն հաջորդ տարվա ապրիլին, բայց մինչ այդ մեր ուսանողները ձեզ կպատմեն, թե ինչ հետաքրքիր բաներ են սովորել վերջին միջոցառման ժամանակ: 

Լուսանկարը՝ կոնֆերանսի ալբոմ

մեր մասին

Սանկտ Պետերբուրգի Ազգային Հետազոտական ​​Համալսարանի Տնտեսագիտության բարձրագույն դպրոցի երկու ուսանողներ աշխատել են այս պաշտոնի վրա.

• Լիզա Վասիլենկոն բակալավրիատի 4-րդ կուրսի ուսանող է, ով սովորում է Ծրագրավորման լեզուներ Կիրառական մաթեմատիկա և համակարգչային գիտություն ծրագրի շրջանակներում: Համալսարանում սովորելուս առաջին կուրսում ծանոթանալով C++ լեզվին, ես հետագայում դրա հետ աշխատելու փորձ ձեռք բերեցի ոլորտում պրակտիկա անցնելու միջոցով: Ընդհանուր առմամբ ծրագրավորման լեզուների և մասնավորապես ֆունկցիոնալ ծրագրավորման հանդեպ իմ կիրքը իր հետքն է թողել համաժողովի զեկույցների ընտրության վրա:
• Դանյա Սմիրնովը «Ծրագրավորում և տվյալների վերլուծություն» մագիստրատուրայի 1-ին կուրսի ուսանող է։ Դեռ դպրոցական տարիներին ես գրում էի օլիմպիադայի խնդիրները C++-ով, հետո ինչ-որ կերպ այնպես ստացվեց, որ լեզուն անընդհատ առաջացավ կրթական գործունեության մեջ և ի վերջո դարձավ հիմնական աշխատանքային լեզուն: Որոշեցի մասնակցել գիտաժողովին գիտելիքներս կատարելագործելու, ինչպես նաև նոր հնարավորություններին ծանոթանալու համար:

Տեղեկագրում ֆակուլտետի ղեկավարությունը հաճախ է կիսվում մեր մասնագիտության հետ կապված կրթական միջոցառումների մասին: Սեպտեմբերին մենք տեղեկություն տեսանք C++ Ռուսաստանի մասին և որոշեցինք գրանցվել որպես ունկնդիր։ Սա նման համաժողովների մասնակցելու մեր առաջին փորձն է։

Կոնֆերանսի կառուցվածքը

• Զեկույցներ

Երկու օրվա ընթացքում փորձագետները կարդացին 30 զեկույց, որոնք ընդգրկում էին բազմաթիվ թեժ թեմաներ. լեզվական առանձնահատկությունների հնարամիտ օգտագործումը կիրառական խնդիրների լուծման համար, լեզվի առաջիկա թարմացումները՝ կապված նոր ստանդարտի հետ, փոխզիջումներ C++ դիզայնում և դրանց հետևանքների հետ աշխատելիս նախազգուշական միջոցներ, օրինակներ։ նախագծի հետաքրքիր ճարտարապետության, ինչպես նաև լեզվական ենթակառուցվածքի որոշ մանրամասներ: Միաժամանակ տեղի է ունեցել երեք ներկայացում, առավել հաճախ՝ երկուսը ռուսերեն, մեկը՝ անգլերեն։

• Քննարկման գոտիներ

Ելույթից հետո բոլոր չտրված հարցերն ու անավարտ քննարկումները տեղափոխվեցին բանախոսների հետ շփման համար նախատեսված հատուկ տարածքներ՝ հագեցած մարկերային տախտակներով։ Լավ միջոց՝ ելույթների միջև ընդմիջումը հաճելի զրույցից հեռու պահելու համար:

• Կայծակի զրույցներ և ոչ պաշտոնական քննարկումներ

Եթե ​​ցանկանում եք կարճ զեկույց ներկայացնել, կարող եք գրանցվել երեկոյան Lightning Talk-ին գրատախտակի վրա և հինգ րոպե ժամանակ տրամադրել համաժողովի թեմայով որևէ բանի մասին խոսելու համար: Օրինակ, C++-ի համար ախտահանող միջոցների արագ ներածություն (ոմանց համար դա նոր էր) կամ պատմություն սինուսային ալիքի առաջացման սխալի մասին, որը կարելի է միայն լսել, բայց չտեսնել:

Մեկ այլ ձևաչափ է «Սրտից սիրտ հանձնաժողովի հետ» պանելային քննարկումը։ Բեմում ստանդարտացման հանձնաժողովի որոշ անդամներ են, պրոյեկտորի վրա՝ բուխարի (պաշտոնապես՝ անկեղծ մթնոլորտ ստեղծելու համար, բայց պատճառն ավելի ծիծաղելի է թվում «որովհետև «ԱՄԵՆ ԻՆՉ ԿՐԿԻ»), հարցեր ստանդարտի և C++-ի ընդհանուր տեսլականի վերաբերյալ։ , առանց բուռն տեխնիկական քննարկումների ու հոլիվարների։ Պարզվեց, որ կոմիտեում կան նաև կենդանի մարդիկ, ովքեր կարող են ինչ-որ բանում լիովին վստահ չլինել կամ չգիտեն։

Հոլիվարների երկրպագուների համար գործի վրա մնաց երրորդ իրադարձությունը՝ BOF նիստը «Գնալ ընդդեմ C++»-ի: Մենք վերցնում ենք Go-ի սիրահարին, C++-ի սիրահարին, մինչև նիստի մեկնարկը նրանք միասին պատրաստում են 100500 սլայդ մի թեմայի շուրջ (օրինակ՝ խնդիրներ C++-ում փաթեթների հետ կամ Go-ում ջեներիկի բացակայությունը), այնուհետև նրանք իրար մեջ աշխույժ քննարկում են անցկացնում և հանդիսատեսի հետ, և հանդիսատեսը փորձում է հասկանալ միանգամից երկու տեսակետ: Եթե ​​հոլիվարը սկսվում է կոնտեքստից դուրս, մոդերատորը միջամտում է և հաշտեցնում կողմերին: Այս ձևաչափը կախվածություն է առաջացնում. մեկնարկից մի քանի ժամ անց ավարտվեց սլայդների միայն կեսը: Վերջը պետք էր մեծապես արագացնել։

• Գործընկերը կանգնած է

Դահլիճներում ներկայացված էին համաժողովի գործընկերները. տրիբունաներում նրանք խոսեցին ընթացիկ նախագծերի մասին, առաջարկեցին պրակտիկա և զբաղվածություն, անցկացրին վիկտորինաներ և փոքր մրցույթներ, ինչպես նաև խաղարկեցին գեղեցիկ մրցանակներ: Ընդ որում, որոշ ընկերություններ նույնիսկ առաջարկել են անցնել հարցազրույցների նախնական փուլերը, ինչը կարող է օգտակար լինել նրանց համար, ովքեր եկել են ոչ միայն հաշվետվություններ լսելու։

Հաշվետվությունների տեխնիկական մանրամասները

Երկու օրն էլ հաշվետվություններ ենք լսել։ Երբեմն դժվար էր զուգահեռ զեկույցներից մեկ ընտրել. պայմանավորվեցինք բաժանվել և փոխանակել ընդմիջումների ժամանակ ստացած գիտելիքները: Եվ նույնիսկ այդ դեպքում, թվում է, թե շատ բան դուրս է մնացել։ Այստեղ մենք կցանկանայինք խոսել որոշ զեկույցների բովանդակության մասին, որոնք մեզ համար ամենահետաքրքիրն էին

Բացառություններ C++-ում կոմպիլյատորների օպտիմալացման պրիզմայով, Ռոման Ռուսյաև

Սահել-ից շնորհանդեսներ

Ինչպես հուշում է վերնագրից, Ռոմանը դիտարկեց բացառություններով աշխատելը, օգտագործելով LLVM-ն որպես օրինակ: Միևնույն ժամանակ, նրանց համար, ովքեր չեն օգտագործում Clang-ն իրենց աշխատանքում, զեկույցը դեռևս կարող է որոշակի պատկերացում տալ, թե ինչպես կարող է հնարավոր օպտիմալացնել կոդը: Դա այդպես է, քանի որ կոմպիլյատորների և համապատասխան ստանդարտ գրադարանների մշակողները շփվում են միմյանց հետ, և շատ հաջող լուծումներ կարող են համընկնել:

Այսպիսով, բացառություն լուծելու համար դուք պետք է շատ բան անեք. զանգահարեք բեռնաթափման կոդը (եթե այդպիսիք կան) կամ անվճար ռեսուրսներ ընթացիկ մակարդակում և պտտեք փաթեթը ավելի բարձր: Այս ամենը հանգեցնում է նրան, որ կոմպիլյատորը ավելացնում է լրացուցիչ հրահանգներ այն զանգերի համար, որոնք պոտենցիալ բացառություններ են նետում: Հետևաբար, եթե բացառությունն իրականում չբարձրացվի, ծրագիրը դեռևս կկատարի ավելորդ գործողություններ: Գումարները ինչ-որ կերպ նվազեցնելու համար LLVM-ն ունի մի քանի էվրիստիկա՝ որոշելու այն իրավիճակները, երբ բացառությունների մշակման կոդը կարիք չկա ավելացնելու կամ «լրացուցիչ» հրահանգների թիվը կարող է կրճատվել:

Բանախոսը ուսումնասիրում է դրանցից մոտ մեկ տասնյակը և ցույց է տալիս ինչպես իրավիճակները, որտեղ դրանք օգնում են արագացնել ծրագրի կատարումը, այնպես էլ այն իրավիճակները, որտեղ այդ մեթոդները կիրառելի չեն:

Այսպիսով, Ռոման Ռուսյաևը ուսանողներին տանում է այն եզրակացության, որ բացառությունների մշակում պարունակող ծածկագիրը չի կարող միշտ իրականացվել զրոյական գլխավճարով, և տալիս է հետևյալ խորհուրդը.

• գրադարաններ մշակելիս արժե սկզբունքորեն հրաժարվել բացառություններից.
• եթե դեռ բացառություններ են անհրաժեշտ, ապա հնարավորության դեպքում արժե ամենուր ավելացնել noexcept (և const) փոփոխիչներ, որպեսզի կոմպիլյատորը կարողանա հնարավորինս օպտիմալացնել:

Ընդհանուր առմամբ, բանախոսը հաստատեց այն տեսակետը, որ բացառությունները լավագույնս պետք է օգտագործվեն նվազագույնի կամ ընդհանրապես հրաժարվել:

Զեկույցի սլայդները հասանելի են հետևյալ հղումով. [«C++ բացառություններ LLVM կոմպիլյատորների օպտիմալացումների միջոցով»]

Գեներատորներ, կորուտիններ և ուղեղը բացող այլ քաղցրություն, Ադի Շավիթ

Սահել-ից շնորհանդեսներ

Այս կոնֆերանսի բազմաթիվ զեկույցներից մեկը, որը նվիրված էր C++20-ի նորարարություններին, հիշարժան էր ոչ միայն իր գունեղ ներկայացմամբ, այլև հավաքածուների մշակման տրամաբանության հետ կապված առկա խնդիրների հստակ բացահայտմամբ (հանգույց, հետադարձ զանգեր):

Ադի Շավիթը կարևորում է հետևյալը. ներկայումս առկա մեթոդներն անցնում են ամբողջ հավաքածուով և չեն ապահովում մուտք դեպի ինչ-որ ներքին միջանկյալ վիճակ (կամ անում են հետադարձ զանգերի դեպքում, բայց մեծ թվով տհաճ կողմնակի էֆեկտներով, օրինակ՝ Callback Hell) . Թվում է, թե կան կրկնողներ, բայց նույնիսկ նրանց մոտ ամեն ինչ այնքան էլ հարթ չէ. չկան ընդհանուր մուտքի և ելքի կետեր (սկիզբ → վերջ ընդդեմ rbegin → rend և այլն), պարզ չէ, թե որքան ժամանակ ենք կրկնելու: Սկսած C++20-ից՝ այս խնդիրները լուծված են։

Առաջին տարբերակը՝ միջակայքերը: Իտերատորները փաթաթելով՝ մենք ստանում ենք ընդհանուր ինտերֆեյս կրկնության սկզբի և վերջի համար, ինչպես նաև ստանում ենք շարադրելու հնարավորություն։ Այս ամենը հեշտացնում է տվյալների մշակման լիարժեք խողովակաշարերի կառուցումը: Բայց ամեն ինչ այնքան էլ հարթ չէ. հաշվարկային տրամաբանության մի մասը գտնվում է կոնկրետ կրկնող սարքի ներսում, որը կարող է բարդացնել կոդը հասկանալու և վրիպազերծելու համար:

Սահել-ից շնորհանդեսներ

Դե, այս դեպքում, C++20-ը ավելացրել է կոորուտիններ (գործառույթներ, որոնց վարքագիծը նման է Python-ի գեներատորներին). կատարումը կարող է հետաձգվել՝ վերադարձնելով որոշակի ընթացիկ արժեք՝ պահպանելով միջանկյալ վիճակը: Այսպիսով, մենք հասնում ենք ոչ միայն տվյալների հետ աշխատելու, ինչպես դրանք երևում են, այլև ամբողջ տրամաբանությունը ընդգրկում ենք կոնկրետ կորուտինայի ներսում:

Բայց քսուքի մեջ մի ճանճ կա. այս պահին դրանք միայն մասամբ են աջակցվում գոյություն ունեցող կոմպիլյատորների կողմից, ինչպես նաև չեն իրականացվում այնքան կոկիկ, որքան մենք կցանկանայինք. օրինակ, դեռ չարժե օգտագործել հղումներ և ժամանակավոր օբյեկտներ կորուտիններում: Բացի այդ, կան որոշ սահմանափակումներ այն մասին, թե ինչ կարող է լինել coroutines, և constexpr ֆունկցիաները, կոնստրուկտորները/դեստրուկտորները և հիմնականը ներառված չեն այս ցանկում:

Այսպիսով, կորուտինները խնդիրների զգալի մասը լուծում են տվյալների մշակման տրամաբանության պարզությամբ, սակայն դրանց ընթացիկ իրականացումը պահանջում է կատարելագործում:

Նյութեր `

• Սլայդներ C++ Ռուսաստանից - [«Գեներատորներ, կորուտիններ և ուղեղը բացող այլ քաղցրություն»]
• Զեկույցի տեսագրություն CppCon 2019-ից

C++ հնարքներ Yandex.Taxi-ից, Անտոն Պոլուխինից

Իմ մասնագիտական ​​գործունեության մեջ երբեմն ստիպված եմ լինում իրականացնել զուտ օժանդակ բաներ՝ փաթաթում ներքին ինտերֆեյսի և ինչ-որ գրադարանի API-ի միջև, գրանցում կամ վերլուծություն: Այս դեպքում սովորաբար լրացուցիչ օպտիմալացման կարիք չկա։ Բայց ի՞նչ, եթե այս բաղադրիչներն օգտագործվեն RuNet-ի ամենահայտնի ծառայություններում: Նման իրավիճակում դուք ստիպված կլինեք միայնակ մշակել տերաբայթներ մեկ ժամում գերանների համար: Այնուհետև յուրաքանչյուր միլիվայրկյան կարևոր է, և, հետևաբար, պետք է դիմել տարբեր հնարքների, - դրանց մասին խոսեց Անտոն Պոլուխինը:

Թերևս ամենահետաքրքիր օրինակը ցուցիչ-ի իրականացում (pimpl) օրինաչափության իրականացումն էր: 

#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_; 
};

Միակ խնդիրը. դուք պետք է նշեք չափը և հավասարեցումը յուրաքանչյուր փաթաթման համար. եկեք պատրաստենք մեր pimpl ձևանմուշը պարամետրերով , օգտագործեք որոշ կամայական արժեքներ և ստուգիչ ավելացրեք կործանիչին, որ մենք ամեն ինչ ճիշտ ենք ստացել. 

~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-ն արդեն սահմանված է դեստրուկտորը մշակելիս, այս կոդը ճիշտ կվերլուծվի, և կազմման փուլում այն ​​կթողարկի պահանջվող չափի և հավասարեցման արժեքները, որոնք պետք է մուտքագրվեն որպես սխալներ: Այսպիսով, մեկ հավելյալ կոմպիլյացիայի գործարկման գնով մենք ազատվում ենք փաթաթված դասերի դինամիկ տեղաբաշխումից, ներդրման հետ միասին թաքցնում ենք API-ն .cpp ֆայլում, ինչպես նաև ստանում ենք դիզայն, որն ավելի հարմար է պրոցեսորի կողմից քեշավորման համար:

Գրանցամատյանները և վերլուծությունը ավելի քիչ տպավորիչ էին թվում, և, հետևաբար, այս վերանայման մեջ չեն նշվի:

Զեկույցի սլայդները հասանելի են հետևյալ հղումով. [«C++ հնարքներ տաքսիից»]

Ձեր ծածկագիրը DRY պահելու ժամանակակից տեխնիկա, Բյորն Ֆահլեր

Այս ելույթում Բյորն Ֆահլերը ցույց է տալիս մի քանի տարբեր եղանակներ՝ պայքարելու վիճակի կրկնվող ստուգումների ոճական թերության դեմ.

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

Օգտագործելով auto ոչ տիպային կաղապարի պարամետրում (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-ները constexpr են անվճար; 
• Եկեք ավելացնենք կատարյալ վերահասցեավորում և դիտենք դրա տգեղ շարահյուսությունը՝ կապված լամբդա փակման պարամետրերի փաթեթի հետ.
• Եկեք կոմպիլյատորին ավելի շատ հնարավորություններ տանք օպտիմալացումների համար պայմանական noexcept; 
• Եկեք հոգ տանենք ձևանմուշներում ավելի հասկանալի սխալի ելքի մասին՝ lambdas-ի բացահայտ վերադարձի արժեքների շնորհիվ: Սա կստիպի կոմպիլյատորին ավելի շատ ստուգումներ կատարել նախքան ձևանմուշի ֆունկցիան իրականում կանչվելը՝ տիպի ստուգման փուլում: 

Մանրամասների համար խնդրում ենք ծանոթանալ դասախոսության նյութերին. 

• Հաղորդել սլայդները. [Ձեր կոդը չոր պահելու ժամանակակից տեխնիկա]
• Աղբյուրի կոդը github-ում
• Հեղինակի բլոգի հոդված

Մեր տպավորությունները

Մեր առաջին մասնակցությունը C++ Ռուսաստանին հիշարժան էր իր ինտենսիվությամբ: Ես ստացա C++ Ռուսաստանի տպավորությունը որպես անկեղծ իրադարձություն, որտեղ մարզումների և կենդանի շփման սահմանը գրեթե աննկատ է։ Ամեն ինչ՝ սկսած բանախոսների տրամադրությունից մինչև միջոցառման գործընկերների մրցույթները, նպաստում են բուռն քննարկումների: Համաժողովի բովանդակությունը, որը բաղկացած է զեկույցներից, ընդգրկում է թեմաների բավականին լայն շրջանակ, ներառյալ C++ նորարարությունները, խոշոր նախագծերի դեպքերի ուսումնասիրությունը և գաղափարական ճարտարապետական ​​նկատառումները: Բայց անարդար կլինի անտեսել միջոցառման սոցիալական բաղադրիչը, որն օգնում է հաղթահարել լեզվական խոչընդոտները ոչ միայն C++-ի հետ կապված:

Շնորհակալություն ենք հայտնում համաժողովի կազմակերպիչներին նման միջոցառմանը մասնակցելու հնարավորության համար։
Հնարավոր է՝ տեսած լինեք կազմակերպիչների գրառումը C++ Ռուսաստանի անցյալի, ներկայի և ապագայի մասին JUG Ru բլոգում.

Շնորհակալություն կարդալու համար և հուսով ենք, որ իրադարձությունների մեր վերապատմումն օգտակար էր:

Source: www.habr.com