C++ રશિયા: તે કેવી રીતે થયું

જો નાટકની શરૂઆતમાં તમે કહો કે દિવાલ પર C++ કોડ લટકાવવામાં આવ્યો છે, તો અંત સુધીમાં તે તમને પગમાં મારશે.

Bjarne Stroustrup

ઑક્ટોબર 31 થી નવેમ્બર 1 સુધી, સેન્ટ પીટર્સબર્ગમાં C++ રશિયા પિટર કોન્ફરન્સ યોજાઈ હતી - જે રશિયામાં મોટા પાયે પ્રોગ્રામિંગ કોન્ફરન્સમાંની એક, જેયુજી રૂ ગ્રુપ દ્વારા આયોજિત કરવામાં આવી હતી. આમંત્રિત વક્તાઓમાં C++ સ્ટાન્ડર્ડ કમિટીના સભ્યો, CppCon સ્પીકર્સ, O'Reilly પુસ્તકના લેખકો અને LLVM, libc++ અને બૂસ્ટ જેવા પ્રોજેક્ટના જાળવણીકારોનો સમાવેશ થાય છે. કોન્ફરન્સનો ઉદ્દેશ્ય અનુભવી C++ વિકાસકર્તાઓને છે જેઓ તેમની કુશળતાને વધુ ઊંડું કરવા અને લાઇવ કોમ્યુનિકેશનમાં અનુભવોની આપ-લે કરવા માગે છે. વિદ્યાર્થીઓ, સ્નાતક વિદ્યાર્થીઓ અને યુનિવર્સિટીના શિક્ષકોને ખૂબ જ સરસ ડિસ્કાઉન્ટ આપવામાં આવે છે.

કોન્ફરન્સની મોસ્કો આવૃત્તિ આવતા વર્ષે એપ્રિલની શરૂઆતમાં મુલાકાત લેવા માટે ઉપલબ્ધ હશે, પરંતુ તે દરમિયાન અમારા વિદ્યાર્થીઓ તમને જણાવશે કે છેલ્લી ઇવેન્ટમાં તેઓએ કઈ રસપ્રદ બાબતો શીખી. 

માંથી ફોટો કોન્ફરન્સ આલ્બમ

ઔંસ

નેશનલ રિસર્ચ યુનિવર્સિટી હાયર સ્કૂલ ઓફ ઈકોનોમિક્સ - સેન્ટ પીટર્સબર્ગના બે વિદ્યાર્થીઓએ આ પોસ્ટ પર કામ કર્યું:

• લિઝા વાસિલેન્કો એપ્લાઇડ મેથેમેટિક્સ અને કોમ્પ્યુટર સાયન્સ પ્રોગ્રામના ભાગરૂપે પ્રોગ્રામિંગ લેંગ્વેજનો અભ્યાસ કરતી 4ઠ્ઠી વર્ષની અંડરગ્રેજ્યુએટ વિદ્યાર્થી છે. યુનિવર્સિટીમાં મારા પ્રથમ વર્ષમાં C++ ભાષા સાથે પરિચિત થયા પછી, મેં ઉદ્યોગમાં ઇન્ટર્નશીપ દ્વારા તેની સાથે કામ કરવાનો અનુભવ મેળવ્યો. સામાન્ય રીતે પ્રોગ્રામિંગ ભાષાઓ અને ખાસ કરીને કાર્યાત્મક પ્રોગ્રામિંગ માટેના મારા જુસ્સાએ કોન્ફરન્સમાં અહેવાલોની પસંદગી પર તેની છાપ છોડી દીધી.
• ડાન્યા સ્મિર્નોવ માસ્ટર પ્રોગ્રામ “પ્રોગ્રામિંગ અને ડેટા એનાલિસિસ” ની 1લી વર્ષની વિદ્યાર્થીની છે. શાળામાં જ હતો ત્યારે, મેં C++ માં ઓલિમ્પિયાડની સમસ્યાઓ લખી, અને પછી એવું બન્યું કે ભાષા સતત શૈક્ષણિક પ્રવૃત્તિઓમાં આવી અને છેવટે મુખ્ય કાર્યકારી ભાષા બની. મેં મારા જ્ઞાનને સુધારવા અને નવી તકો વિશે જાણવા માટે કોન્ફરન્સમાં ભાગ લેવાનું નક્કી કર્યું.

