சி++ ரஷ்யா: அது எப்படி நடந்தது

நாடகத்தின் தொடக்கத்தில் சுவரில் C++ குறியீடு தொங்கிக்கொண்டிருப்பதாகச் சொன்னால், இறுதியில் அது உங்கள் காலில் சுடும்.

Bjarne Stroustrup

அக்டோபர் 31 முதல் நவம்பர் 1 வரை, C++ ரஷ்யா Piter மாநாடு செயின்ட் பீட்டர்ஸ்பர்க்கில் நடைபெற்றது - ரஷ்யாவில் பெரிய அளவிலான நிரலாக்க மாநாடுகளில் ஒன்று, JUG Ru குழுவால் ஏற்பாடு செய்யப்பட்டது. விருந்தினர் பேச்சாளர்களில் C++ தரநிலைக் குழு உறுப்பினர்கள், CppCon ஸ்பீக்கர்கள், O'Reilly புத்தக ஆசிரியர்கள் மற்றும் LLVM, libc++ மற்றும் Boost போன்ற திட்டங்களைப் பராமரிப்பவர்கள் உள்ளனர். இந்த மாநாடு அனுபவம் வாய்ந்த சி++ டெவலப்பர்களை இலக்காகக் கொண்டது, அவர்கள் தங்கள் நிபுணத்துவத்தை ஆழப்படுத்தவும், நேரடி தகவல்தொடர்பு அனுபவங்களை பரிமாறிக்கொள்ளவும் விரும்புகிறார்கள். மாணவர்கள், பட்டதாரி மாணவர்கள் மற்றும் பல்கலைக்கழக ஆசிரியர்களுக்கு நல்ல தள்ளுபடிகள் வழங்கப்படுகின்றன.

மாநாட்டின் மாஸ்கோ பதிப்பு அடுத்த ஆண்டு ஏப்ரல் மாத தொடக்கத்தில் பார்வையிடக் கிடைக்கும், ஆனால் இதற்கிடையில் எங்கள் மாணவர்கள் கடந்த நிகழ்வில் என்ன சுவாரஸ்யமான விஷயங்களைக் கற்றுக்கொண்டார்கள் என்பதை உங்களுக்குச் சொல்வார்கள். 

புகைப்படம் மாநாட்டு ஆல்பம்

எங்களுக்கு பற்றி

நேஷனல் ரிசர்ச் யுனிவர்சிட்டி ஹையர் ஸ்கூல் ஆஃப் எகனாமிக்ஸ் - செயின்ட் பீட்டர்ஸ்பர்க்கில் இருந்து இரண்டு மாணவர்கள் இந்த பதவியில் பணிபுரிந்தனர்:

• Liza Vasilenko, பயன்பாட்டு கணிதம் மற்றும் கணினி அறிவியல் திட்டத்தின் ஒரு பகுதியாக நிரலாக்க மொழிகளைப் படிக்கும் 4 ஆம் ஆண்டு இளங்கலை மாணவி. பல்கலைக்கழகத்தில் எனது முதல் ஆண்டில் C++ மொழியுடன் பழகியதால், தொழில்துறையில் பயிற்சி மூலம் அதனுடன் பணிபுரிந்த அனுபவத்தைப் பெற்றேன். பொதுவாக நிரலாக்க மொழிகள் மற்றும் குறிப்பாக செயல்பாட்டு நிரலாக்கத்திற்கான ஆர்வம் மாநாட்டில் அறிக்கைகளைத் தேர்ந்தெடுப்பதில் அதன் அடையாளத்தை விட்டுச் சென்றது.
• டான்யா ஸ்மிர்னோவ் முதுநிலை திட்டமான "புரோகிராமிங் மற்றும் தரவு பகுப்பாய்வு" இன் 1 ஆம் ஆண்டு மாணவர். பள்ளியில் இருந்தபோது, ​​நான் ஒலிம்பியாட் பிரச்சனைகளை C++ இல் எழுதினேன், பின்னர் எப்படியாவது அந்த மொழி கல்வி நடவடிக்கைகளில் தொடர்ந்து வந்து இறுதியில் முக்கிய வேலை மொழியாக மாறியது. எனது அறிவை மேம்படுத்தவும், புதிய வாய்ப்புகளைப் பற்றி அறிந்து கொள்ளவும் மாநாட்டில் பங்கேற்க முடிவு செய்தேன்.

