प्राग में दूसरे दिन, अंतर्राष्ट्रीय मानकीकरण समिति C ++ की बैठक हुई। और-और-और ...
C ++ 20 तैयार है! यह आईएसओ से एक मुहर लगाने के लिए बनी हुई है, लेकिन यह एक शुद्ध रूप से औपचारिक कदम है जिसके साथ कोई समस्या नहीं होनी चाहिए।इस अद्भुत घटना पर सभी को बधाई! कॉन्सेप्ट, कोराटाइन्स, मॉड्यूल्स, रेंज, एसटीडी :: फॉर्मेट, कॉन्स्ट्रेक न्यू और कॉन्स्ट्रेक्प एल्गोरिदम + वेक्टर + स्ट्रिंग, डेटाइम, जेथ्रेड, स्पैन, बिट_कास्ट और कई अन्य छोटे और बड़े इनोवेशन।अंतिम क्षण में वे क्या जोड़ने और ठीक करने में कामयाब रहे, उन्होंने क्या तोड़ना प्रस्तावित किया और हर कोई C ++ 23 में देखना चाहता है - कट के तहत इस सब के बारे में।C से C ++ 20 तक की ट्रिक्स
हाल ही में, C ++ में अपरिभाषित व्यवहार (UB) के साथ नौसिखिया डेवलपर्स को डराने की परंपरा रही है। इसे बदलने का समय आ गया है!यहाँ, उदाहरण के लिए, ऐसा कोड C के लिए बिल्कुल मान्य है:struct X { int a, b; };
X *make_x() {
X *p = (X*)malloc(sizeof(struct X));
p->a = 1;
p->b = 2;
return p;
}
लेकिन C ++ में इसके साथ बड़ी समस्याएं थीं। C बाइट्स के साथ काम करता है, और C ++ ऑब्जेक्ट्स के साथ काम करता है। लेकिन ऑब्जेक्ट का जीवनकाल होता है, और C ++ 20 से पहले, ऑब्जेक्ट के लिए जीवन की शुरुआत को कॉल नए से माना जाता था।समिति गंभीरता से बाइट्स और सरल संरचनाओं के साथ निम्न स्तर के काम के बारे में चिंतित है। उन्होंने उन सुधारों को अपनाया जो कहते हैं कि कार्यों का एक निश्चित सेट (मेमकी, मेमोव, मॉलोक, एलाइन_लोक, कॉलोक, रियललॉक, बिट_कास्ट) वस्तु के जीवनकाल की शुरुआत करता है। अब अधिकांश निम्न-स्तरीय सी-ट्रिक C ++ में काम करने की गारंटी हैं।C ++ 20 में बूल अधिक विश्वसनीय हो गया है
अनुमान करें कि त्रुटि क्या है:template <typename T, size_t N>
auto count_unique(const std::array<T, N>& v) {
return std::unordered_set<T>{v.begin(), v.end()}.size();
}
उत्तरT bool v.begin() v.end() (, libc++ libstdc++) — count_unique 1.
- , std::unordered_set<bool>{v.begin(), v.end()} bool std::unordered_set<bool>{true, true}.
बूल में रूपांतरण अब संकीर्ण परिवर्तन माना जाता है। इससे हमें कई कोडबेस ( P1957 वाक्य में अधिक उदाहरण) में समस्याओं का पता लगाने की अनुमति मिली ।C ++ 20 अवधारणाएं तेजी से बनीं
कुछ समय पहले तक, आप इस तरह की अवधारणा लिख सकते थे:template <class T>
concept Reservable = requires(T v) {
v.reserve(int{});
};
और आश्चर्य है कि यह अलग परिणाम देता है:struct Test;
static_assert(!Reservable<Test>);
struct Test {
void reserve(int);
};
static_assert(Reservable<Test>);
पिछली बार, हमने देश से एक टिप्पणी भेजी थी: "अवधारणाओं में अपूर्ण प्रकार का उपयोग करना असंभव है, क्योंकि अन्यथा आपको कई ओडीआर उल्लंघन मिलते हैं"। हमारी टिप्पणी को अस्वीकार कर दिया गया था, लेकिन हमें आंशिक रूप से प्रस्ताव पी 2104 के साथ अब वांछित परिणाम मिला है।एक बोनस के रूप में, हम तेजी से संकलन प्राप्त करते हैं, क्योंकि संकलक अब अवधारणाओं को प्रकारों पर लागू करने के परिणामों को कैश करने के हकदार हैं।C ++ 20 में मामूली संपादन
- रेंजों को ssize विधि मिली।
- मॉड्यूल आंतरिक लिंकेज अब दिखाई नहीं दे रहे हैं जब इंस्टेंटेटिंग मॉड्यूल लिंकेज इकाइयां (कंपाइलर आपको बताएगा कि कंपार्टमेंट स्टेज में क्या गलत है)।
- हमने मॉड्यूल के लिए नियमों को मोड़ दिया ताकि किसी भी उपकरण के लिए उनके साथ काम करना आसान हो सके।
और चलो C ++ 23 या C ++ 26 में सब कुछ तोड़ दें?
लंबे समय तक बहस ने एक आवेदन बाइनरी इंटरफेस (एबीआई, एपीआई के साथ भ्रमित न करें) के लिए एक प्रस्ताव दिया है । दिलचस्प सवाल उठाए गए थे:1. हम C ++ 23 में ABI को पूरी तरह से बदल सकते हैं और 5-10% प्रदर्शन लाभ प्राप्त कर सकते हैं।
इसके अलावा, सभी पुराने C ++ पुस्तकालयों का पुनर्निर्माण करना होगा, वे नए ABI के साथ पुस्तकालयों से लिंक नहीं कर पाएंगे। आप C ++ 23 प्रोजेक्ट में C ++ के पुराने संस्करणों द्वारा निर्मित लाइब्रेरी का उपयोग नहीं कर सकते।खैर, निश्चित रूप से, हमेशा पुराने वाणिज्यिक सॉफ़्टवेयर होंगे जो कोई भी फिर से इकट्ठा नहीं करेगा, लेकिन वह अपने मानक पुस्तकालय को खींचेगा (हाँ, वीडियो गेम, मैं आपके बारे में बात कर रहा हूं!)।वोट के मामूली अंतर के साथ, ABI ने C ++ 23 में नहीं टूटने का फैसला किया।2. चलो उपयोगकर्ताओं को एक गारंटी देते हैं कि हम एबीआई को तोड़ने / बदलने की कोशिश नहीं करेंगे।
और फिर उन्होंने गारंटी नहीं देने का फैसला किया। विभिन्न विक्रेताओं के पास अपने प्लेटफार्मों के लिए अलग-अलग योजनाएं हैं, और कभी-कभी वे एबीआई को तोड़ने का जोखिम उठा सकते हैं, अक्सर उपयोगकर्ताओं को नुकसान पहुंचाए बिना।और चलो हर जगह noexcept जोड़ते हैं?
ऐतिहासिक रूप से, पूर्व-कार्यों के साथ मानक कार्यों में noexcept के रूप में चिह्नित नहीं किया जाता है, भले ही वे अपवादों को कभी नहीं फेंकते। यहाँ, उदाहरण के लिए, ऑपरेटर -> में std :: वैकल्पिक है:constexpr const T* operator->() const;
constexpr T* operator->();
Requires: *this contains a value.
Returns: val.
Throws: Nothing.
वह कुछ भी नहीं फेंकता है, लेकिन इसे शब्दों के बजाय यह कहता है कि "फेंकता: कुछ भी नहीं", क्योंकि एक पूर्व शर्त है "* इसमें एक मूल्य शामिल है"।Noexcept वाले उपयोगकर्ता स्पष्ट होंगे। P1656 में एक अच्छा विचार !
नहीं!एक संपूर्ण उपसमूह SG21 है: संविदा, जो संविदा की जांच (पूर्व और पोस्टकंडिशन) के लिए एक सामान्य तंत्र के साथ आता है। अनुबंध हैंडलर एक अपवाद फेंक सकते हैं, अगर कोई अपवाद noexcept फ़ंक्शन से फेंका गया है, तो यह std :: समाप्त हो जाएगा और एप्लिकेशन क्रैश हो जाएगा। यदि आप एक विशेष बैसाखी डालते हैं कि अनुबंधों के लिए अपवाद एक noexcept फ़ंक्शन से बाहर निकल सकते हैं ... तो वैसे भी सब कुछ टूट जाता है, टाइप लक्षण noexcept की उपस्थिति द्वारा निर्देशित होते हैं, और वे आपसे झूठ बोलना शुरू करते हैं, एक पूर्वानुभव के साथ noexcept के साथ चिह्नित फ़ंक्शन अपवाद को फेंक देगा।लेकिन यह सबसे बड़ी समस्या नहीं है। मानक पुस्तकालयों के कांटे हैं, जो पहले से ही अब कुछ मामलों में स्पष्ट रूप से पूर्व शर्त चेक सम्मिलित करते हैं। उदाहरण के लिए, क्या आपके पास एक महत्वपूर्ण परियोजना है, जिसकी उपलब्धता अधिकतम होनी चाहिए। आप एक समान कांटा का उपयोग करते हैं, और अगर किसी को अचानक खाली वेक्टर के लिए std :: वेक्टर :: बैक () कहा जाता है, तो एक अपवाद फेंकता है, जो कोड में उच्च संसाधित होता है और फ़ॉलबैक का उपयोग किया जाने लगता है। P1656 से संपादन के साथ , इस तरह के पुस्तकालय को अब मानक नहीं माना जा सकता है।और यह सभी समस्याएं नहीं हैं! .. न केवल मानक पुस्तकालय के लिए अतिरिक्त noexcept बाइनरी फ़ाइलों या अधिक प्रदर्शन के आकार में कमी के रूप में कोई सकारात्मक प्रभाव लाएगा, न केवल परिवर्तन कम से कम दो कंपनियों के कोड को तोड़ देगा, न केवल यह एक तरीके को नष्ट कर देगा। अनुबंधों का उपयोग ... इसलिए भी प्रस्ताव दो उपसमूहों में अनुमोदित किया गया था।RG21 के गुण
हमेशा की तरह, हमने विभिन्न उपसमूहों में काम किया, कार्यान्वयन अनुभव साझा किया, प्रस्ताव प्रस्तुत किए, जिनमें से लेखक नहीं आ सके।उन उत्कृष्ट विचारों में से एक, जिन्हें हम प्रस्तुत करने के लिए भाग्यशाली थे, एंटोन ज़ीलिन P2025 नाम वापसी वस्तुओं के लिए गारंटी नकल के विचार थे । इसके कार्यान्वयन से कॉपी के बिना ऑब्जेक्ट के लिए फ़ैक्टरी फ़ंक्शन बनाने और निर्माणकर्ताओं को स्थानांतरित करने की अनुमति मिलेगी। वास्तव में, यह एक विनाशकारी चाल है, जो 90 के दशक के मध्य से गुप्त रूप से मानक में मौजूद है और विशेष रूप से व्यक्तिगत भाषा नियमों द्वारा निषिद्ध है।हमने लेखक द्वारा स्वयं विचार के उत्कृष्ट विस्तार के लिए EWG-I और EWG उदाहरणों के माध्यम से विचार को सफलतापूर्वक खींच लिया। CWG चरण बना रहा, और कुछ बैठकों के बाद मानक में आवश्यक शब्दों को देखने का पूरा मौका है, और संकलक में पहला कार्यान्वयन है।इस विचार के अलावा, हमने P1990R0 के विचार को खींच लिया : ऑपरेटर जोड़ें [] std :: LEASG-I के माध्यम से initializer_list , P1944R0: constexpr <cstring> और <cwchar> पर एक उपयोगी प्रतिक्रिया मिली । डेनियल गोंचारोव के दोनों विचारों को C ++ 23 में होने का हर मौका है।Std :: हैश के क्षेत्र में, एक अप्रत्याशित विफलता ने हमारा इंतजार किया। P1406r1 की चर्चा : अधिक एसटीडी जोड़ें: हैश विशेषज्ञता अचानक पतित सीमा मामलों और दूर C ++ 2 * की संभावनाओं की चर्चा में बदल गई। नतीजतन, समिति ने कुछ भी नहीं बदलने का फैसला किया।SG6 और नंबर के साथ एक साथ नहीं बढ़े। SG6 की मुख्य चर्चाएँ ABI की चर्चाओं से मेल खाती हैं, यही वजह है कि SG6 में कोरम जमा नहीं हुआ। इस p1889 की वजह से : C ++ न्यूमेरिक्स वर्क इन प्रोग्रेस , P2010: P1889 से iostream ऑपरेटर्स निकालें औरP1890: C ++ न्यूमेरिक्स वर्क इन प्रोग्रेस इश्यूज पर चर्चा नहीं की गई।सी ++ 23 योजनाएं
सी ++ 20 के विकास की शुरुआत के बाद से, समिति ने योजना के अनुसार कार्य करना शुरू किया। अर्थात्, अगले मानक के लिए कई प्रमुख दिलचस्प विचारों की पहचान करना, जिसके बाद बाद की सभी बैठकों में अन्य विषयों पर प्रस्तावों पर विचार नहीं करना है, अगर सभी पर मुख्य चर्चा नहीं की गई है।C ++ 23 के लिए, ऐसी योजना को प्राग में अनुमोदित किया गया था। C ++ 23 की मुख्य प्राथमिकताएं:- मानक पुस्तकालय में Corutin समर्थन करते हैं
- मानक पुस्तकालय को मॉड्यूल में बदलें
- निष्पादकों
- नेटवर्किंग
पहले पैराग्राफ में, सभी को कैप्पोरो लाइब्रेरी द्वारा निर्देशित किया जाएगा । इसलिए यदि आप पहले से ही C ++ 20 कोरआउट का उपयोग करना चाहते हैं, तो आपको इस लाइब्रेरी का उपयोग करके शुरू करना चाहिए।मॉड्यूल के साथ, दूसरा बिंदु, आपको बस नीचे बैठने और इसे करने की आवश्यकता है, कोई विशेष कठिनाइयों की उम्मीद नहीं है।लेकिन एक्जिक्यूटर्स एक समस्या है। उनका डिज़ाइन स्पष्ट नहीं है, सभी उपयोगकर्ता मामलों को कवर नहीं किया गया है, उनके वर्तमान रूप में वे किसी के द्वारा उपयोग नहीं किए गए थे, और डिज़ाइन अभी भी स्वीकृत नहीं है।समिति निम्नलिखित क्षेत्रों में प्रस्तावों को प्राथमिकता देने पर भी सहमत हुई:- प्रतिबिंब
- पैटर्न मिलान
- ठेके
योग के बजाय
C ++ 20 तैयार है, यह C ++ 23 पर काम करने का समय है! अगली समिति की बैठक गर्मियों में होगी, इसलिए यदि आपके पास नए मानक का एक अच्छा विचार है - तो उन्हें stdcpp.ru और टेलीग्राम-चैटिंग प्रोक्सएक्सएक्स पर साझा करें ।खैर, हर कोई जो समिति के प्रतिनिधियों के साथ चैट करना चाहता है - बैठकों और C ++ सम्मेलनों * को देखें।* जीवन हैक: यदि आप एक वक्ता हैं तो आपको सम्मेलन टिकट के लिए भुगतान करने की आवश्यकता नहीं है।