ન્યૂઝલેટરમાં, ફેકલ્ટી નેતૃત્વ ઘણીવાર અમારી વિશેષતા સાથે સંબંધિત શૈક્ષણિક ઇવેન્ટ્સ વિશેની માહિતી શેર કરે છે. સપ્ટેમ્બરમાં અમે C++ રશિયા વિશે માહિતી જોઈ અને શ્રોતાઓ તરીકે નોંધણી કરવાનું નક્કી કર્યું. આવી પરિષદોમાં ભાગ લેવાનો આ અમારો પ્રથમ અનુભવ છે.

કોન્ફરન્સ માળખું

• અહેવાલો

બે દિવસ દરમિયાન, નિષ્ણાતોએ 30 અહેવાલો વાંચ્યા, જેમાં ઘણા ચર્ચાસ્પદ વિષયો આવરી લેવામાં આવ્યા: લાગુ પડતી સમસ્યાઓને ઉકેલવા માટે ભાષાની વિશેષતાઓનો બુદ્ધિશાળી ઉપયોગ, નવા ધોરણના સંબંધમાં આગામી ભાષા અપડેટ્સ, C++ ડિઝાઇનમાં સમાધાન અને તેના પરિણામો સાથે કામ કરતી વખતે સાવચેતીઓ, ઉદાહરણો. રસપ્રદ પ્રોજેક્ટ આર્કિટેક્ચર, તેમજ ભાષા ઈન્ફ્રાસ્ટ્રક્ચરની કેટલીક અંડર-ધ-હૂડ વિગતો. ત્રણ પ્રદર્શન એક સાથે થયા, મોટાભાગે બે રશિયનમાં અને એક અંગ્રેજીમાં.

• ચર્ચા ઝોન

ભાષણ પછી, બધા ન પૂછાયેલા પ્રશ્નો અને અધૂરી ચર્ચાઓને માર્કર બોર્ડથી સજ્જ વક્તાઓ સાથે વાતચીત માટે ખાસ નિયુક્ત વિસ્તારોમાં સ્થાનાંતરિત કરવામાં આવી હતી. સુખદ વાર્તાલાપ સાથે ભાષણો વચ્ચેના વિરામને દૂર કરવાની સારી રીત.

• લાઈટનિંગ ટોક્સ અને અનૌપચારિક ચર્ચાઓ

જો તમે ટૂંકો અહેવાલ આપવા માંગતા હો, તો તમે વ્હાઇટબોર્ડ પર સાંજે લાઈટનિંગ ટોક માટે સાઇન અપ કરી શકો છો અને કોન્ફરન્સ વિષય પર કંઈપણ વિશે વાત કરવા માટે પાંચ મિનિટનો સમય મેળવી શકો છો. ઉદાહરણ તરીકે, C++ માટે સેનિટાઈઝરનો ઝડપી પરિચય (કેટલાક માટે તે નવું હતું) અથવા સાઈન વેવ જનરેશનમાં બગ વિશેની વાર્તા જે ફક્ત સાંભળી શકાય છે, પણ જોઈ શકાતી નથી.

બીજું ફોર્મેટ પેનલ ચર્ચા છે "હાર્ટ ટુ હાર્ટ કમિટી સાથે." સ્ટેજ પર માનકીકરણ સમિતિના કેટલાક સભ્યો છે, પ્રોજેક્ટર પર એક સગડી છે (સત્તાવાર રીતે - એક નિષ્ઠાવાન વાતાવરણ બનાવવા માટે, પરંતુ કારણ "કારણ કે બધું જ આગમાં છે" વધુ રમુજી લાગે છે), ધોરણ અને C++ ની સામાન્ય દ્રષ્ટિ વિશે પ્રશ્નો. , ગરમ તકનીકી ચર્ચાઓ અને હોલીવાર વગર. તે બહાર આવ્યું છે કે સમિતિમાં એવા જીવંત લોકો પણ છે કે જેઓ કંઈક વિશે સંપૂર્ણ ખાતરી નથી અથવા કંઈક જાણતા નથી.