செய்திமடலில், ஆசிரியத் தலைமை அடிக்கடி எங்கள் சிறப்புடன் தொடர்புடைய கல்வி நிகழ்வுகள் பற்றிய தகவல்களைப் பகிர்ந்து கொள்கிறது. செப்டம்பரில், C++ ரஷ்யா பற்றிய தகவலைப் பார்த்தோம், மேலும் கேட்பவர்களாக பதிவு செய்ய முடிவு செய்தோம். இதுபோன்ற மாநாடுகளில் பங்கேற்பது இதுவே முதல் அனுபவம்.

மாநாட்டு அமைப்பு

• அறிக்கைகள்

இரண்டு நாட்களில், வல்லுநர்கள் 30 அறிக்கைகளைப் படித்தனர், பல சூடான தலைப்புகளை உள்ளடக்கியது: பயன்பாட்டு சிக்கல்களைத் தீர்க்க மொழி அம்சங்களின் தனித்துவமான பயன்பாடுகள், புதிய தரநிலையுடன் தொடர்புடைய வரவிருக்கும் மொழி புதுப்பிப்புகள், C++ வடிவமைப்பில் சமரசம் மற்றும் அவற்றின் விளைவுகளுடன் பணிபுரியும் போது முன்னெச்சரிக்கைகள், எடுத்துக்காட்டுகள். சுவாரசியமான திட்டக் கட்டமைப்பு, அத்துடன் மொழி உள்கட்டமைப்பின் சில அண்டர்-தி-ஹூட் விவரங்கள். மூன்று நிகழ்ச்சிகள் ஒரே நேரத்தில் நடந்தன, பெரும்பாலும் இரண்டு ரஷ்ய மொழியிலும் ஒன்று ஆங்கிலத்திலும்.

• கலந்துரையாடல் மண்டலங்கள்

உரைக்குப் பிறகு, அனைத்து கேட்கப்படாத கேள்விகள் மற்றும் முடிக்கப்படாத விவாதங்கள் பேச்சாளர்களுடன் தொடர்புகொள்வதற்காக குறிப்பான் பலகைகளுடன் சிறப்பாக நியமிக்கப்பட்ட பகுதிகளுக்கு மாற்றப்பட்டன. ஒரு இனிமையான உரையாடலுடன் பேச்சுக்களுக்கு இடையே இடைவேளையின் போது ஒரு நல்ல வழி.

• மின்னல் பேச்சுகள் மற்றும் முறைசாரா விவாதங்கள்

நீங்கள் ஒரு சிறிய அறிக்கையை வழங்க விரும்பினால், மாலை மின்னல் பேச்சுக்கு வெள்ளைப் பலகையில் பதிவு செய்து, மாநாட்டின் தலைப்பில் எதையும் பேச ஐந்து நிமிட நேரத்தைப் பெறலாம். எடுத்துக்காட்டாக, C++ க்கான சானிடைசர்கள் பற்றிய விரைவான அறிமுகம் (சிலருக்கு இது புதியது) அல்லது சைன் அலை உருவாக்கத்தில் உள்ள பிழையைப் பற்றிய கதை, அதைக் கேட்க மட்டுமே முடியும், ஆனால் பார்க்க முடியாது.

