سي ++ روس: اهو ڪيئن ٿيو

جيڪڏهن راند جي شروعات ۾ توهان چئو ٿا ته ڀت تي C++ ڪوڊ لٽڪيل آهي، ته پوءِ آخر تائين اهو توهان کي پيرن ۾ مارڻ جو پابند هوندو.

Bjarne Stroustrup

31 آڪٽوبر کان 1 نومبر تائين، سينٽ پيٽرسبرگ ۾ C++ روس پيٽر ڪانفرنس منعقد ڪئي وئي - روس ۾ وڏي پيماني تي پروگرامنگ ڪانفرنسن مان هڪ، JUG Ru گروپ پاران منظم. مهمان ڳالهائيندڙن ۾ C++ معيار ڪميٽي جا ميمبر، CppCon اسپيڪر، O'Reilly ڪتاب جا ليکڪ، ۽ پروجيڪٽ جا سنڀاليندڙ جهڙوڪ LLVM، libc++، ۽ Boost شامل آهن. ڪانفرنس جو مقصد آهي تجربيڪار C++ ڊولپرز جيڪي پنهنجي مهارت کي وڌيڪ مضبوط ڪرڻ ۽ لائيو ڪميونيڪيشن ۾ تجربا مٽائڻ چاهين ٿا. شاگرد، گريجوئيٽ شاگردن ۽ يونيورسٽي جي استادن کي تمام سٺي رعايتون ڏنيون وينديون آهن.

ڪانفرنس جو ماسڪو ايڊيشن ايندڙ سال اپريل جي شروعات ۾ گهمڻ لاءِ دستياب هوندو، پر ان دوران اسان جا شاگرد توهان کي ٻڌائيندا ته گذريل تقريب ۾ هنن ڪهڙيون دلچسپ شيون سکيون. 

فوٽو تان ڪانفرنس البم

اسان جي باري ۾

نيشنل ريسرچ يونيورسٽي هائر اسڪول آف اڪنامڪس - سينٽ پيٽرسبرگ مان ٻن شاگردن هن پوسٽ تي ڪم ڪيو:

• Liza Vasilenko 4th سال جي انڊر گريجوئيٽ شاگردياڻي آهي جيڪا اپلائيڊ ميٿميٽڪس ۽ ڪمپيوٽر سائنس پروگرام جي حصي طور پروگرامنگ ٻوليون پڙهندي آهي. يونيورسٽي ۾ منهنجي پهرين سال ۾ C++ ٻوليءَ سان واقفيت ٿيڻ بعد، مون ان کان پوءِ صنعت ۾ انٽرنشپ ذريعي ڪم ڪرڻ جو تجربو حاصل ڪيو. عام طور تي پروگرامنگ ٻولين جو شوق ۽ خاص طور تي فنڪشنل پروگرامنگ ڪانفرنس ۾ رپورٽن جي چونڊ تي پنهنجو نشان ڇڏي ويو.
• دنيا سمرنوف ماسٽر پروگرام جي پهرين سال جي شاگرد آهي “پروگرامنگ ۽ ڊيٽا تجزيي”. جڏهن اڃا اسڪول ۾ هو، مون اولمپياڊ جا مسئلا C++ ۾ لکيا، ۽ پوءِ ڪنهن نه ڪنهن طرح اهو ٿيو ته ٻولي مسلسل تعليمي سرگرمين ۾ اچي وئي ۽ آخرڪار مکيه ڪم ڪندڙ ٻولي بڻجي وئي. مون ڪانفرنس ۾ حصو وٺڻ جو فيصلو ڪيو ته جيئن منهنجي ڄاڻ کي بهتر بڻائي سگهجي ۽ نئين موقعن بابت پڻ سکڻ.

نيوز ليٽر ۾، فيڪلٽي قيادت اڪثر ڪري اسان جي خاصيت سان لاڳاپيل تعليمي واقعن بابت معلومات حصيداري ڪري ٿي. سيپٽمبر ۾ اسان C++ روس بابت معلومات ڏٺي ۽ ٻڌندڙن جي طور تي رجسٽر ٿيڻ جو فيصلو ڪيو. اهڙين ڪانفرنسن ۾ شرڪت جو هي اسان جو پهريون تجربو آهي.

ڪانفرنس جي جوڙجڪ

• رپورٽون