હોલીવરના ચાહકો માટે, ત્રીજી ઘટના કેસ પર રહી - BOF સત્ર “ગો વિ. C++”. અમે એક ગો પ્રેમી, એક C++ પ્રેમીને લઈએ છીએ, સત્રની શરૂઆત પહેલાં તેઓ સાથે મળીને એક વિષય પર 100500 સ્લાઇડ્સ તૈયાર કરે છે (જેમ કે C++ માં પેકેજની સમસ્યા અથવા Go માં જેનરિકનો અભાવ), અને પછી તેઓ એકબીજા સાથે જીવંત ચર્ચા કરે છે અને પ્રેક્ષકો સાથે, અને પ્રેક્ષકો એક સાથે બે દૃષ્ટિકોણને સમજવાનો પ્રયાસ કરે છે. જો હોલિવર સંદર્ભની બહાર શરૂ થાય છે, તો મધ્યસ્થ દખલ કરે છે અને પક્ષકારો સાથે સમાધાન કરે છે. આ ફોર્મેટ વ્યસનકારક છે: શરૂઆતના કેટલાક કલાકો પછી, સ્લાઇડ્સનો માત્ર અડધો ભાગ પૂર્ણ થયો હતો. અંતને મોટા પ્રમાણમાં વેગ આપવો પડ્યો.

• ભાગીદાર ઊભો છે

કોન્ફરન્સના ભાગીદારોને હોલમાં રજૂ કરવામાં આવ્યા હતા - સ્ટેન્ડ પર તેઓએ વર્તમાન પ્રોજેક્ટ્સ વિશે વાત કરી, ઇન્ટર્નશીપ અને રોજગારની ઓફર કરી, ક્વિઝ અને નાની સ્પર્ધાઓ યોજી અને સરસ ઇનામો પણ આપ્યા. તે જ સમયે, કેટલીક કંપનીઓએ ઇન્ટરવ્યુના પ્રારંભિક તબક્કામાંથી પસાર થવાની ઓફર પણ કરી હતી, જે ફક્ત અહેવાલો સાંભળવા જ નહીં આવતા લોકો માટે ઉપયોગી થઈ શકે છે.

અહેવાલોની તકનીકી વિગતો

અમે બંને દિવસ અહેવાલો સાંભળ્યા. કેટલીકવાર સમાંતર રિપોર્ટ્સમાંથી એક રિપોર્ટ પસંદ કરવાનું મુશ્કેલ હતું - અમે વિભાજન કરવા અને વિરામ દરમિયાન મેળવેલા જ્ઞાનની આપલે કરવા સંમત થયા. અને તેમ છતાં, એવું લાગે છે કે ઘણું બાકી છે. અહીં અમે કેટલાક અહેવાલોની સામગ્રી વિશે વાત કરવા માંગીએ છીએ જે અમને સૌથી વધુ રસપ્રદ લાગ્યાં

કમ્પાઇલર ઓપ્ટિમાઇઝેશનના પ્રિઝમ દ્વારા C++ માં અપવાદો, રોમન રુસ્યાયેવ

થી સ્લાઇડ કરો પ્રસ્તુતિઓ

શીર્ષક સૂચવે છે તેમ, રોમન ઉદાહરણ તરીકે LLVM નો ઉપયોગ કરીને અપવાદો સાથે કામ કરવા તરફ ધ્યાન આપે છે. તે જ સમયે, જેઓ તેમના કાર્યમાં રણકારનો ઉપયોગ કરતા નથી, રિપોર્ટ હજુ પણ કોડને સંભવિત રીતે કેવી રીતે ઑપ્ટિમાઇઝ કરી શકાય તે અંગે થોડો ખ્યાલ આપી શકે છે. આ એટલા માટે છે કારણ કે કમ્પાઇલર્સ અને અનુરૂપ પ્રમાણભૂત પુસ્તકાલયોના વિકાસકર્તાઓ એકબીજા સાથે વાતચીત કરે છે અને ઘણા સફળ ઉકેલો એકરૂપ થઈ શકે છે.

તેથી, અપવાદને હેન્ડલ કરવા માટે, તમારે ઘણી બધી વસ્તુઓ કરવાની જરૂર છે: હેન્ડલિંગ કોડ (જો કોઈ હોય તો) અથવા વર્તમાન સ્તરે મફત સંસાધનોને કૉલ કરો અને સ્ટેકને વધુ ઊંચો કરો. આ બધું એ હકીકત તરફ દોરી જાય છે કે કમ્પાઇલર એવા કૉલ્સ માટે વધારાની સૂચનાઓ ઉમેરે છે જે સંભવિત અપવાદો ફેંકી દે છે. તેથી, જો અપવાદ વાસ્તવમાં ઉભો કરવામાં આવ્યો નથી, તો પ્રોગ્રામ હજુ પણ બિનજરૂરી ક્રિયાઓ કરશે. કોઈક રીતે ઓવરહેડ ઘટાડવા માટે, LLVM પાસે એવી પરિસ્થિતિઓ નક્કી કરવા માટે ઘણી હ્યુરિસ્ટિક્સ છે જ્યાં અપવાદ હેન્ડલિંગ કોડ ઉમેરવાની જરૂર નથી અથવા "વધારાની" સૂચનાઓની સંખ્યા ઘટાડી શકાય છે.