மற்றொரு வடிவம், குழு விவாதம் "இதயத்திற்கு இதயக் குழுவுடன்." மேடையில் தரப்படுத்தல் குழுவின் சில உறுப்பினர்கள் உள்ளனர், ப்ரொஜெக்டரில் ஒரு நெருப்பிடம் உள்ளது (அதிகாரப்பூர்வமாக - ஒரு நேர்மையான சூழ்நிலையை உருவாக்க, ஆனால் காரணம் "எல்லாம் தீயில் இருப்பதால்" வேடிக்கையானது), C ++ இன் தரநிலை மற்றும் பொதுவான பார்வை பற்றிய கேள்விகள் , சூடான தொழில்நுட்ப விவாதங்கள் மற்றும் ஹோலிவார்கள் இல்லாமல். எதையாவது முழுமையாக உறுதியாக நம்பாத அல்லது எதையாவது அறியாத உயிருள்ளவர்களும் குழுவில் உள்ளனர் என்பது தெரியவந்தது.

ஹோலிவார்களின் ரசிகர்களுக்கு, மூன்றாவது நிகழ்வு வழக்கில் இருந்தது - BOF அமர்வு “Go vs. C++”. நாங்கள் ஒரு Go காதலரை, C++ காதலரை அழைத்துச் செல்கிறோம், அமர்வு தொடங்கும் முன் அவர்கள் ஒன்றாக ஒரு தலைப்பில் 100500 ஸ்லைடுகளைத் தயார் செய்கிறோம் (C++ இல் உள்ள பேக்கேஜ்களில் உள்ள சிக்கல்கள் அல்லது Goவில் ஜெனரிக்ஸ் இல்லாமை போன்றவை), பின்னர் அவர்கள் தங்களுக்குள் கலகலப்பான விவாதம் மற்றும் பார்வையாளர்களுடன், மற்றும் பார்வையாளர்கள் ஒரே நேரத்தில் இரண்டு பார்வைகளைப் புரிந்து கொள்ள முயற்சி செய்கிறார்கள். ஒரு ஹோலிவர் சூழலில் இருந்து தொடங்கினால், மதிப்பீட்டாளர் தலையிட்டு கட்சிகளை சமரசம் செய்கிறார். இந்த வடிவம் போதைக்குரியது: தொடங்கிய சில மணிநேரங்களுக்குப் பிறகு, ஸ்லைடுகளில் பாதி மட்டுமே முடிக்கப்பட்டது. முடிவை பெரிதும் துரிதப்படுத்த வேண்டியிருந்தது.

• பங்குதாரர் நிற்கிறார்

மாநாட்டின் பங்காளிகள் அரங்குகளில் பிரதிநிதித்துவப்படுத்தப்பட்டனர் - ஸ்டாண்டில் அவர்கள் தற்போதைய திட்டங்களைப் பற்றி பேசினர், வேலைவாய்ப்பு மற்றும் வேலை வாய்ப்புகளை வழங்கினர், வினாடி வினாக்கள் மற்றும் சிறிய போட்டிகளை நடத்தினர், மேலும் நல்ல பரிசுகளை வழங்கினர். அதே நேரத்தில், சில நிறுவனங்கள் நேர்காணலின் ஆரம்ப கட்டங்களுக்கு செல்ல முன்வந்தன, இது அறிக்கைகளைக் கேட்பதற்கு மட்டுமல்லாமல் வந்தவர்களுக்கு பயனுள்ளதாக இருக்கும்.

அறிக்கையின் தொழில்நுட்ப விவரங்கள்

இரண்டு நாட்களும் அறிக்கைகளைக் கேட்டோம். சில சமயங்களில் இணையான அறிக்கைகளிலிருந்து ஒரு அறிக்கையைத் தேர்ந்தெடுப்பது கடினமாக இருந்தது - இடைவேளையின் போது பெற்ற அறிவைப் பிரித்து பரிமாறிக்கொள்ள ஒப்புக்கொண்டோம். அப்படியிருந்தும், அதிகம் விடப்பட்டதாகத் தெரிகிறது. நாங்கள் மிகவும் சுவாரஸ்யமாகக் கண்ட சில அறிக்கைகளின் உள்ளடக்கங்களைப் பற்றி இங்கே பேச விரும்புகிறோம்