ٻن ڏينهن جي دوران، ماهر 30 رپورٽون پڙهيا، جن ۾ ڪيترن ئي گرم موضوعن کي شامل ڪيو ويو آهي: لاڳو ٿيل مسئلن کي حل ڪرڻ لاءِ ٻوليءَ جي خاصيتن جا ذهين استعمال، نئين معيار جي حوالي سان ايندڙ ٻولي جون تازه ڪاريون، C++ ڊيزائن ۾ سمجهوتو ۽ انهن جي نتيجن سان ڪم ڪرڻ دوران احتياطي تدبيرون، مثال. دلچسپ پروجيڪٽ آرڪيٽيڪچر جو، انهي سان گڏ ٻوليءَ جي بنيادي ڍانچي جا ڪجهه هيٺيون تفصيل. ٽي پرفارمنس هڪ ئي وقت ۾ ٿي ويا، اڪثر ڪري ٻه روسي ۽ هڪ انگريزي ۾.

• بحث جا علائقا

تقرير کان پوء، سڀئي اڻ پڇيل سوال ۽ اڻڄاتل بحث مباحثن سان رابطي لاء خاص طور تي نامزد ٿيل علائقن ڏانهن منتقل ڪيا ويا، مارڪر بورڊ سان ليس. خوشگوار گفتگو سان تقريرن ​​جي وچ ۾ وقفي کي دور ڪرڻ جو سٺو طريقو.

• روشني واريون ڳالهيون ۽ غير رسمي بحث

جيڪڏھن توھان ھڪ مختصر رپورٽ ڏيڻ چاھيو ٿا، توھان سائن اپ ڪري سگھو ٿا وائيٽ بورڊ تي شام جي روشنيءَ واري گفتگو لاءِ ۽ پنجن منٽن جو وقت حاصل ڪريو ڪانفرنس جي موضوع تي ڪنھن به شيءِ بابت ڳالهائڻ لاءِ. مثال طور، C++ لاءِ صاف ڪرڻ وارن جو تڪڙو تعارف (ڪجهه لاءِ اهو نئون هو) يا هڪ ڪهاڻي سائين ويو نسل ۾ بگ بابت جيڪا صرف ٻڌي سگهجي ٿي پر نه ڏٺي وڃي.

ٻيو فارميٽ پينل بحث آهي "دل کان دل جي ڪميٽي سان." اسٽيج تي معيار سازي ڪميٽي جا ڪجهه ميمبر آهن، پروجيڪٽر تي هڪ چمني آهي (سرڪاري طور تي - هڪ مخلص ماحول پيدا ڪرڻ لاء، پر سبب "ڇاڪاڻ ته سڀ ڪجهه باهه تي آهي" مزيدار لڳي ٿو)، معيار بابت سوال ۽ C++ جي عام ويزن بابت. ، بغير گرم ٽيڪنيڪل بحثن ۽ هوليوارن جي. معلوم ٿيو ته ڪميٽيءَ ۾ زندهه ماڻهو به شامل آهن، جن کي شايد ڪنهن شيءِ بابت مڪمل يقين نه آهي يا شايد ڪجهه نه ڄاڻن.

هوليورز جي مداحن لاءِ، ٽيون واقعو ڪيس تي رهيو - BOF سيشن “Go vs. C++”. اسان هڪ Go عاشق، هڪ C++ عاشق کي وٺي وڃون ٿا، سيشن جي شروعات کان اڳ اهي گڏجي هڪ موضوع تي 100500 سلائيڊ تيار ڪن ٿا (جهڙوڪ C++ ۾ پيڪيجز جا مسئلا يا Go ۾ جنريڪس جي کوٽ)، ۽ پوءِ اهي پاڻ ۾ سرسبز بحث مباحثا ڪن ٿا ۽ سامعين سان، ۽ سامعين هڪ ئي وقت ۾ ٻه نقطا سمجهڻ جي ڪوشش ڪندو آهي. جيڪڏهن هوليور جي حوالي سان شروع ٿئي ٿي، منتظم مداخلت ڪري ٿو ۽ پارٽين کي ٺهرايو. هي فارميٽ لت آهي: شروع ٿيڻ کان ڪيترائي ڪلاڪ، صرف اڌ سلائڊ مڪمل ڪيا ويا. پڄاڻي کي تمام گهڻو تيز ڪرڻو پيو.