વક્તા તેમાંથી લગભગ એક ડઝનની તપાસ કરે છે અને બંને પરિસ્થિતિઓ બતાવે છે જ્યાં તેઓ પ્રોગ્રામના અમલીકરણને ઝડપી બનાવવામાં મદદ કરે છે, અને જ્યાં આ પદ્ધતિઓ લાગુ પડતી નથી.

આમ, રોમન રુસ્યાયેવ વિદ્યાર્થીઓને નિષ્કર્ષ પર લઈ જાય છે કે અપવાદ હેન્ડલિંગ ધરાવતા કોડને હંમેશા શૂન્ય ઓવરહેડ સાથે એક્ઝિક્યુટ કરી શકાતો નથી, અને નીચેની સલાહ આપે છે:

• પુસ્તકાલયોનો વિકાસ કરતી વખતે, તે સિદ્ધાંતમાં અપવાદોને છોડી દેવા યોગ્ય છે;
• જો અપવાદોની હજુ પણ જરૂર હોય, તો જ્યારે પણ શક્ય હોય ત્યારે દરેક જગ્યાએ noexcept (અને const) મોડિફાયર ઉમેરવા યોગ્ય છે જેથી કમ્પાઈલર શક્ય તેટલું ઑપ્ટિમાઇઝ કરી શકે.

સામાન્ય રીતે, સ્પીકરે એ દૃષ્ટિકોણની પુષ્ટિ કરી હતી કે અપવાદોનો ઉપયોગ ઓછામાં ઓછો અથવા સંપૂર્ણપણે છોડી દેવામાં આવે છે.

રિપોર્ટની સ્લાઇડ્સ નીચેની લિંક પર ઉપલબ્ધ છે: [“LLVM કમ્પાઇલર ઑપ્ટિમાઇઝેશનના લેન્સ દ્વારા C++ અપવાદો”]

જનરેટર, કોરોટીન અને અન્ય મગજ-અનરોલિંગ મીઠાશ, આદિ શવિત

થી સ્લાઇડ કરો પ્રસ્તુતિઓ

C++20 માં નવીનતાઓને સમર્પિત આ કોન્ફરન્સના ઘણા અહેવાલોમાંથી એક માત્ર તેની રંગીન પ્રસ્તુતિ માટે જ નહીં, પણ સંગ્રહ પ્રક્રિયા તર્ક (લૂપ, કૉલબેક્સ માટે) સાથેની હાલની સમસ્યાઓની સ્પષ્ટ ઓળખ માટે પણ યાદગાર હતો.

આદિ શવિત નીચેનાને હાઇલાઇટ કરે છે: હાલમાં ઉપલબ્ધ પદ્ધતિઓ સમગ્ર સંગ્રહમાંથી પસાર થાય છે અને કેટલીક આંતરિક મધ્યવર્તી સ્થિતિમાં પ્રવેશ આપતી નથી (અથવા તેઓ કૉલબેકના કિસ્સામાં કરે છે, પરંતુ મોટી સંખ્યામાં અપ્રિય આડઅસરો સાથે, જેમ કે કૉલબેક હેલ) . એવું લાગે છે કે ત્યાં પુનરાવર્તકો છે, પરંતુ તેમની સાથે પણ બધું એટલું સરળ નથી: ત્યાં કોઈ સામાન્ય પ્રવેશ અને બહાર નીકળવાના બિંદુઓ નથી (પ્રારંભ → અંત વિરુદ્ધ આરબીગિન → રેન્ડ અને તેથી વધુ), તે સ્પષ્ટ નથી કે આપણે કેટલા સમય સુધી પુનરાવર્તન કરીશું? C++20 થી શરૂ કરીને, આ સમસ્યાઓ હલ થાય છે!