கம்பைலர் மேம்படுத்தல்களின் ப்ரிஸம் மூலம் C++ இல் விதிவிலக்குகள், Roman Rusyaev

இருந்து ஸ்லைடு விளக்கக்காட்சிகள்

தலைப்பு குறிப்பிடுவது போல, ரோமன் எல்.எல்.வி.எம்.ஐ உதாரணமாகப் பயன்படுத்தி விதிவிலக்குகளுடன் வேலை பார்த்தார். அதே நேரத்தில், தங்கள் வேலையில் க்ளாங்கைப் பயன்படுத்தாதவர்களுக்கு, குறியீட்டை எவ்வாறு மேம்படுத்தலாம் என்பது குறித்த சில யோசனைகளை அறிக்கை இன்னும் கொடுக்க முடியும். கம்பைலர்கள் மற்றும் தொடர்புடைய நிலையான நூலகங்களின் உருவாக்குநர்கள் ஒருவருக்கொருவர் தொடர்புகொள்வதால், பல வெற்றிகரமான தீர்வுகள் ஒத்துப்போகின்றன.

எனவே, ஒரு விதிவிலக்கைக் கையாள, நீங்கள் நிறைய விஷயங்களைச் செய்ய வேண்டும்: கையாளுதல் குறியீடு (ஏதேனும் இருந்தால்) அல்லது தற்போதைய நிலையில் இலவச ஆதாரங்களை அழைக்கவும், மேலும் அடுக்கை மேலே சுழற்றவும். விதிவிலக்குகளைத் தூக்கி எறியக்கூடிய அழைப்புகளுக்கான கூடுதல் வழிமுறைகளை கம்பைலர் சேர்க்கிறது என்பதற்கு இவை அனைத்தும் வழிவகுக்கிறது. எனவே, விதிவிலக்கு உண்மையில் உயர்த்தப்படவில்லை என்றால், நிரல் இன்னும் தேவையற்ற செயல்களைச் செய்யும். எப்படியாவது மேல்நிலையைக் குறைப்பதற்காக, விதிவிலக்கு கையாளுதல் குறியீடு சேர்க்கப்பட வேண்டிய அவசியமில்லாத அல்லது "கூடுதல்" வழிமுறைகளின் எண்ணிக்கையைக் குறைக்கக்கூடிய சூழ்நிலைகளைத் தீர்மானிக்க LLVM பல ஹூரிஸ்டிக்களைக் கொண்டுள்ளது.

பேச்சாளர் அவற்றில் ஒரு டஜன் பற்றி ஆய்வு செய்து, நிரல் செயல்படுத்தலை விரைவுபடுத்த உதவும் மற்றும் இந்த முறைகள் பொருந்தாத இரண்டு சூழ்நிலைகளையும் காட்டுகிறது.

எனவே, விதிவிலக்கு கையாளுதலைக் கொண்ட குறியீட்டை எப்போதும் பூஜ்ஜிய மேல்நிலையுடன் செயல்படுத்த முடியாது என்ற முடிவுக்கு ரோமன் ருஸ்யாவ் மாணவர்களை அழைத்துச் செல்கிறார், மேலும் பின்வரும் ஆலோசனையை வழங்குகிறார்:

• நூலகங்களை உருவாக்கும் போது, ​​கொள்கையளவில் விதிவிலக்குகளை கைவிடுவது மதிப்பு;
• விதிவிலக்குகள் இன்னும் தேவைப்பட்டால், முடிந்தவரை எல்லா இடங்களிலும் noexcept (மற்றும் const) மாற்றிகளைச் சேர்ப்பது மதிப்பு. இதனால் கம்பைலர் முடிந்தவரை மேம்படுத்த முடியும்