• ساٿي بيٺو

ڪانفرنس جي ڀائيوارن جي نمائندگي هالن ۾ ڪئي وئي - اسٽينڊن تي انهن موجوده منصوبن بابت ڳالهايو، انٽرن شپ ۽ روزگار جي آڇ ڪئي، کوئزز ۽ ننڍا مقابلا منعقد ڪيا ويا، ۽ پڻ سٺا انعام پڻ ڏنا ويا. ساڳئي وقت، ڪجهه ڪمپنين ته انٽرويو جي شروعاتي مرحلن مان گذرڻ جي آڇ ڪئي، جيڪي انهن لاء ڪارائتو ٿي سگهن ٿيون جيڪي نه رڳو رپورٽون ٻڌڻ لاء آيا هئا.

رپورٽن جي ٽيڪنيڪل تفصيل

اسان ٻئي ڏينهن رپورٽون ٻڌيون. ڪڏهن ڪڏهن متوازي رپورٽن مان هڪ رپورٽ چونڊڻ ڏکيو هو - اسان وقفي دوران حاصل ڪيل ڄاڻ کي ورهائڻ ۽ مٽائڻ تي اتفاق ڪيو. ۽ ان جي باوجود، اهو لڳي ٿو ته گهڻو ڪجهه ڇڏي ويو آهي. هتي اسان ڪجهه رپورٽن جي مواد جي باري ۾ ڳالهائڻ چاهيون ٿا جيڪي اسان کي تمام گهڻي دلچسپ لڳي

C++ ۾ استثنيٰ prism of compiler optimizations جي ذريعي، رومن Rusyaev

کان سلائڊ презентации

جيئن ته عنوان مشورو ڏئي ٿو، رومن مثال طور LLVM استعمال ڪندي استثنا سان ڪم ڪندي ڏٺو. ساڳئي وقت، انهن لاء جيڪي ڪلنگ استعمال نٿا ڪن انهن جي ڪم ۾، رپورٽ اڃا تائين ڪجهه خيال ڏئي سگهي ٿي ته ڪوڊ ڪيئن ممڪن طور تي بهتر ٿي سگهي ٿو. اهو ئي سبب آهي ڇو ته ڊولپرز جا مرتب ڪندڙ ۽ لاڳاپيل معياري لائبريريون هڪ ٻئي سان رابطو ڪن ٿا ۽ ڪيترائي ڪامياب حل ٺهي سگهن ٿا.

تنهن ڪري، هڪ استثنا کي سنڀالڻ لاء، توهان کي تمام گهڻيون شيون ڪرڻ جي ضرورت آهي: هينڊلنگ ڪوڊ (جيڪڏهن ڪو به هجي) يا موجوده سطح تي مفت وسيلن کي ڪال ڪريو ۽ اسٽيڪ کي بلند ڪريو. هي سڀ حقيقت ڏانهن وڌي ٿو ته مرتب ڪندڙ ڪالن لاءِ اضافي هدايتون شامل ڪري ٿو جيڪي امڪاني طور تي استثنا ڏين ٿا. تنهن ڪري، جيڪڏهن استثنا اصل ۾ نه وڌايو ويو آهي، پروگرام اڃا تائين غير ضروري ڪارناما انجام ڏيندو. ڪنهن حد تائين اوور هيڊ کي گھٽائڻ لاءِ، LLVM وٽ حالتون طئي ڪرڻ لاءِ ڪيترائي ھيرسٽڪس آھن جتي استثنا ھينڊلنگ ڪوڊ شامل ڪرڻ جي ضرورت نه آھي يا ”اضافي“ ھدايتن جو تعداد گھٽائي سگھجي ٿو.

اسپيڪر انهن مان هڪ درجن جي باري ۾ جانچ ڪري ٿو ۽ ٻنهي حالتن کي ڏيکاري ٿو جتي اهي پروگرام جي عمل کي تيز ڪرڻ ۾ مدد ڪن ٿا، ۽ اهي جتي اهي طريقا لاڳو نه آهن.

اهڙيءَ طرح، رومن روسياوف شاگردن کي ان نتيجي تي پهچندو آهي ته ڪوڊ جنهن ۾ استثنيٰ سنڀالي هجي، هميشه صفر اوور هيڊ سان عمل ۾ نه اچي سگهي، ۽ هيٺيون صلاحون ڏئي ٿو:

• جڏهن لائبريرين کي ترقي ڪندي، اهو اصول ۾ استثناء کي ڇڏي ڏيڻ جي قابل آهي؛
• جيڪڏهن استثنا اڃا به گهربل آهي، پوء جڏهن به ممڪن هجي ته هر جڳهه شامل ڪرڻ جي قابل آهي noexcept (۽ const) موڊيفائرز ته جيئن گڏ ڪرڻ وارو ممڪن حد تائين بهتر ڪري سگهي.

عام طور تي، اسپيڪر ان خيال جي تصديق ڪئي ته استثنا بهترين طور تي گهٽ ۾ گهٽ استعمال ڪيا ويا آهن يا مڪمل طور تي ڇڏيل آهن.

رپورٽ جي سلائيڊ هيٺ ڏنل لنڪ تي موجود آهن: ["سي ++ استثنا LLVM مرتب ڪندڙ اصلاحن جي لينس ذريعي"]

جنريٽر، ڪوروٽين ۽ ٻين دماغ کي ختم ڪرڻ واري مٺي، ادي شيوٽ

کان سلائڊ презентации

C++20 ۾ جدت لاءِ وقف ڪيل هن ڪانفرنس جي ڪيترن ئي رپورٽن مان هڪ نه رڳو ان جي رنگين پيشڪش لاءِ يادگار هئي، پر ان جي ڪليڪشن پروسيسنگ منطق (لوپ، ڪال بڪ لاءِ) سان موجود موجوده مسئلن جي واضح سڃاڻپ لاءِ پڻ.

Adi Shavit هيٺ ڏنل نمايان ڪري ٿو: في الحال دستياب طريقا سڄي مجموعي مان گذريا آهن ۽ ڪجهه اندروني وچ واري حالت تائين رسائي فراهم نٿا ڪن (يا اهي ڪال بيڪ جي صورت ۾ ڪندا آهن، پر وڏي تعداد ۾ ناپسنديده ضمني اثرات، جهڙوڪ ڪال بيڪ دوزخ) . اهو لڳي ٿو ته اتي ٻيهر ورجائيندڙ آهن، پر انهن سان گڏ هر شيء ايترو آسان ناهي: اتي عام داخلا ۽ نڪرڻ واري پوائنٽون نه آهن (شروع → آخر بمقابله rbegin → رينڊ وغيره)، اهو واضح ناهي ته اسان ڪيتري وقت تائين ٻيهر ڪنداسين؟ C++ 20 سان شروع ڪندي، اهي مسئلا حل ٿي ويا آهن!

پهريون اختيار: حدون. Iterators کي لفافي ڪرڻ سان، اسان کي هڪ عام انٽرفيس حاصل ڪريون ٿا شروعات ۽ پڇاڙيءَ لاءِ، ۽ اسان کي ڪمپوز ڪرڻ جي صلاحيت پڻ ملي ٿي. هي سڀ مڪمل ڊيٽا پروسيسنگ پائپ لائنز ٺاهڻ ۾ آسان بڻائي ٿو. پر هر شيء ايترو آسان ناهي: حساب جي منطق جو حصو هڪ مخصوص آئٽرٽر جي عمل جي اندر واقع آهي، جيڪو ڪوڊ کي سمجهڻ ۽ ڊيبگ ڪرڻ لاء پيچيده ڪري سگهي ٿو.

کان سلائڊ презентации

خير، هن معاملي لاءِ، C++ 20 شامل ڪيو ڪوروٽين (فعل جن جو رويو پائٿون ۾ جنريٽر وانگر آهي): عمل کي ملتوي ڪري سگهجي ٿو ڪجهه موجوده قيمت واپس ڪندي جڏهن وچ واري حالت کي محفوظ ڪندي. ان ڪري، اسان حاصل ڪريون ٿا نه صرف ڊيٽا سان ڪم ڪرڻ سان جيئن ظاهر ٿئي ٿو، پر هڪ مخصوص ڪوروٽين جي اندر سڀني منطق کي پڻ شامل ڪري ٿو.