પ્રથમ વિકલ્પ: શ્રેણીઓ. પુનરાવર્તકોને લપેટીને, અમને પુનરાવર્તનની શરૂઆત અને અંત માટે એક સામાન્ય ઇન્ટરફેસ મળે છે, અને અમને કંપોઝ કરવાની ક્ષમતા પણ મળે છે. આ બધું સંપૂર્ણ ડેટા પ્રોસેસિંગ પાઇપલાઇન્સ બનાવવાનું સરળ બનાવે છે. પરંતુ બધું એટલું સરળ નથી: ગણતરીના તર્કનો ભાગ ચોક્કસ ઇટરરેટરના અમલીકરણની અંદર સ્થિત છે, જે કોડને સમજવા અને ડીબગ કરવા માટે જટિલ બનાવી શકે છે.

થી સ્લાઇડ કરો પ્રસ્તુતિઓ

ઠીક છે, આ કિસ્સામાં, C++20 એ કોરોટીન્સ ઉમેર્યા (કાર્યો કે જેની વર્તણૂક પાયથોનમાં જનરેટર જેવી જ છે): મધ્યવર્તી સ્થિતિને સાચવીને અમુક વર્તમાન મૂલ્ય પરત કરીને અમલને સ્થગિત કરી શકાય છે. આમ, અમે માત્ર ડેટા સાથે કામ કરીને જ નહીં, પણ ચોક્કસ કોરોટીનની અંદરના તમામ તર્કને સમાવીને પણ હાંસલ કરીએ છીએ.

પરંતુ મલમમાં એક ફ્લાય છે: આ ક્ષણે તેઓ ફક્ત હાલના કમ્પાઇલર્સ દ્વારા આંશિક રીતે સપોર્ટેડ છે, અને અમે ઇચ્છીએ છીએ તેટલું સરસ રીતે અમલમાં મૂકાતા નથી: ઉદાહરણ તરીકે, કોરોટીનમાં સંદર્ભો અને અસ્થાયી વસ્તુઓનો ઉપયોગ કરવો તે હજી યોગ્ય નથી. ઉપરાંત, કોરોટીન્સ શું હોઈ શકે તેના પર કેટલાક નિયંત્રણો છે, અને કોન્સ્ટેક્સપ્ર ફંક્શન્સ, કન્સ્ટ્રક્ટર/ડિસ્ટ્રક્ટર અને મુખ્ય આ સૂચિમાં શામેલ નથી.

આમ, કોરોટીન્સ ડેટા પ્રોસેસિંગ તર્કની સરળતા સાથે સમસ્યાઓના નોંધપાત્ર ભાગને હલ કરે છે, પરંતુ તેમના વર્તમાન અમલીકરણમાં સુધારાની જરૂર છે.

સામગ્રી:

• 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++ યુક્તિઓ"]

તમારો કોડ DRY રાખવા માટેની આધુનિક તકનીકો, Björn Fahller

આ વાર્તાલાપમાં, બ્યોર્ન ફાહલર પુનરાવર્તિત સ્થિતિ તપાસની શૈલીયુક્ત ખામીનો સામનો કરવા માટે ઘણી અલગ રીતો બતાવે છે:

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

પરિચિત અવાજ? તાજેતરના ધોરણોમાં રજૂ કરવામાં આવેલી ઘણી શક્તિશાળી C++ તકનીકોનો ઉપયોગ કરીને, તમે કોઈપણ પ્રદર્શન દંડ વિના સમાન કાર્યક્ષમતાને સુંદર રીતે અમલમાં મૂકી શકો છો. તુલના:   

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

અનિશ્ચિત સંખ્યામાં ચેકને હેન્ડલ કરવા માટે, તમારે તરત જ વૈવિધ્યસભર નમૂનાઓ અને ફોલ્ડ એક્સપ્રેશનનો ઉપયોગ કરવાની જરૂર છે. ચાલો માની લઈએ કે આપણે enum ના state_type એલિમેન્ટ સાથે અનેક ચલોની સમાનતા તપાસવા માંગીએ છીએ. પ્રથમ વસ્તુ જે ધ્યાનમાં આવે છે તે છે સહાયક કાર્ય લખવાનું છે_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);

આ ઉદાહરણમાં, કપાત માર્ગદર્શિકા કમ્પાઇલરને ઇચ્છિત સ્ટ્રક્ચર ટેમ્પલેટ પરિમાણો સૂચવવા માટે સેવા આપે છે, જે કન્સ્ટ્રક્ટર દલીલોના પ્રકારો જાણે છે. 