பொதுவாக, விதிவிலக்குகள் குறைந்தபட்சமாகப் பயன்படுத்தப்படுவது அல்லது முற்றிலும் கைவிடப்படுவது என்ற கருத்தை பேச்சாளர் உறுதிப்படுத்தினார்.

அறிக்கை ஸ்லைடுகள் பின்வரும் இணைப்பில் கிடைக்கின்றன: [“எல்எல்விஎம் கம்பைலர் மேம்படுத்தல்களின் லென்ஸ் மூலம் சி++ விதிவிலக்குகள்”]

ஜெனரேட்டர்கள், கரோட்டின்கள் மற்றும் பிற மூளையை உருட்டும் இனிப்பு, ஆதி ஷவிட்

இருந்து ஸ்லைடு விளக்கக்காட்சிகள்

C++20 இல் புதுமைகளுக்கு அர்ப்பணிக்கப்பட்ட இந்த மாநாட்டின் பல அறிக்கைகளில் ஒன்று, அதன் வண்ணமயமான விளக்கக்காட்சிக்காக மட்டுமல்லாமல், சேகரிப்பு செயலாக்க தர்க்கத்தில் (லூப், கால்பேக்குகளுக்கு) ஏற்கனவே உள்ள சிக்கல்களை தெளிவாகக் கண்டறிந்ததற்காகவும் மறக்கமுடியாததாக இருந்தது.

ஆதி ஷாவிட் பின்வருவனவற்றை முன்னிலைப்படுத்துகிறார்: தற்போது கிடைக்கக்கூடிய முறைகள் முழு சேகரிப்பையும் கடந்து சில உள் இடைநிலை நிலைகளுக்கான அணுகலை வழங்காது (அல்லது கால்பேக்குகளின் போது அவை செய்கின்றன, ஆனால் கால்பேக் ஹெல் போன்ற அதிக எண்ணிக்கையிலான விரும்பத்தகாத பக்க விளைவுகளுடன்) . இடிரேட்டர்கள் இருப்பதாகத் தோன்றுகிறது, ஆனால் அவர்களுடன் கூட எல்லாம் அவ்வளவு சீராக இல்லை: பொதுவான நுழைவு மற்றும் வெளியேறும் புள்ளிகள் இல்லை (தொடக்கம் → முடிவு மற்றும் rbegin → ரென்ட் மற்றும் பல), நாம் எவ்வளவு காலம் மீண்டும் கூறுவோம் என்பது தெளிவாகத் தெரியவில்லை? C++20 இல் தொடங்கி, இந்த சிக்கல்கள் தீர்க்கப்படுகின்றன!

முதல் விருப்பம்: வரம்புகள். மறு செய்கைகளை மடக்குவதன் மூலம், மறு செய்கையின் ஆரம்பம் மற்றும் முடிவுக்கான பொதுவான இடைமுகத்தைப் பெறுகிறோம், மேலும் இசையமைக்கும் திறனையும் பெறுகிறோம். இவை அனைத்தும் முழு அளவிலான தரவு செயலாக்க குழாய்களை உருவாக்குவதை எளிதாக்குகிறது. ஆனால் எல்லாம் அவ்வளவு சீராக இல்லை: கணக்கீட்டு தர்க்கத்தின் ஒரு பகுதி ஒரு குறிப்பிட்ட மறு செய்கையின் செயல்பாட்டிற்குள் அமைந்துள்ளது, இது குறியீட்டைப் புரிந்துகொண்டு பிழைத்திருத்தத்தை சிக்கலாக்கும்.

இருந்து ஸ்லைடு விளக்கக்காட்சிகள்