پر عطر ۾ هڪ مکڻ آهي: هن وقت اهي صرف جزوي طور تي موجود ڪمپيلرز جي حمايت ڪري رهيا آهن، ۽ پڻ لاڳو نه ڪيا ويا آهن صاف طور تي جيئن اسان چاهيون ٿا: مثال طور، اهو اڃا تائين قابل ناهي ته حوالن ۽ عارضي شين کي ڪوروٽين ۾ استعمال ڪندي. ان سان گڏ، اتي ڪي پابنديون آھن جيڪي ٿي سگھن ٿيون ڪوروٽين، ۽ constexpr افعال، ٺاھيندڙ / تباھ ڪندڙ، ۽ مکيه ھن لسٽ ۾ شامل نه آھن.

اهڙيء طرح، ڪوروٽين ڊيٽا پروسيسنگ منطق جي سادگي سان مسئلن جو هڪ اهم حصو حل ڪن ٿا، پر انهن جي موجوده عملن کي سڌارڻ جي ضرورت آهي.

مواد

• سلائيڊس کان C++ روس - ["جنريٽر، ڪوروٽين ۽ ٻيون دماغ کي ختم ڪرڻ واري مٺي"]
• CppCon 2019 کان رپورٽ جي وڊيو رڪارڊنگ

Yandex.Taxi، Anton Polukhin کان C++ چالون

منهنجي پيشه ورانه سرگرمين ۾، ڪڏهن ڪڏهن مون کي مڪمل طور تي مددگار شين تي عمل ڪرڻو پوندو آهي: اندروني انٽرفيس ۽ ڪجهه لائبريري جي API جي وچ ۾ هڪ لفافي، لاگنگ يا پارسنگ. انهي حالت ۾، عام طور تي ڪنهن به اضافي اصلاح جي ضرورت ناهي. پر ڇا جيڪڏهن اهي جزا RuNet تي ڪجهه مشهور خدمتن ۾ استعمال ڪيا وڃن؟ اهڙي صورتحال ۾، توهان کي صرف لاگ ان جي في ڪلاڪ ٽيرا بائيٽ پروسيس ڪرڻو پوندو! پوءِ هر مليسيڪنڊ ڳڻپ ڪندو آهي ۽ تنهن ڪري توهان کي مختلف چالن جو سهارو وٺڻو پوندو - Anton Polukhin انهن بابت ڳالهايو.

شايد سڀ کان وڌيڪ دلچسپ مثال پوائنٽر-کي-عمل درآمد (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 جي اڳ ۾ ئي وضاحت ڪئي وئي آهي جڏهن ڊسٽرڪٽر کي پروسيس ڪيو وڃي، اهو ڪوڊ صحيح طريقي سان پارس ڪيو ويندو ۽ تاليف جي اسٽيج تي اهو گهربل سائيز ۽ ترتيب جي قيمتن کي ڪڍي ڇڏيندو جيڪي غلطي جي طور تي داخل ٿيڻ جي ضرورت آهي. اهڙيء طرح، هڪ اضافي تاليف هلائڻ جي قيمت تي، اسان لپيل طبقن جي متحرڪ مختص ڪرڻ کان نجات حاصل ڪريون ٿا، عمل سان گڏ هڪ .cpp فائل ۾ API کي لڪايو، ۽ پڻ هڪ ڊزائن حاصل ڪريو جيڪو پروسيسر طرفان ڪيش ڪرڻ لاء وڌيڪ مناسب آهي.

لاگنگ ۽ پارسنگ گهٽ متاثر کن لڳي ٿي ۽ تنهن ڪري هن جائزي ۾ ذڪر نه ڪيو ويندو.

رپورٽ جي سلائيڊ هيٺ ڏنل لنڪ تي موجود آهن: ["ٽيڪسي مان سي ++ چالون"]

توهان جي ڪوڊ 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)); 

غير قسم جي ٽيمپليٽ پيٽرولر صورتحال کي ٿورو بهتر ڪرڻ ۾ مدد ڪندي. انهن جي مدد سان، اسان اينيم جي ڳڻپيوڪر عناصر کي ٽيمپليٽ پيٽرولر جي لسٽ ۾ منتقل ڪنداسين: 

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

هن مثال ۾، ڊيڊڪشن گائيڊ ڪمپليٽر کي گهربل ڍانچي ٽيمپليٽ پيٽرولر جو مشورو ڏئي ٿو، جيڪو تعمير ڪندڙ دليلن جي قسمن کي ڄاڻي ٿو. 

