C ++ 20 में दिखाई देने वाली अवधारणाएं एक लंबे और व्यापक रूप से चर्चा का विषय हैं। वर्षों से संचित सामग्री की अधिकता (विश्व स्तरीय विशेषज्ञों के भाषणों सहित) के बावजूद, अभी भी लागू प्रोग्रामर (जो मानक के साथ रोज सोते नहीं हैं) के बीच भ्रम की स्थिति है कि C ++ 20 अवधारणाएं क्या हैं और क्या वे हैं यदि वर्षों में सक्षम किया गया है तो हमें जरूरत है। आंशिक रूप से गलती यह है कि अवधारणाएं 15 साल में कैसे विकसित हुईं (कॉन्सेप्ट फुल + कॉन्सेप्ट मैप -> कॉन्सेप्ट लाइट), और आंशिक रूप से क्योंकि अवधारणाएं अन्य भाषाओं (जावा / सी # जेनेरिक सीमाएं, अनुष्ठान लक्षण) में समान टूल के विपरीत हैं। ..)।

C ++ रूस 2019 सम्मेलन से ReSharper C ++ टीम से एंड्री डेविडोव की एक रिपोर्ट के कट - वीडियो और ट्रांसक्रिप्ट के तहत। एंड्री ने C ++ 20 के अवधारणा-संबंधी नवाचारों की एक संक्षिप्त समीक्षा की, जिसके बाद उन्होंने C ++ 17 और C ++ 20 समाधानों की तुलना करते हुए STL के कुछ वर्गों और कार्यों के कार्यान्वयन की जांच की। आगे की कहानी उसकी ओर से है।

अवधारणाओं के बारे में बात करें। यह एक बहुत ही जटिल और व्यापक विषय है, इसलिए रिपोर्ट की तैयारी करते समय, मैं कुछ मुश्किल में था। मैंने C ++ समुदाय के सर्वश्रेष्ठ वक्ताओं में से एक आंद्रेई अलेक्जेंड्रेस्कु के अनुभव को बदलने का फैसला किया।

नवंबर 2018 में, मीटिंग सी ++ के उद्घाटन पर बोलते हुए, आंद्रेई ने दर्शकों से पूछा कि सी ++ की अगली बड़ी विशेषता क्या होगी:

• अवधारणाओं
• metaclasses
• या आत्मनिरीक्षण?

आइए इस प्रश्न से शुरू करते हैं। क्या आपको लगता है कि C ++ में अगली बड़ी विशेषता अवधारणाएं होंगी?

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

जब हम C ++ 20 में अवधारणाओं के बारे में बात करते हैं तो हमारा क्या मतलब है? इस सुविधा पर कम से कम 2003 से चर्चा की गई है, और इस समय के दौरान यह बहुत विकसित होने में कामयाब रही है। आइए देखें कि C ++ 20 में अवधारणा संबंधी कौन-कौन सी नई विशेषताएं दिखाई दीं।

"अवधारणाओं" नामक एक नई इकाई को concept कीवर्ड द्वारा परिभाषित किया गया है। यह टेम्पलेट मापदंडों पर एक विधेय है। यह कुछ इस तरह दिखता है:

 template <typename T> concept NoThrowDefaultConstructible = noexept(T{}); template <typename From, typename To> concept Assignable = std::is_assignable_v<From, To> 

मैंने केवल "टेम्पलेट मापदंडों पर" वाक्यांश का उपयोग नहीं किया है, न कि "प्रकारों पर", क्योंकि अवधारणाओं को गैर-मानक टेम्पलेट मापदंडों पर परिभाषित किया जा सकता है। यदि आपके पास कुछ भी करने के लिए नहीं है, तो आप एक संख्या के लिए एक अवधारणा को परिभाषित कर सकते हैं:

 template<int I> concept Even = I % 2 == 0; 

लेकिन यह ठेठ और atypical टेम्पलेट मापदंडों को मिश्रण करने के लिए अधिक समझ में आता है। हम एक प्रकार को छोटा कहते हैं यदि इसका आकार और संरेखण निर्दिष्ट सीमाओं से अधिक नहीं है:

 template<typename T, size_t MaxSize, size_t MaxAlign> concept Small = sizeof(T) <= MaxSize && alignof(T) <= MaxAlign; 

शायद, यह अभी तक स्पष्ट नहीं है कि हमें भाषा में एक नई इकाई को constexpr bool क्यों है, और क्यों अवधारणा सिर्फ एक constexpr bool वैरिएबल नहीं है।

 //  `concept`    ? #define concept constexpr bool 

अवधारणाओं का उपयोग कैसे किया जाता है?

समझने के लिए, आइए देखें कि अवधारणाओं का उपयोग कैसे किया जाता है।

सबसे पहले, constexpr bool वेरिएबल्स की तरह, संकलन-समय में जहाँ भी आपको बूलियन अभिव्यक्ति की आवश्यकता होती है, उनका उपयोग किया जा सकता है। उदाहरण के लिए, static_assert अंदर या noexcept अंदर
विनिर्देशों:

 // bool expression evaluated in compile-time static_assert(Assignable<float, int>); template<typename T> void test() noexcept(NothrowDefaultConstructible<T>) { T t; ... } 

दूसरी बात, टेम्पलेट मापदंडों को परिभाषित करते समय typename या class कीवर्ड के बजाय अवधारणाओं का उपयोग किया जा सकता है। एक सरल optional वर्ग को परिभाषित करें जो बस बूलीयन ध्वज की एक जोड़ी को initialized और मानों में संग्रहीत करेगा। स्वाभाविक रूप से, ऐसे optional केवल तुच्छ प्रकारों पर लागू होते हैं। इसलिए, हम यहाँ Trivial लिख रहे हैं और जब हम कुछ गैर-तुच्छ से तात्कालिक करने का प्रयास करते हैं, उदाहरण के लिए, std::string , तो हमारे पास एक संकलन त्रुटि होगी:

 //  type-parameter-key (class, typename) template<Trivial T> class simple_optional { T value; bool initialized = false; ... }; 

अवधारणाओं को आंशिक रूप से लागू किया जा सकता है। उदाहरण के लिए, हम अपनी कक्षा को छोटे बफर अनुकूलन के साथ लागू करते हैं। एक निश्चित Size और Alignment साथ SB संरचना (छोटे बफर) को परिभाषित करें, हम SB और ढेर पर सूचक से यूनियन स्टोर करेंगे। और अब, यदि एक छोटा प्रकार कंस्ट्रक्टर में आता है, तो हम इसे SB में डाल सकते हैं। यह निर्धारित करने के लिए कि एक प्रकार छोटा है, हम लिखते हैं कि यह Small की अवधारणा को संतुष्ट करता है। Small अवधारणा में 3 टेम्पलेट पैरामीटर लिए गए: हमने दो को परिभाषित किया, और हमें एक टेम्पलेट पैरामीटर से एक फ़ंक्शन मिला:

 //   class any { struct SB { static constexpr size_t Size = ...; static constexpr size_t Alignment = ...; aligned_storage_t<Size, Alignment> storage; }; union { SB sb; void* handle; }; template<Small<SB::Size, SB::Alignment> T> any(T const & t) : sb(...) ... }; 

एक छोटा रिकॉर्ड है। हम टेम्पलेट पैरामीटर का नाम लिखते हैं, संभवतः auto से पहले कुछ तर्कों के साथ। पिछला उदाहरण इस तरह से फिर से लिखा गया है:

 // Terse syntax (  auto) class any { struct SB { static constexpr size_t Size = ...; static constexpr size_t Alignment = ...; aligned_storage_t<Size, Alignment> storage; }; union { SB sb; void* handle; }; any(Small<SB::Size, SB::Alignment> auto const & t) : sb(...) ... }; 

शायद, किसी भी जगह जहां हम auto लिखते हैं, अब आप इसके सामने अवधारणा का नाम लिख सकते हैं।

get_handle फ़ंक्शन को परिभाषित करें, जो ऑब्जेक्ट के लिए कुछ handle लौटाता है।
हम मानते हैं कि छोटी वस्तुएं खुद को handle , और बड़ी वस्तुओं के लिए, उनके लिए एक सूचक handle । चूँकि हमारी दो शाखाएँ हैं if constexpr विभिन्न प्रकार के if constexpr को व्यक्त करता है, तो यह हमारे लिए सुविधाजनक है कि हम इस फ़ंक्शन के प्रकार को स्पष्ट रूप से निर्दिष्ट न करें, लेकिन संकलक से इसका उत्पादन करने के लिए कहें। लेकिन अगर हम बस auto , तो हम यह जानकारी खो देंगे कि संकेतित मूल्य छोटा है, यह सूचक से अधिक नहीं है:

 //Terse syntax (  auto) template<typename T> concept LEPtr = Small<T, sizeof(void *), alignof(void *)>; template<typename T> auto get_handle(T& object) { if constexpr (LEPtr<T>) return object; else return &object; } 

C ++ 20 में, इससे पहले यह लिखना संभव होगा कि यह सिर्फ auto नहीं है, यह सीमित auto :

 // Terse syntax (  auto) template<typename T> concept LEPtr = Small<T, sizeof(void *), alignof(void *)>; template<typename T> LEPtr auto get_handle(T &object) { if constexpr (LEPtr<T>) return object; else return &object; } 

अभिव्यक्ति की आवश्यकता है

एक्सप्रेशन की आवश्यकता है अभिव्यक्ति'ओव का एक पूरा परिवार है, उनमें से सभी टाइप bool और संकलन-समय में गणना की जाती है। वे अभिव्यक्ति और प्रकार के बारे में बयानों का परीक्षण करने के लिए उपयोग किए जाते हैं। अवधारणाओं को परिभाषित करने के लिए अभिव्यक्ति की आवश्यकता होती है।

Constructible उदाहरण। जो लोग मेरी पिछली रिपोर्ट में थे, वे उसे देख चुके हैं:

 template<typename T, typename... Args> concept Constructible = requires(Args... args) { T{args...} }; 

और तुलना के साथ एक उदाहरण। मान लीजिए कि टाइप T Comparable यदि टाइप T की दो वस्तुओं की तुलना "कम" ऑपरेटर के उपयोग से की जा सकती है और परिणाम bool परिवर्तित हो जाता है। इस तीर और इसके बाद के प्रकार का मतलब है कि प्रकार की अभिव्यक्ति को bool में बदल दिया जाता है, और यह नहीं कि यह bool बराबर है:

 template<typename T> concept Comparable = requires(T const & a, T const & b) { {a < b} -> bool; }; 

हमने जो जांच की वह पहले से ही अवधारणाओं के उपयोग का एक पूर्ण उदाहरण दिखाने के लिए पर्याप्त है।

हमारे पास पहले से ही एक Comparable अवधारणा है, चलो पुनरावृत्तियों के लिए अवधारणाओं को परिभाषित करते हैं। मान RandomAccessIterator कि RandomAccessIterator एक BidirectionalIterator और कुछ अन्य गुण हैं। इसके साथ, हम Sortable की अवधारणा को परिभाषित करते हैं। Range को RandomAccess कहा जाता है यदि इसके RandomAccess एसेटर्स और उसके तत्वों की तुलना की जा सकती है। और अब हम एक sort फ़ंक्शन लिख सकते हैं जो न केवल स्वीकार करता है, बल्कि sort Sortable Range :

 // concepts,    ++20 template<typename Iterator> concept RandomAccessIterator = BidirectionalIterator<Iterator> && ...; template<typename R> concept Sortable = RandomAccessIterator<Iterator<R>> && Comparable<ValueType<R>>; template<Sortable Range> void sort(Range &) {...} 

अब, यदि हम इस फ़ंक्शन को उस चीज़ से कॉल करने का प्रयास करते हैं जो Sortable करने Sortable अवधारणा को संतुष्ट नहीं करता है, तो हमें कंपाइलर से एक स्पष्ट संदेश के साथ एक अच्छा, SFINAE- अनुकूल त्रुटि मिलेगी। आइए एक std::list 'या वेक्टर के तत्वों की तुलना करें जो तुलना नहीं कर सकते हैं:

 //concepts,    ++20,  struct X {}; void test() { vector<int> vi; sort(vi); // OK list <int> li; sort(li); // Fail, list<int>::iterator is not random access vector< X > vx; sort(vx); // Fail, X is not Comparable } 

क्या आपने पहले से ही अवधारणाओं या कुछ समान का उपयोग करने का एक समान उदाहरण देखा है? मैंने इसे कई बार देखा है। ईमानदारी से कहूं तो इसने मुझे बिल्कुल नहीं समझा। क्या हमें भाषा में इतनी नई संस्थाओं को बाड़ने की आवश्यकता है, अगर हम इसे C ++ 17 में प्राप्त कर सकते हैं?

 //concepts,    ++17 #define concept constexpr bool template<typename T> concept Comparable = is_convertible_v< decltype(declval<T const &>() < declval<T const &>()), bool >; template<typename Iterator> concept RandomAccessIterator = BidirectionalIterator<Iterator> && ...; template<typename R> concept Sortable = RandomAccessIterator<Iterator<R>> && Comparable<ValueType<R>>; template<typename Range, typename = enable_if_t<Sortable<Range>>> void sort(Range &) { ... } 

मैंने concept मैक्रो के concept कीवर्ड concept दर्ज की, और Comparable इस तरह Comparable फिर Comparable लिखा गया है। यह थोड़ा बदसूरत हो गया है, और यह हमारे लिए संकेत है कि अभिव्यक्ति की आवश्यकता है वास्तव में एक उपयोगी और सुविधाजनक चीज है। इसलिए हमने Sortable की अवधारणा को परिभाषित किया और enable_if का उपयोग enable_if संकेत दिया कि sort फ़ंक्शन Sortable Range स्वीकार करता है।

आप सोच सकते हैं कि संकलन त्रुटि संदेशों के अनुसार यह विधि बहुत कुछ खो देती है, लेकिन वास्तव में, यह कंपाइलर कार्यान्वयन की गुणवत्ता का मामला है। बताते चलें कि क्लैंग ने इस विषय को लेकर enable_if और विशेष रूप से उछल enable_if कि यदि आप enable_if स्थानापन्न enable_if हैं तो आपके पास पहला तर्क है
यदि false गणना false जाती है, तो वे इस त्रुटि को प्रस्तुत करते हैं ताकि इस तरह की आवश्यकता संतुष्ट न हो।

उपरोक्त उदाहरण अवधारणाओं के माध्यम से लिखा गया लगता है। मेरे पास एक परिकल्पना है: यह उदाहरण अनिर्णायक है, क्योंकि यह अवधारणाओं की मुख्य विशेषता का उपयोग नहीं करता है - खंड की आवश्यकता है।

खंड की आवश्यकता है

क्लॉज की आवश्यकता एक ऐसी चीज है जो लगभग किसी भी टेम्प्लेट घोषणा पर या गैर-टेम्पलेट फ़ंक्शन पर लटका हुआ है। संक्षेप में, यह कुछ बूलियन अभिव्यक्ति के बाद requires कीवर्ड की तरह दिखता है। टेम्प्लेट स्पेशलाइजेशन या ओवरलोडिंग उम्मीदवार को फ़िल्टर करने के लिए यह आवश्यक है, अर्थात यह SFINAE की तरह ही काम करता है, केवल सही तरीके से किया जाता है, और हैक्स द्वारा नहीं:

 // requires-clause template<typename R> concept Sortable = RandomAccessIterator<Iterator<R>> && Comparable<ValueType<R>>; template<Sortable Range> void sort(Range &) { ... } 

हमारे सॉर्ट किए गए उदाहरण में हम उपयोग कर सकते हैं जहां खंड की आवश्यकता है? अवधारणाओं को लागू करने के लिए एक संक्षिप्त वाक्यविन्यास के बजाय, हम इसे लिखते हैं:

 template<typename R> concept Sortable = RandomAccessIterator<Iterator<R>> && Comparable<ValueType<R>>; template<typename Range> requires Sortable<Range> void sort(Range &) { ... } 

ऐसा लगता है कि कोड बस खराब हो गया और बड़ा हो गया। लेकिन अब हम Sortable अवधारणा से छुटकारा पा सकते हैं। मेरे दृष्टिकोण से, यह एक सुधार है, क्योंकि Sortable कॉन्सेप्ट Sortable टॉटोलॉजिकल है: हम Sortable सब कुछ कहते हैं जिसे sort फ़ंक्शन में पास किया जा सकता है। इसका कोई भौतिक अर्थ नहीं है। हम इस तरह से कोड को फिर से लिखते हैं:

 //template<typename R> concept Sortable // = RandomAccessIterator<Iterator<R>> && Comparable<ValueType<R>>; template<typename Range> requires RandomAccessIterator<Iterator<Range>> && Comparable<ValueType<Range>>; void sort(Range &) { ... } 

अवधारणा से संबंधित सुविधाओं की सारांश सूची

C ++ 20 में अवधारणा से संबंधित नवाचारों की सूची इस तरह दिखती है। इस सूची की वस्तुओं को मेरे व्यक्तिपरक दृष्टिकोण से सुविधा की उपयोगिता में वृद्धि करके क्रमबद्ध किया गया है:

• नई इकाई concept । यह मुझे लगता है कि अतिरिक्त शब्दार्थ के साथ constexpr bool चर को समाप्त करके concept सार के बिना करना संभव होगा।
• अवधारणाओं को लागू करने के लिए विशेष वाक्यविन्यास। बेशक, यह सुखद है, लेकिन यह सिर्फ वाक्यविन्यास है। यदि C ++ प्रोग्रामर खराब सिंटैक्स से डरते थे, तो वे डर से बहुत पहले ही मर जाते थे।
• अभिव्यक्ति की आवश्यकता वास्तव में एक अच्छी बात है, और यह न केवल अवधारणाओं को परिभाषित करने के लिए उपयोगी है।
• क्लॉज के लिए अवधारणाओं का सबसे बड़ा मूल्य है, यह आपको SFINAE और C ++ टेम्प्लेट के अन्य प्रसिद्ध भयावहता के बारे में भूल जाने की अनुमति देता है।

अधिक अभिव्यक्ति की आवश्यकता है

इससे पहले कि हम क्लॉज़ की आवश्यकता के बारे में चर्चा करें, कुछ शब्दों के बारे में अभिव्यक्ति की आवश्यकता होती है।

सबसे पहले, उन्हें न केवल अवधारणाओं को परिभाषित करने के लिए उपयोग किया जा सकता है। पुराने समय से, Microsoft कंपाइलर का एक्सटेंशन __if_exists - __if_not_exists । यह एक नाम के अस्तित्व को सत्यापित करने के लिए संकलन-समय की अनुमति देता है और, इसके आधार पर, एक कोड ब्लॉक के संकलन को सक्षम या अक्षम करता है। और कोड बेस में, जिसके साथ मैंने कई साल पहले काम किया था, यह कुछ इस तरह था। एक फ़ंक्शन f() , यह टेम्पलेट प्रकार का एक बिंदु लेता है और इस बिंदु से ऊंचाई लेता है। इसे तीन-आयामी या दो-आयामी बिंदु द्वारा त्वरित किया जा सकता है। त्रि-आयामी के लिए, हम z समन्वय को ऊंचाई के रूप में मानते हैं, दो-आयामी के लिए, हम एक विशेष सतह सेंसर की ओर मुड़ते हैं। यह इस तरह दिखता है:

 struct Point2 { float x, y; }; struct Point3 { float x, y, z; }; template<typename Point> void f(Point const & p) { float h; __if_exists(Point::z) { h = pz; } __if_not_exists(Point::z) { h = sensor.get_height(p); } } 

C ++ 20 में, हम मानक कोड का उपयोग करके संकलक एक्सटेंशन का उपयोग किए बिना इसे फिर से लिख सकते हैं। यह मुझे लगता है कि यह बदतर नहीं हो गया है:

 struct Point2 { float x, y; }; struct Point3 { float x, y, z; }; template<typename Point> void f(Point const & p) { float h; if constexpr(requires { Point::z; }) h = pz; else h = sensor.get_height(p); } 

दूसरा बिंदु यह है कि आपको सिंटैक्स के साथ सतर्क रहने की आवश्यकता है अभिव्यक्ति की आवश्यकता है।
वे काफी शक्तिशाली हैं, और यह शक्ति कई नए सिंटैक्टिक निर्माणों की शुरूआत से हासिल की गई है। आप उनमें भ्रमित हो सकते हैं, कम से कम पहले।

आइए एक Sizable अवधारणा को परिभाषित करते हैं जो यह जांचता है कि कंटेनर में एक स्थिर विधि size जो size_t देता है। हम स्वाभाविक रूप से उम्मीद करते हैं कि vector<int> Sizable , हालांकि यह static_assert । क्या आप समझते हैं कि हमसे गलती क्यों हुई? यह कोड संकलन क्यों नहीं कर रहा है?

 template<typename Container> concept Sizable = requires(Container const & c) { c.size() -> size_t; }; static_assert(Sizable<vector<int>>); // Fail 

मैं आपको वह कोड दिखाता हूं जो संकलन करता है। इस तरह के एक X वर्ग Sizable अवधारणा को संतुष्ट करता है। अब आप समझ गए हैं कि हमें क्या समस्या है?

 struct X { struct Inner { int size_t; }; Inner* size() const; }; static_assert(Sizable<X>); // OK 

मुझे हाइलाइटिंग कोड ठीक करने दें। बाईं ओर, कोड रंगीन है जैसा कि मैं चाहूंगा। लेकिन वास्तव में, इसे दाईं ओर चित्रित किया जाना चाहिए:

देखें, तीर के बाद खड़े होने वाले size_t का रंग बदल गया है? मैं चाहता था कि यह एक प्रकार हो, लेकिन यह सिर्फ वह क्षेत्र है जिसे हम एक्सेस कर रहे हैं। अभिव्यक्ति में हमारे पास जो कुछ भी है, वह एक बड़ी अभिव्यक्ति है, और हम इसकी शुद्धता की जांच करते हैं। टाइप X , हाँ, यह एक वैध अभिव्यक्ति है; vector<int> , नहीं। जो हम चाहते थे उसे प्राप्त करने के लिए, हमें अभिव्यक्ति को ब्रेसिज़ में लेने की आवश्यकता है:

 template<typename Container> concept Sizable = requires(Container const & c) { {c.size()} -> size_t; }; static_assert(Sizable<vector<int>>); // OK struct X { struct Inner { int size_t; }; Inner* size() const; }; static_assert(Sizable<X>); // Fail 

लेकिन यह सिर्फ एक मजेदार उदाहरण है। सामान्य तौर पर, आपको बस सावधान रहने की जरूरत है।

अवधारणाओं का उपयोग करने के उदाहरण

जोड़ी वर्ग कार्यान्वयन

इसके अलावा मैं कुछ एसटीएल अंशों को प्रदर्शित करूंगा जिन्हें C ++ 17 में लागू किया जा सकता है, बल्कि बोझिल भी।
और फिर हम देखेंगे कि कैसे C ++ 20 में हम कार्यान्वयन में सुधार कर सकते हैं।

pair क्लास के साथ शुरू करते हैं।
यह एक बहुत पुराना वर्ग है, यह अभी भी C ++ 98 में है।
इसमें कोई जटिल तर्क नहीं है, इसलिए
मैं चाहूंगा कि उसकी परिभाषा कुछ इस तरह दिखे।
यह, मेरे दृष्टिकोण से, इस पर लगभग समाप्त होना चाहिए:

 template<typename F, typename S> struct pair { F f; S s; ... }; 

लेकिन, cppreference के अनुसार, डिजाइनरों pair एक pair केवल 8 टुकड़े होते हैं।
और यदि आप वास्तविक कार्यान्वयन को देखते हैं, उदाहरण के लिए, माइक्रोसॉफ्ट एसटीएल में, तो pair वर्ग के 15 निर्माता के रूप में कई होंगे। हम इस सारी शक्ति को नहीं देखेंगे और अपने आप को डिफ़ॉल्ट कंस्ट्रक्टर तक सीमित रखेंगे।

ऐसा लगेगा कि यह कुछ जटिल है? शुरुआत करने के लिए, हम समझते हैं कि इसकी आवश्यकता क्यों है। हम चाहते हैं कि अगर pair वर्ग का एक तर्क एक तुच्छ प्रकार का था, int कहना है, तो pair वर्ग के निर्माण के बाद इसे शून्य पर आरंभीकृत किया गया था, और यह एकतरफा नहीं रहा। ऐसा करने के लिए, हम एक निर्माता लिखना चाहते हैं जो फ़ील्ड f (प्रथम) और s (दूसरा) के लिए मूल्य-आरंभीकरण कहता है।

 template<typename F, typename S> struct pair { F f; S s; pair() : f() , s() {} }; 

दुर्भाग्य से, अगर हम किसी ऐसी चीज से एक pair को तुरंत बनाने की कोशिश करते हैं जिसमें डिफ़ॉल्ट निर्माता नहीं है, तो कहें, ऐसी कक्षा से हमें तुरंत संकलन त्रुटि मिलती है। वांछित व्यवहार यह है कि यदि आप एक pair बनाने की कोशिश करते हैं, तो डिफ़ॉल्ट एक संकलन त्रुटि होगी, लेकिन अगर हम स्पष्ट रूप से f और s के मूल्यों को पास करते हैं, तो सब कुछ काम करेगा:

 struct A { A(int); }; pair<int, A> a2; // must fail pair<int, A> a1; { 1, 2 }; // must be OK 

ऐसा करने के लिए, डिफ़ॉल्ट निर्माता को एक टेम्प्लेट बनाएं और इसे SFINAE तक सीमित करें।
पहला विचार जो मन में आता है वह लिखते हैं ताकि इस निर्माता को केवल तभी अनुमति दी जाए जब f और s is_default_constructable :

 template<typename F, typename S> struct pair { F f; S s; template<typename = enable_if_t<conjunction_v< is_default_constructible<F>, // not dependent is_default_constructible<S> >>> pair() : f(), s() {} }; 

यह काम नहीं करेगा, क्योंकि enable_if_t तर्क केवल कक्षा के टेम्पलेट मापदंडों पर निर्भर करता है। यही है, वर्ग के प्रतिस्थापन के बाद, वे स्वतंत्र हो जाते हैं, उन्हें तुरंत गणना की जा सकती है। लेकिन अगर हम क्रमशः false हो जाते हैं, तो हमें फिर से कठिन संकलक त्रुटि मिलती है।

इसे दूर करने के लिए, आइए इस कंस्ट्रक्टर में अधिक टेम्प्लेट पैरामीटर जोड़ें और इन टेम्प्लेट पैरामीटर्स पर enable_if_t को कंडीशन करें:

 template<typename F, typename S> struct pair { F f; S s; template<typename T = F, typename U = S, typename = enable_if_t<conjunction_v< is_default_constructible<T>, is_default_constructible<U> >>> pair() : f(), s() {} }; 

स्थिति काफी मजेदार है। तथ्य यह है कि टेम्पलेट पैरामीटर T और U उपयोगकर्ता द्वारा स्पष्ट रूप से सेट नहीं किए जा सकते हैं। C ++ में, कंस्ट्रक्टर के टेम्प्लेट मापदंडों को स्पष्ट रूप से सेट करने के लिए कोई सिंटैक्स नहीं है, वे संकलक द्वारा आउटपुट नहीं किया जा सकता है, क्योंकि इसमें उन्हें प्रदर्शित करने के लिए कहीं नहीं है। वे केवल डिफ़ॉल्ट मान से आ सकते हैं। यही है, प्रभावी रूप से यह कोड पिछले उदाहरण में कोड से अलग नहीं है। हालांकि, संकलक के दृष्टिकोण से, यह मान्य है, लेकिन पिछले उदाहरण में नहीं।

हमने अपनी पहली समस्या को हल किया, लेकिन हम एक दूसरे के साथ सामना कर रहे हैं, थोड़ा और सूक्ष्म। मान लें कि हमारे पास एक स्पष्ट डिफ़ॉल्ट कंस्ट्रक्टर के साथ वर्ग B , और हम pair<int, B> बनाना चाहते हैं pair<int, B> :

 struct B { explicit B(); }; pair<int, B> p = {}; 

हम इसे कर सकते हैं, लेकिन, मानक के अनुसार, इसे काम नहीं करना चाहिए। मानक रूप से, एक जोड़ी का निर्माण किया जाना चाहिए डिफ़ॉल्ट रूप से केवल तभी निर्माण किया जा सकता है जब उसके दोनों तत्वों का निर्माण होने के लिए डिफ़ॉल्ट रूप से डिफ़ॉल्ट रूप से निर्माण किया जाए।

प्रश्न: क्या हमें स्पष्ट जोड़ी के निर्माता को लिखने की आवश्यकता है या नहीं? सी ++ 17 में, हमारे पास एक सोलोमन समाधान है: आइए ऐसे और ऐसे दोनों को लिखें।

 template<typename F, typename S> struct pair { F f; S s; template<typename T = F, typename U = S, typename = enable_if_t<conjunction_v< is_default_constructible<T>, is_default_constructible<U>, is_implicity_default_constructible<T>, is_implicity_default_constructible<U> >>> pair() : f(), s() {} template<...> explicit pair() : f(), s() {} }; 

अब हमारे पास दो डिफ़ॉल्ट निर्माता हैं:

• जब तत्व मूल रूप से डिफ़ॉल्ट रूप से निर्माण योग्य होते हैं तो हम उस मामले के लिए SFINAE के अनुसार उनमें से एक को काट देंगे;
• और विपरीत मामले के लिए दूसरा।

वैसे, C ++ 17 में टाइप विशेषता को लागू करने के लिए is_implicitly_default_constructible है, मैं इस तरह के समाधान को जानता हूं, लेकिन मैं SFINAE के बिना समाधान नहीं जानता:

 template<typrname T> true_type test(T, int); template<typrname T> false_type test(int, ...); template<typrname T> using is_implicity_default_constructible = decltype(test<T>({}, 0)); 

यदि हम अब pair <int, B> बनाने pair <int, B> कोशिश करते हैं pair <int, B> , तो हमें एक संकलन त्रुटि मिलती है, जैसा कि हम चाहते थे:

 template<..., typename = enable_if_t<conjuction_v< is_default_constructible<T>, is_default_constructible<U>, is_implicity_default_constructible<T>, is_implicity_default_constructible<U> >>> ... pair<int, B> p = {}; ... candidate template ignored: requirement 'conjunction_v< is_default_constructible<int>, is_default_constructible<B>, is_implicity_default_constructible<int>, is_implicity_default_constructible<B> >' was not satisfied [with T=int, U=B] 

अलग-अलग कंपाइलरों में, यह त्रुटि अलग-अलग डिग्री की समझदारी की होगी। उदाहरण के लिए, इस मामले में Microsoft कंपाइलर कहता है: "खाली पेट ब्रैकेट से एक जोड़ी <int, B> संभव नहीं था।" जीसीसी और क्लैंग इसे जोड़ेंगे: "हमने इस तरह के और इस तरह के एक निर्माता की कोशिश की, उनमें से एक नहीं आया," और वे प्रत्येक के बारे में एक कारण कहेंगे।

हमारे यहां कौन से डिजाइनर हैं? कॉपी और मूव कंपाइलर द्वारा निर्मित कंस्ट्रक्टर हैं, कुछ हमारे द्वारा लिखे गए हैं। प्रतिलिपि और चाल के साथ, सब कुछ सरल है: वे एक पैरामीटर की उम्मीद करते हैं, हम शून्य पास करते हैं। हमारे निर्माता के लिए, कारण यह है कि प्रतिस्थापन फ्लॉपी है।

जीसीसी का कहना है: "प्रतिस्थापन विफल हो गया, enable_if<false> अंदर के प्रकार को खोजने की कोशिश की - खेद नहीं मिला।"

क्लैंग इस स्थिति को एक विशेष मामला मानते हैं। इसलिए, वह बहुत ही शांत इस त्रुटि को दर्शाता है। यदि हम पहले तर्क के enable_if मूल्यांकन false समय false हो enable_if हैं, तो वह लिखता है कि विशिष्ट आवश्यकता संतुष्ट नहीं है।

उसी समय, हम खुद को बोझिल स्थिति को enable_if करके अपना जीवन enable_if । हम देखते हैं कि यह false निकला, लेकिन हम अभी तक नहीं देखते हैं।

अगर हम इस तरह से चार में enable_if को तोड़ते हैं तो इसे दूर किया जा सकता है:

 template<..., typename = enable_if_t<is_default_constructible<T>::value>>, typename = enable_if_t<is_default_constructible<U>::value>>, typename = enable_if_t<is_implicity_default_constructible<T>::value>>, typename = enable_if_t<is_implicity_default_constructible<U>::value>> > ... 

अब, जब हम एक जोड़ी का निर्माण करने का प्रयास करते हैं, तो हमें एक उत्कृष्ट संदेश मिलता है कि ऐसा कोई उम्मीदवार उपयुक्त नहीं है, क्योंकि प्रकार विशेषता is_implicitly_default_constructable संतुष्ट नहीं है:

 pair<int, B> p = {}; // candidate template ignored: requirement 'is_implicity_default_constructible<B>::value' was not satisfied with... 

यह एक दूसरे के लिए भी लग सकता है: अगर हमारे पास इतना अच्छा कंपाइलर है तो हमें एक अवधारणा की आवश्यकता क्यों है?
लेकिन फिर हम याद करते हैं कि कंस्ट्रक्टर को लागू करने के लिए डिफ़ॉल्ट रूप से दो टेम्पलेट फ़ंक्शन का उपयोग किया जाता है, और प्रत्येक टेम्पलेट में छह टेम्पलेट पैरामीटर होते हैं। शक्तिशाली होने का दावा करने वाली भाषा के लिए, यह एक हलचल है।

C ++ 20 हमें कैसे मदद करेगा? सबसे पहले, इसे क्लॉज की आवश्यकता के साथ फिर से लिखकर पैटर्न से छुटकारा पाएं। हमने पहले enable_if अंदर क्या लिखा था, अब हम क्लॉज तर्क की आवश्यकता के अंदर लिखते हैं:

 template<typename F, typename S> struct pair { F f; S s; pair() requires DefaultConstructible<F> && DefaultConstructible<S> && ImplicitlyDefaultConstructible<F> && ImplicitlyDefaultConstructible<S> : f(), s() {} explicit pair() ... }; 

ImplicitlyDefaultConstructible की अवधारणा को ऐसी अच्छी आवश्यकता का उपयोग करके लागू किया जा सकता है जिसमें अभिव्यक्ति की आवश्यकता होती है, जिसके अंदर लगभग विभिन्न आकारों के केवल कोष्ठक का उपयोग किया जाता है:

 template<typename T> concept ImplicitlyDefaultConstructible = requires { [] (T) {} ({}); }; 

T ImplicitlyDefaultConstructible , , T . , , SFINAE.

C++20: (conditional) explicit ( noexcept ). explicit . , explicit .

 template<typename F, typename S> struct pair { F f; S s; explicit(!ImplicityDefaultConstructible<F> || !ImplicityDefaultConstructible<S>) pair() requires DefaultConstructible<F> && DefaultConstructible<S> : f(), s() {} }; 

, . , DefaultConstructible , explicit , explicit .

Optional C++17

Optional . , .

. ? , C++ :

 enum Option<T> { None, Some(t) } 

:

 class Optional<T> { final T value; Optional() {this.value = null; } Optional(T value) {this.value = value; } } 

C++: null , value-?

C++ . initialized storage , , . T , optional T , C++ memory model.

 template<typename T> class optional { bool initialized; aligned_storage_t<sizeof(T), alignof(T)> storage; ... 

, . : optional , optional . :

  ... T & get() & { return reinterpret_cast<T &>(storage); } T const & get() const & { return reinterpret_cast<T const &>(storage); } T && get() && { return move(get()); } optional() noexcept : initialized(false) {} optional(T const & value) noexcept(NothrowCopyConstructible<T>) : initialized(true) { new (&storage) T(value); } ~optional() : noexcept(NothrowDestructible<T>) { if (initialized) get().~T(); } }; 

optional ' . optional , optional , , optional . , copy move .

. : assignment . , . . copy constructor. :

 template<typename T> class optional { bool initialized; aligned_storage_t<sizeof(T), alignof(T)> storage; ... optional(optional const & other) noexcept(NothrowCopyConstructible<T>) : initialized(other.initialized) { if (initialized) new (&storage) T(other.get()); } optional& operator =(optional && other) noexcept(...) {...} }; 

move assignment. , :

• optional ' , .
• , .
• , — , , .

T : move constructor, move assignment :

 optional& operator =(optional && other) noexcept(...) { if (initialized) { if (other.initialized) { get() = move(other.get()); } else { initialized = false; other.initilized = true; new(&other.storage) T(move(get())); get().~T(); } } else if (other.initialized) { initialized = true; other.initialized = false; new(&storage) T(move(get())); other.get().~T(); } return *this; } 

noexcept :

 optional& operator =(optional && other) noexcept(NothrowAssignable<T> && NothrowMoveConstructible<T> && NothrowDestructible<T>) { if (initialized) { if (other.initialized) { get() = move(other.get()); } else { initialized = false; other.initialized = true; new (&other.storage) T(move(get())); get().~T(); } } ... } 

optional :

 template<typename T> class optional { ... optional(optional const &) noexcept(NothrowCopyConstructible<T>); optional(optional &&) noexcept(NothrowMoveConstructible<T>); optional& operator =(optional const &) noexcept(...); optional& operator =(optional &&) noexcept(...); }; 

, pair :
Optional -, (, deleted), compilation error.

 template class optional<unique_ptr<int>>; // compilation error 

, optional unique_ptr ,
copy constructor copy assignment deleted. , , SFINAE.
copy move assignment , — . - , copy , .

— . copy : deleted operation , , operation:

• deleted_copy_construct delete , — default ;
• copy_construct , copy_construct .

 template<class Base> struct deleted_copy_construct : Base { deleted_copy_construct(deleted_copy_construct const &) = delete; deleted_copy_construct(deleted_copy_construct &&) = default; deleted_copy_construct& operator =(deleted_copy_construct const &) = default; deleted_copy_construct& operator =(deleted_copy_construct &&) = default; }; template<class Base> struct copy_construct : Base { copy_construct(copy_construct const & other) noexcept(noexcept(Base::construct(other))) { Base::construct(other); } copy_construct(copy_construct &&) = default; copy_construct& operator =(copy_construct const &) = default; copy_construct& operator =(copy_construct &&) = default; }; 

select_copy_construct , , CopyConstrictuble , copy_construct , deleted_copy_construct :

 template<typename T, class Base> using select_copy_construct = conditional_t<CopyConstructible<T> copy_construct<Base> deleted_copy_construct<Base> >; 

, optional , optional_base , copy construct , optional
select_copy_construct<T, optional_base<T>> . copy :

 template<typename T> class optional_base { ... void construct(optional_base const & other) noexcept(NothrowCopyConstructible<T>) { if ((initialized = other.initialized)) new (&storage) t(other.get()); } }; template<typename T> class optional : select_copy_construct<T, optional_base<T>> { ... }; 

. , , copy_construct , move_construct copy_construct , copy_assign , , move_construct , , , :

 template<typename T, class Base> using select_move_construct = select_copy_construct<T, conditional_t<MoveConstructible<T>, move_construct<Base> > >; template<typename T, class Base> using select_copy_assign = select_move_construct<T, conditional_t<CopyAssignable<T> && CopyConstructible<T>, copy_assign<Base> delete_copy_assign<Base> > >; 

, move_assign copy_assign , optional_base , assignment construct assign , optional select_move_assign<T, optional_base<T>> .

 template<typename T, class Base> using select_move_assign = select_copy_assign<T, ...>; template<typename T> class optional_base { ... void construct(optional_base const&) noexcept(NothrowCopyConstructible<T>); void construct(optional_base &&) noexcept(NothrowMoveConstructible<T>); optional_base& assign(optional_base &&) noexcept(...); optional_base& assign(optional_base const &) noexcept(...); }; template<typename T> class optional : select_move_assign<T, optional_base<T>> { ... }; 

, :
optional<unique_ptr> deleted_copy_construct ,
move_construct . !

 optional<unique_ptr<int>> : deleted_copy_construct<...> : move_construct<...> : deleted_copy_assign<...> : move_assign<...> : optional_base<unique_ptr<int>> 

: optional TriviallyCopyable TriviallyCopyable .

TriviallyCopyable ? , T TriviallyCopyable ,
memcpy . , .

, , , . resize vector TriviallyCopyable , memcpy , , . , , .

TriviallyCopyable , , static_assert ', copy-move :

 template<typename T> class optional : select_move_assign<T, optional_base<T>> {...}; static_assert(TriviallyCopyable<optional<int>>); static_assert(TriviallyCopyConstructible<optional<int>>); static_assert(TriviallyMoveConstructible<optional<int>>); static_assert(TriviallyCopyAssignable <optional<int>>); static_assert(TriviallyMoveAssignable <optional<int>>); static_assert(TriviallyDestructible <optional<int>>); 

static_assert ' . , , . optional — aligned_storage , , , , TriviallyCopyable .

, . , TriviallyCopyable .

, . select_copy_construct :

 template<typename T, class Base> using select_copy_construct = conditional_t<CopyConstructible<T>, copy_construct<Base> deleted_copy_construct<Base> >; 

CopyContructible copy_construct , if compile-time: CopyContructible TriviallyCopyContructible , Base .

 template<typename T, class Base> using select_copy_construct = conditional_t<CopyConstructible<T>, conditional_t<TriviallyCopyConstructible<T>, Base, copy_construct<Base> >, deleted_copy_construct<Base> >; 

, copy . , select_destruct . int , - - , .

 template<typename T, class Base> using select_destruct = conditional_t<TriviallyDenstructible<T>, Base, destruct<Base> > >; 

, , . , , :

 optional<unique_ptr<int>> : deleted_copy_construct<...> : move_construct<...> : deleted_copy_assign<...> : move_assign<...> : destruct<optional_base<unique_ptr<int>>> : optional_base<unique_ptr<int>> 

, C++17 optional 7; : operation , deleted_operation select_operation ; construct assign . , .

- . . : deleted.

, noexcept .
, , , trivial , noexcept . , , trivial noexcept , noexcept , deleted . . , , .

type trait, , . , , copy : deleted , nothrow , ?

, - special member, , , , :

• , deleted , = delete deleted_copy_construct ;
• , copy_construct , c noexcept ;
• , , , .

.

optional C++20

C++20 optional copy ?
:

• T CopyConstructible , deleted ;
• TriviallyCopyConstructible , ;
• noexcept .

 template<typename T> class optional { ... optional(optional const &) requires(!CopyConstructible<T>) = delete; // #1 optional(optional const &) requires(TriviallyCopyConstructible<T>) = default; // #2 optional(optional const &) noexcept(NothrowCopyConstructible<T>) {...} // #3 ... ~optional() requires(TriviallyDestructible<T>) = default; ~optional() noexcept(NothroeDestructible<T>) {...} }; 

, . -, , T requires clause false . requires(false) , , overload resolution. , requires(true) , .
, .

requires clause = delete :

• = delete overload resolution, , , deleted .
• requires(false) overload resolution.

, copy , , requires clause. .

, . ! C++ , ? , , . , , , . , , , , , optional .

, , GCC internal compiler error, Clang . , . , .

, , optional C++20. , , C++17.

aligned_storage aligned_union

: aligned_storage reinterpret_cast , reinterpret_cast constexpr . , compile-time optional , compile-time. STL aligned_storage optional aligned_union variant . , , STL Boost optional variant . variant , :

 template<bool all_types_are_trivially_destructible, typename...> class _Variant_storage_; template<typename... _Types> using _Variant_storage = _Variant_storage_< conjunction_v<is_trivially_destructible<_Types>...>, _Types... >; template<typename _First, typename... _Rest> class _Variant_storage_<true, _First, _Rest...> { union { remove_const_t<First> _Head; _Variant_storage<_Rest...> _Tail; }; }; 

variant . _Variant_storage_ , , -, , variant , -, . , trivially_destructible ? type alias, . _Variant_storage_ , true false . , true , . trivially_destructible , union Variant ' .

, , , , . type alias _Variant_storage . :

 template<typename... _Types, bool = conjunction_v<is_trivially_destructible<_Types>...> > class _Variant_storage_; 

. , variadic template . , , , _Types . C++17 , .

C++20 ,
,
requires clause. C++20 requires clause:

 template<typename... _Types> class _Variant_storage_; template<typename _First, typename... _Rest> requires(TriviallyDestructible<_First> && ... && TriviallyDestuctible<_Rest>) class _Variant_storage_<_First, _Rest...> { union { remove_const_t<_First> _Head; _Variant_storage_<_Rest...> _Tail }; }; 

_Variant_storage_ , TriviallyDestructible . , requires clause , , .

requires clause template type alias

, requires clause template type alias. C++20 - enable_if , :

 template<bool condition, typename T = void> requires condition using enable_if_t = T; 

,

, . :

 // Equivalent, but functionally not equivalent template<typename T> enable_if_t<(sizeof(T) < 239)> f(); template<typename T> enable_if_t<(sizeof(T) > 239)> f(); // Not equivalent template<typename T> requires(sizeof(T) < 239) void f(); template<typename T> requires(sizeof(T) > 239) void f(); 

, enable_if . ? f() : enable_if , , 239, , , , 239. , :

• , , template type alias', «void f(); void f();
• , SFINAE, , , .

, enable_if , , size < 239 , size > 239 . , . , f() . requires clause. — , .

— , . C++ Russia 2019 Piter, «: core language» . , , : reachable entity visible, ADL, entities internal linkage . , C++ Russia (JetBrains) « ++20 — ?»