சரி, இந்த விஷயத்தில், C++20 coroutines ஐச் சேர்த்தது (பைத்தானில் உள்ள ஜெனரேட்டர்களைப் போலவே செயல்படும் செயல்பாடுகள்): இடைநிலை நிலையைப் பாதுகாக்கும் போது சில தற்போதைய மதிப்பை வழங்குவதன் மூலம் செயல்படுத்தலை ஒத்திவைக்கலாம். இவ்வாறு, தரவு தோன்றும்படி வேலை செய்வதோடு மட்டுமல்லாமல், ஒரு குறிப்பிட்ட கரோட்டினுக்குள் அனைத்து தர்க்கங்களையும் இணைக்கிறோம்.

ஆனால் களிம்பில் ஒரு ஈ உள்ளது: இந்த நேரத்தில் அவை தற்போதுள்ள கம்பைலர்களால் ஓரளவு மட்டுமே ஆதரிக்கப்படுகின்றன, மேலும் அவை நாம் விரும்பும் அளவுக்கு நேர்த்தியாக செயல்படுத்தப்படவில்லை: எடுத்துக்காட்டாக, கரோட்டின்களில் குறிப்புகள் மற்றும் தற்காலிக பொருட்களைப் பயன்படுத்துவது இன்னும் மதிப்புக்குரியது அல்ல. கூடுதலாக, கரோட்டின்கள் என்னவாக இருக்க வேண்டும் என்பதில் சில கட்டுப்பாடுகள் உள்ளன, மேலும் constexpr செயல்பாடுகள், கன்ஸ்ட்ரக்டர்கள்/டிஸ்ட்ரக்டர்கள் மற்றும் மெயின் ஆகியவை இந்தப் பட்டியலில் சேர்க்கப்படவில்லை.

எனவே, தரவு செயலாக்க தர்க்கத்தின் எளிமையுடன் கரோட்டின்கள் சிக்கல்களின் குறிப்பிடத்தக்க பகுதியை தீர்க்கின்றன, ஆனால் அவற்றின் தற்போதைய செயலாக்கங்களுக்கு முன்னேற்றம் தேவைப்படுகிறது.

பொருட்கள்:

• C++ ரஷ்யாவிலிருந்து ஸ்லைடுகள் - ["ஜெனரேட்டர்கள், கரோட்டின்கள் மற்றும் பிற மூளையை உருட்டும் இனிப்பு"]
• CppCon 2019 இன் அறிக்கையின் வீடியோ பதிவு

Yandex.Taxi, Anton Polukhin வழங்கும் C++ தந்திரங்கள்

எனது தொழில்முறை நடவடிக்கைகளில், சில நேரங்களில் நான் முற்றிலும் துணை விஷயங்களைச் செயல்படுத்த வேண்டும்: உள் இடைமுகம் மற்றும் சில நூலகத்தின் 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_; 
};

இந்த எடுத்துக்காட்டில், முதலில் நான் வெளிப்புற நூலகங்களின் தலைப்பு கோப்புகளை அகற்ற விரும்புகிறேன் - இது வேகமாக தொகுக்கப்படும், மேலும் சாத்தியமான பெயர் மோதல்கள் மற்றும் பிற ஒத்த பிழைகளிலிருந்து உங்களைப் பாதுகாத்துக் கொள்ளலாம். 

சரி, .cpp கோப்பிற்கு #includeஐ நகர்த்தினோம்: மூடப்பட்ட 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"
    ); 
}

டிஸ்ட்ரக்டரைச் செயலாக்கும் போது டி ஏற்கனவே வரையறுக்கப்பட்டிருப்பதால், இந்தக் குறியீடு சரியாகப் பாகுபடுத்தப்பட்டு, தொகுக்கும் கட்டத்தில் பிழைகளாக உள்ளிட வேண்டிய அளவு மற்றும் சீரமைப்பு மதிப்புகளை வெளியிடும். எனவே, ஒரு கூடுதல் தொகுப்பு ரன் செலவில், மூடப்பட்ட வகுப்புகளின் மாறும் ஒதுக்கீட்டிலிருந்து விடுபடுவோம், செயல்படுத்தலுடன் API ஐ .cpp கோப்பில் மறைத்து, செயலியின் மூலம் தேக்ககத்திற்கு மிகவும் பொருத்தமான வடிவமைப்பைப் பெறுகிறோம்.