આગળ - વધુ રસપ્રદ. બ્યોર્ન શીખવે છે કે કેવી રીતે પરિણામી કોડનું સામાન્યીકરણ ==થી આગળની સરખામણી ઓપરેટરો માટે, અને પછી મનસ્વી કામગીરી માટે. રસ્તામાં, no_unique_address એટ્રિબ્યુટ (C++20) અને લેમ્બડા ફંક્શન્સ (C++20) માં ટેમ્પલેટ પેરામીટર્સ જેવી સુવિધાઓ ઉપયોગના ઉદાહરણોનો ઉપયોગ કરીને સમજાવવામાં આવે છે. (હા, હવે લેમ્બડા સિન્ટેક્સ યાદ રાખવું વધુ સરળ છે - આ તમામ પ્રકારના કૌંસની સતત ચાર જોડી છે.) કન્સ્ટ્રક્ટર વિગતો તરીકે ફંક્શનનો ઉપયોગ કરીને અંતિમ ઉકેલ ખરેખર મારા આત્માને ગરમ કરે છે, લેમ્બડાની શ્રેષ્ઠ પરંપરાઓમાં અભિવ્યક્તિ ટપલનો ઉલ્લેખ ન કરવો. કલન

અંતે, તેને પોલિશ કરવાનું ભૂલશો નહીં:

• યાદ રાખો કે lambdas મફતમાં constexpr છે; 
• ચાલો સંપૂર્ણ ફોરવર્ડિંગ ઉમેરીએ અને લેમ્બડા ક્લોઝરમાં પેરામીટર પેકના સંબંધમાં તેના નીચ સિન્ટેક્સને જોઈએ;
• ચાલો કમ્પાઈલરને કંડીશનલ નોઈક્સાઇડ સાથે ઓપ્ટિમાઈઝેશન માટે વધુ તકો આપીએ; 
• ચાલો લેમ્બડાસના સ્પષ્ટ વળતર મૂલ્યોને આભારી ટેમ્પલેટ્સમાં વધુ સમજી શકાય તેવી ભૂલ આઉટપુટની કાળજી લઈએ. આ કમ્પાઈલરને ટેમ્પલેટ ફંક્શનને વાસ્તવમાં બોલાવવામાં આવે તે પહેલાં વધુ તપાસ કરવા દબાણ કરશે - પ્રકાર તપાસના તબક્કે. 

વિગતો માટે, કૃપા કરીને વ્યાખ્યાન સામગ્રીનો સંદર્ભ લો: 

• સ્લાઇડ્સની જાણ કરો: [તમારા કોડને સુકા રાખવા માટેની આધુનિક તકનીકો]
• ગીથબ પર સોર્સ કોડ
• લેખકનો બ્લોગ લેખ

અમારી છાપ

C++ રશિયામાં અમારી પ્રથમ સહભાગિતા તેની તીવ્રતા માટે યાદગાર હતી. મને C++ રશિયાની એક નિષ્ઠાવાન ઘટના તરીકેની છાપ મળી, જ્યાં તાલીમ અને જીવંત સંચાર વચ્ચેની રેખા લગભગ અગોચર છે. વક્તાઓના મૂડથી લઈને ઇવેન્ટ પાર્ટનર્સ તરફથી સ્પર્ધાઓ સુધીની દરેક બાબત ગરમ ચર્ચાઓ માટે અનુકૂળ છે. કોન્ફરન્સની સામગ્રી, જેમાં અહેવાલોનો સમાવેશ થાય છે, તેમાં C++ નવીનતાઓ, મોટા પ્રોજેક્ટ્સના કેસ સ્ટડીઝ અને વૈચારિક સ્થાપત્ય વિચારણાઓ સહિતના વિષયોની એકદમ વ્યાપક શ્રેણી આવરી લેવામાં આવી છે. પરંતુ ઘટનાના સામાજિક ઘટકને અવગણવું અયોગ્ય હશે, જે માત્ર C++ ના સંબંધમાં ભાષાના અવરોધોને દૂર કરવામાં મદદ કરે છે.

આવી ઇવેન્ટમાં ભાગ લેવાની તક બદલ અમે કોન્ફરન્સના આયોજકોનો આભાર માનીએ છીએ!
તમે C++ રશિયાના ભૂતકાળ, વર્તમાન અને ભવિષ્ય વિશે આયોજકોની પોસ્ટ જોઈ હશે JUG Ru બ્લોગ પર.

વાંચવા બદલ આભાર, અને અમે આશા રાખીએ છીએ કે અમારી ઘટનાઓનું ફરીથી કહેવું મદદરૂપ હતું!

સોર્સ: www.habr.com