وڌيڪ - وڌيڪ دلچسپ. Bjorn سيکاري ٿو ته نتيجن واري ڪوڊ کي ڪيئن عام ڪجي مقابلي جي آپريٽرن لاءِ == کان ٻاهر، ۽ پوءِ پاڻمرادو عملن لاءِ. رستي ۾، اهڙيون خاصيتون جهڙوڪ no_unique_address attribute (C++20) ۽ ٽيمپليٽ پيرا ميٽرز ۾ lambda افعال (C++20) استعمال جا مثال استعمال ڪندي وضاحت ڪئي وئي آهي. (ها، هاڻي ليمبڊا نحو ياد رکڻ اڃا به آسان آهي - اهي هر قسم جي قوس جا چار لڳاتار جوڙا آهن.) حتمي حل فنڪشن کي استعمال ڪندي ڪنسٽرڪٽر تفصيل واقعي منهنجي روح کي گرمائي ٿو، ليمبڊا جي بهترين روايتن ۾ ٽوپل جي اظهار جو ذڪر نه ڪرڻ. حساب ڪتاب

آخر ۾، ان کي پالش ڪرڻ نه وساريو:

• ياد رهي ته lambdas مفت ۾ constexpr آهن؛ 
• اچو ته مڪمل فارورڊنگ شامل ڪريون ۽ ان جي بدصورت نحو کي ڏسو ليمبڊا بندش ۾ پيراميٽر پيڪ جي حوالي سان؛
• اچو ته مرتب ڪندڙ کي بهتر ڪرڻ جا وڌيڪ موقعا ڏيون مشروط noexcept سان؛ 
• اچو ته ٽيمپليٽس ۾ وڌيڪ سمجھڻ واري نقص آئوٽ جو خيال رکون ليمبڊاس جي واضح موٽڻ واري قدر جي مهرباني. هي ٽيمپليٽ فنڪشن کي اصل ۾ سڏڻ کان اڳ وڌيڪ چيڪ ڪرڻ لاءِ مرتب ڪندڙ کي مجبور ڪندو - ٽائپ چيڪنگ اسٽيج تي. 

تفصيل لاءِ مهرباني ڪري ليڪچر مواد جو حوالو ڏيو: 

• رپورٽ سلائيڊ: [توهان جو ڪوڊ DRY رکڻ لاءِ جديد ٽيڪنالاجيون]
• گٿب تي ماخذ ڪوڊ
• ليکڪ جو بلاگ آرٽيڪل

اسان جا تاثرات

C++ روس ۾ اسان جي پهرين شرڪت ان جي شدت لاءِ يادگار هئي. مون کي C++ روس جو هڪ مخلص واقعي جو تاثر مليو، جتي ٽريننگ ۽ لائيو ڪميونيڪيشن جي وچ ۾ لڪير لڳ ڀڳ ناقابل تصور آهي. هر شيءِ، ڳالهائيندڙن جي مزاج کان وٺي ايونٽ جي ڀائيوارن کان مقابلن تائين، گرم بحثن لاءِ سازگار آهي. ڪانفرنس جو مواد، رپورٽن تي مشتمل آهي، موضوعن جي ڪافي وسيع رينج تي مشتمل آهي، جنهن ۾ C++ جدت، وڏي منصوبن جي ڪيس جي مطالعي ۽ نظرياتي تعميراتي خيالات شامل آهن. پر ان واقعي جي سماجي جز کي نظر انداز ڪرڻ ناانصافي ٿيندي، جيڪا نه صرف C++ جي حوالي سان ٻوليءَ جي رڪاوٽن کي دور ڪرڻ ۾ مدد ڪري ٿي.

اسان اهڙي تقريب ۾ شرڪت جو موقعو ڏيڻ لاءِ ڪانفرنس جي منتظمين جا ٿورائتا آهيون!
توھان ڏٺو ھوندو آرگنائيزر جي پوسٽ ماضي، حال ۽ مستقبل بابت C++ روس JUG Ru بلاگ تي.

پڙهڻ لاءِ مهرباني، ۽ اسان کي اميد آهي ته اسان جي واقعن کي ٻيهر ٻڌائڻ مددگار هو!

جو ذريعو: www.habr.com