பதிவு செய்தல் மற்றும் பாகுபடுத்துதல் ஆகியவை சுவாரஸ்யமாக இல்லை, எனவே இந்த மதிப்பாய்வில் குறிப்பிடப்படாது.

அறிக்கை ஸ்லைடுகள் பின்வரும் இணைப்பில் கிடைக்கின்றன: ["டாக்ஸியில் இருந்து சி++ தந்திரங்கள்"]

உங்கள் குறியீட்டை DRY, Björn Fahller வைத்திருப்பதற்கான நவீன நுட்பங்கள்

இந்த பேச்சில், Björn Fahller மீண்டும் மீண்டும் நிலை சரிபார்ப்புகளின் ஸ்டைலிஸ்டிக் குறைபாட்டை எதிர்த்துப் பல வழிகளைக் காட்டுகிறார்:

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

தெரிந்ததா? சமீபத்திய தரநிலைகளில் அறிமுகப்படுத்தப்பட்ட பல சக்திவாய்ந்த C++ நுட்பங்களைப் பயன்படுத்துவதன் மூலம், எந்த செயல்திறன் அபராதமும் இல்லாமல் அதே செயல்பாட்டை நீங்கள் நேர்த்தியாக செயல்படுத்தலாம். ஒப்பிடு:   

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

சரி செய்யப்படாத எண்ணிக்கையிலான காசோலைகளைக் கையாள, நீங்கள் உடனடியாக மாறுபட்ட வார்ப்புருக்கள் மற்றும் மடிப்பு வெளிப்பாடுகளைப் பயன்படுத்த வேண்டும். enum இன் நிலை_வகை உறுப்புக்கு பல மாறிகளின் சமத்துவத்தை சரிபார்க்க வேண்டும் என்று வைத்துக்கொள்வோம். ஒரு உதவி செயல்பாட்டை எழுதுவது முதலில் நினைவுக்கு வருவது: ஏதேனும்_எது:

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

இந்த எடுத்துக்காட்டில், கன்ஸ்ட்ரக்டர் வாதங்களின் வகைகளை அறிந்த கம்பைலருக்கு தேவையான கட்டமைப்பு டெம்ப்ளேட் அளவுருக்களை பரிந்துரைக்க, கழித்தல் வழிகாட்டி உதவுகிறது. 

மேலும் - மிகவும் சுவாரஸ்யமானது. அதன் விளைவாக வரும் குறியீட்டை == க்கு அப்பால் ஒப்பீட்டு ஆபரேட்டர்களுக்கும், பின்னர் தன்னிச்சையான செயல்பாடுகளுக்கும் எவ்வாறு பொதுமைப்படுத்துவது என்பதை பிஜோர்ன் கற்பிக்கிறார். வழியில், no_unique_address பண்புக்கூறு (C++20) மற்றும் லாம்ப்டா செயல்பாடுகளில் உள்ள டெம்ப்ளேட் அளவுருக்கள் (C++20) போன்ற அம்சங்கள் பயன்பாட்டின் எடுத்துக்காட்டுகளைப் பயன்படுத்தி விளக்கப்பட்டுள்ளன. (ஆம், இப்போது லாம்ப்டா தொடரியல் நினைவில் கொள்வது இன்னும் எளிதானது - இவை அனைத்து வகையான அடைப்புக்குறிகளின் நான்கு தொடர்ச்சியான ஜோடிகளாகும்.) கன்ஸ்ட்ரக்டர் விவரங்களாக செயல்பாடுகளைப் பயன்படுத்தும் இறுதித் தீர்வு, லாம்ப்டாவின் சிறந்த மரபுகளில் உள்ள வெளிப்பாடு டூப்ளைக் குறிப்பிடாமல், உண்மையில் என் ஆன்மாவை வெப்பப்படுத்துகிறது. கால்குலஸ்.

முடிவில், அதை மெருகூட்ட மறக்காதீர்கள்:

• லாம்ப்டாக்கள் இலவசமாக constexpr என்பதை நினைவில் கொள்ளுங்கள்; 
• லாம்ப்டா க்ளோஷரில் உள்ள அளவுரு பேக் தொடர்பாக சரியான ஃபார்வர்டிங்கைச் சேர்த்து அதன் அசிங்கமான தொடரியலைப் பார்ப்போம்;
• கம்பைலருக்கு நிபந்தனையுடன் கூடிய மேம்படுத்தல்களுக்கு அதிக வாய்ப்புகளை வழங்குவோம் தவிர; 
• லாம்ப்டாஸின் வெளிப்படையான மதிப்புகளுக்கு நன்றி வார்ப்புருக்களில் மிகவும் புரிந்துகொள்ளக்கூடிய பிழை வெளியீட்டை கவனித்துக்கொள்வோம். இது வார்ப்புரு செயல்பாடு உண்மையில் அழைக்கப்படுவதற்கு முன், கம்பைலரை மேலும் சரிபார்ப்புகளை செய்ய கட்டாயப்படுத்தும் - வகை சரிபார்ப்பு கட்டத்தில். 

விவரங்களுக்கு, விரிவுரைப் பொருட்களைப் பார்க்கவும்: 

• ஸ்லைடுகளைப் புகாரளிக்கவும்: [உங்கள் குறியீட்டை உலர வைப்பதற்கான நவீன நுட்பங்கள்]
• கிதுப்பில் மூல குறியீடு
• ஆசிரியரின் வலைப்பதிவு கட்டுரை

எங்கள் பதிவுகள்

C++ ரஷ்யாவில் எங்கள் முதல் பங்கேற்பு அதன் தீவிரத்திற்காக மறக்கமுடியாதது. சி++ ரஷ்யாவை ஒரு நேர்மையான நிகழ்வாக நான் உணர்ந்தேன், அங்கு பயிற்சிக்கும் நேரடி தொடர்புக்கும் இடையிலான கோடு கிட்டத்தட்ட புரிந்துகொள்ள முடியாதது. பேச்சாளர்களின் மனநிலை முதல் நிகழ்வு பங்காளிகளின் போட்டிகள் வரை அனைத்தும் சூடான விவாதங்களுக்கு உகந்தவை. அறிக்கைகளைக் கொண்ட மாநாட்டின் உள்ளடக்கம், C++ கண்டுபிடிப்புகள், பெரிய திட்டங்களின் வழக்கு ஆய்வுகள் மற்றும் கருத்தியல் கட்டடக்கலை பரிசீலனைகள் உட்பட மிகவும் பரந்த அளவிலான தலைப்புகளை உள்ளடக்கியது. ஆனால் நிகழ்வின் சமூகக் கூறுகளை புறக்கணிப்பது நியாயமற்றது, இது C++ தொடர்பான மொழி தடைகளை கடக்க உதவுகிறது.

இதுபோன்ற நிகழ்வில் பங்கேற்க வாய்ப்பளித்த மாநாட்டு ஏற்பாட்டாளர்களுக்கு நன்றி!
C++ ரஷ்யாவின் கடந்த காலம், நிகழ்காலம் மற்றும் எதிர்காலம் பற்றிய அமைப்பாளர்களின் இடுகையை நீங்கள் பார்த்திருக்கலாம் JUG Ru வலைப்பதிவில்.

படித்ததற்கு நன்றி, நிகழ்வுகளை மீண்டும் கூறுவது பயனுள்ளதாக இருந்தது என்று நம்புகிறோம்!

ஆதாரம்: www.habr.com