ड्राफ्ट FAQ: हर तीन साल में C ++ मानक क्यों निकलते हैं?

WG21 की हर तीन साल में मानक रिलीज के लिए एक सख्त अनुसूची ( P1000 देखें) है। और कोई देरी नहीं।

प्रत्येक चक्र के दौरान, हम नियमित रूप से प्रश्न पूछते हैं "यह इतना सख्त क्यों है?", विशेष रूप से समिति के नए सदस्यों से जो इसके इतिहास और चीजों की वर्तमान स्थिति के कारणों से परिचित नहीं हैं। और कोलोन प्रशासन के साथ एक प्रारंभिक टेलीकांफ्रेंस के दौरान, कई लोगों ने यह वर्णन करने की सिफारिश की कि हम ऐसा क्यों कर रहे थे और इस अनुसूची को अपनाने का निर्णय कैसे किया गया।

मैंने P1000 के अगले मसौदे के लिए सवाल और जवाब के रूप में यह सब चित्रित किया, और कोलोन के रास्ते में समिति के सदस्यों को एक प्रति भेजी। यह सामग्री P1000 के अगले सार्वजनिक संस्करण में प्रकाशित की जाएगी, हम इसे वर्तमान क्षण से शुरू होने वाले कुछ हफ्तों में भेज देंगे।

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

मानक में बग हैं, क्या आपको C ++ 20 को स्थगित करना चाहिए?

हाँ और ना।

हम एक चुने हुए गति से दिए गए दिशा में आगे बढ़ रहे हैं: इस साल के लिए बग फिक्स की योजना बनाई गई है, इसलिए C ++ "19" (कोना) के शुरुआती समय में C ++ "20" में सुविधा जोड़ (फीचर फ्रीज) को रोकने के लिए एक समय सीमा निर्धारित की गई है, ताकि इस साल गर्मियों में विभिन्न देशों की टिप्पणियों के साथ काम करने वाले कीड़े को ठीक करने के लिए हमारे पास एक साल था। 2020 की शुरुआत से पहले (कोलोन, बेलफास्ट और प्राग में बैठकें), हमें प्रतिक्रिया देनी चाहिए और समस्याओं के समाधान के साथ-साथ बग सुधार के लिए कोई अन्य समाधान लागू करना चाहिए।

यदि हमारे पास एक या दो और बैठकें हैं, तो हम एक <सुविधा नाम> जोड़ सकते हैं, जो लगभग तैयार है, तो क्या आपको + 20 + स्थगित करना चाहिए?

हाँ और ना।

कुछ और बैठकों के लिए प्रतीक्षा करें (प्राग के बाद), और C ++ 23 व्यवसाय के लिए खुला रहेगा, और सबसे पहले हम C ++ 23 के कार्य मसौदे में <सुविधा नाम> जोड़ने के लिए मतदान करेंगे। यही हमने अवधारणाओं के साथ किया: वे टीएस से सीधे सी ++ 17 में संक्रमण के लिए तैयार नहीं थे। इसलिए, C ++ 20 (टोरंटो में) पर पहली बैठक में, उन्होंने अवधारणाओं की बुनियादी कार्यक्षमता को C ++ 20 के मसौदे में स्थानांतरित करने के लिए मतदान किया, जिसने टीएस के शेष विरोधाभासी हिस्से को सुधारने और परिष्कृत करने के लिए बहुत समय दिया (गैर "टेम्पलेट" सिंटैक्स), जो पेश किया गया था। अगले साल (सैन डिएगो)। अब सारी कार्यक्षमता तैयार है।

यह बहुत सख्त प्रतीत होता है। निश्चित अंतराल (तीन साल) पर IS रिलीज क्यों जारी करता है?

क्योंकि सी ++ आईएस की रिहाई के मामले में, यह परियोजना प्रबंधन के लिए दो मुख्य विकल्पों में से एक है, और अनुभव से पता चलता है कि यह विकल्प दूसरे से बेहतर है।

C ++ IS की रिलीज़ के लिए प्रोजेक्ट प्रबंधन के लिए दो विकल्प क्या हैं?

खुशी है कि आपने पूछा।

एक रिलीज के मामले में, दो मुख्य विकल्प हैं: एक सुविधा या रिलीज की तारीख चुनें, और जब आप एक का चयन करते हैं, तो आप दूसरे की परिभाषा पर नियंत्रण खो देते हैं। आप एक साथ दोनों को नियंत्रित नहीं कर सकते। संक्षेप में:


मैं समझाता हूं:

(1) "क्या": हम तैयार के रूप में सुविधाओं और जहाज का चयन करते हैं, रिलीज के समय का चयन करने की कोई आवश्यकता नहीं है । यदि यह पता चलता है कि आपको मसौदा मानक से किसी विशेषता को अंतिम रूप देने के लिए अधिक समय की आवश्यकता है, तो पूरी दुनिया को आपके लिए इंतजार करना होगा। आप बड़ी सुविधाओं पर काम करते हैं जिनके लिए कई वर्षों के विकास की आवश्यकता होती है, और फिर आप रिलीज़ को स्थिर करते हुए नई सुविधाओं पर काम करना बंद करने की कोशिश करते हैं।

इसलिए यह C ++ 98 के साथ था (यह 1994 के आसपास की उम्मीद थी, ब्योर्न ने कहा कि यदि रिलीज नहीं हुई तो यह C ++ 11 के साथ असफल हो जाएगी) (इसे 0x कहा जाता था क्योंकि x 2007 तक अपेक्षित था। )। यह अनिश्चित काल के लिए "मरीज को बिना सोचे-समझे छोड़ दें" दृष्टिकोण है, जिसके कारण एकीकरण परीक्षण और रिलीज में देरी हुई। और इसके परिणामस्वरूप, अगले मानक के समय के बारे में बड़ी बाजार अनिश्चितता पैदा हुई, और क्या यह बिल्कुल जारी किया जाएगा (हां, न केवल विकास प्रतिभागियों, बल्कि 1996 और 2009 में समिति के कुछ सदस्यों को भी गंभीरता से संदेह दिखाई देगा। क्या कोई प्रासंगिक रिलीज़ हैं)। कई वर्षों के लिए, अधिकांश कंपाइलर्स मानक को पूरा नहीं करते थे, क्योंकि किसी को नहीं पता था कि नई रिलीज़ में समिति कितने असंगत बदलाव लाएगी, या यह सब कब होगा? इससे समुदाय के लिए उपलब्ध संकलक में व्यापक विविधता और C ++ समर्थन का विखंडन हुआ है।

हमने ऐसा क्यों किया, क्या हम बेवकूफ हैं? वास्तव में नहीं, वे सिर्फ अनुभवहीन थे और ... चलो कहते हैं, "आशावादी।" यह बेहतरीन इरादों के साथ एक सड़क थी। 1994-1996 में और 2007-2009 में हमें वास्तव में विश्वास था कि अब हम एक और एक, दो या तीन बैठकें करेंगे, और हम सब कुछ करेंगे, और हर बार उन्हें चार साल तक के लिए स्थगित कर दिया जाएगा। और अब उन्होंने अपने स्वयं के अनुभव से देखा है कि एक या दो साल तक कोई हस्तांतरण नहीं हो सकता है।

सौभाग्य से, सब कुछ विकल्प (2) के लिए धन्यवाद बदल गया है।

(2) "कब": हम रिलीज की तारीख का चयन करते हैं और तैयार की गई सुविधाओं को शिप करते हैं, आपको सुविधाओं के एक सेट का चयन करने की आवश्यकता नहीं है । यदि यह पता चलता है कि ड्राफ्ट मानक से एक सुविधा को परिष्कृत करने के लिए अधिक समय की आवश्यकता होती है, तो हम इसे त्याग देते हैं और तैयार होते हैं। आप बड़ी विशेषताओं पर काम करना जारी रख सकते हैं, जिसके निर्माण में कई रिलीज के लिए समय लगता है, लेकिन इसे तृतीय-पक्ष "शाखाओं" में करें, जैसे ही आप कर सकते हैं आईएस मास्टर शाखा में जोड़ते हैं। और आप लगातार सुविधाओं पर काम करते हैं, क्योंकि उनका विकास वर्तमान रिलीज़ से पूरी तरह से अलग है (कोई बड़ा कनेक्शन बिंदु नहीं है)।

हम 2012 से इस दृष्टिकोण का पालन कर रहे हैं और इसे छोड़ना नहीं चाहते हैं। यह "रोगी को नियमित रूप से पैचिंग" दृष्टिकोण है, जो मजबूर नियमित एकीकरण के कारण उच्च गुणवत्ता की उम्मीद की ओर जाता है और आईएस के मसौदे में काम जोड़ने से इनकार कर देता है जब तक कि यह एक निश्चित स्तर की स्थिरता तक नहीं पहुंचता है, आमतौर पर सुविधा शाखा के भीतर। यह एक पूर्वानुमानित रिलीज चक्र भी बनाता है जो बाजार पर भरोसा कर सकता है। वर्षों से, संकलक के लेखक पहले और पहले शुरू हुए, अगली रिलीज के बाद, अपने उत्पादों के संस्करणों को मानक के अनुरूप जारी करने के लिए, जो पहले कभी नहीं हुआ था। और 2020 में, हम मानक की रिहाई के साथ एक वर्ष में पूरी तरह से अनुपालन कार्यान्वयन की रिहाई की उम्मीद करते हैं, जो पहले कभी नहीं हुआ था। यह केवल पूरे बाजार के लाभ के लिए है - डेवलपर्स, उपयोगकर्ता, शिक्षक।

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

दृष्टिकोण (2) के बारे में आप कितने गंभीर हैं? यदि, समिति के एक आधिकारिक सदस्य के अनुसार, कुछ बड़ी विशेषता "लगभग तैयार" है, तो आपको थोड़ा इंतजार करने का लालच होगा, है ना?

बहुत गंभीरता से, और नहीं।

हमारे पास आंकड़े हैं: 2016 में जैक्सनविले में, जब हमने अंततः C ++ 17 के लिए सुविधाओं पर फैसला किया, तो Björn Straustrup ने C ++ 17 में अवधारणाओं को शामिल करने के प्रस्ताव के साथ एक पूर्ण बैठक में बात की। जब कोई आम सहमति नहीं बन पाई, तो स्ट्रैसेप से सीधे पूछा गया कि क्या वह इसमें अवधारणाओं को शामिल करने के लिए एक वर्ष के लिए C ++ 17 की रिहाई में देरी करना चाहता है। ब्योर्न ने बिना किसी हिचकिचाहट और चोरी के "नहीं" का जवाब दिया, और कहा कि अवधारणाओं के बिना C ++ 17 C ++ 18 या C ++ 19 की तुलना में अधिक महत्वपूर्ण था, हालांकि स्ट्रेंज़प लगभग 15 वर्षों से उन पर काम कर रहा था। पसंद यह थी: (2) हम अवधारणाओं के बिना C ++ 17 जारी करते हैं, और फिर C ++ 20 अवधारणाओं के साथ (जो हमने किया), या (1) हम C ++ 17 का नाम बदलकर C ++ 20 करते हैं, जो कि आइसोमोर्फिक (2) है। सी ++ 17 को छोड़ देने और सी ++ 17 के लिए पहले से ही तैयार होने से इनकार करने के अपवाद के साथ।

(1) और (2) के बीच व्यापार बंद के बारे में क्या? कहते हैं, हम आम तौर पर (2) का पालन करते हैं, लेकिन "थोड़ा" अतिरिक्त समय पाने के लिए "छोटे" लचीलेपन के साथ, यदि आपको सुविधा को परिष्कृत करने की आवश्यकता है?

नहीं, क्योंकि यह निकला (1)।

पौराणिक पौराणिक कथाओं में फ्रेड ब्रूक्स ने "पौराणिक छोटे से संक्रमण" को लोकप्रिय रूप से समझाया और निष्कर्ष निकाला: " किसी भी छोटे हस्तांतरण की अनुमति न दें ।"

कल्पना कीजिए कि हमने C ++ 20 को पोर्ट किया। हमें (2) से (1) तक वापस जाना होगा, चाहे हम इससे बचने की कितनी भी कोशिश कर लें, और साथ ही उसे कोई लाभ नहीं मिलेगा। अगर हमने इसे चमकाने के लिए C ++ 20 को स्थगित करने का फैसला किया, तो हम मानक को कम से कम दो साल तक रोक देंगे। एक या तीन बैठकों के हस्तांतरण के रूप में ऐसी कोई अवधारणा नहीं है, क्योंकि इस समय के दौरान अन्य लोग (काफी) कहते रहेंगे: "ठीक है, मेरी सुविधा को केवल एक और बैठक की आवश्यकता है, हमने अभी भी इसे पुनर्निर्धारित किया है, चलो एक और स्थानांतरण करें।" और अगर हम कम से कम दो साल का स्थानांतरण करते हैं, तो इसका मतलब है कि C ++ 20 C ++ 22 हो जाता है, और सबसे अधिक संभावना C ++ 23 ... लेकिन हम पहले से ही C ++ 23 को शिप करने जा रहे हैं! - अर्थात्, किसी भी मामले में, हम C ++ 23 को शिप करेंगे, और एकमात्र अंतर यह है कि हम C ++ 20 को बड़ी मात्रा में काम के साथ स्थानांतरित नहीं करते हैं, रिलीज के लिए तैयार हैं, और पूरी दुनिया को एक और तीन साल इंतजार नहीं करना है। देरी से इन सुविधाओं का लाभ नहीं होगा, उनमें से अधिकांश या सभी एक साथ।

इसलिए, वाक्य "आइए C ++ 20 को C ++ 22 या C ++ 23 में बदल दें", और इसका सरल उत्तर है: "हाँ, हमारे पास C ++ 23 होगा, लेकिन C ++ 20 के अलावा, और उसकी जगह पर नहीं। ” C ++ 20 देरी का अर्थ है एक अच्छा, स्थिर, तैयार उत्पाद जारी करने के बजाय C ++ 20 को छोड़ देना और इससे कोई लाभ नहीं होगा।

लेकिन फीचर X टूट गया है / C ++ 20 में बग्स को ठीक करने में जितना समय बचा है, उससे अधिक समय लगता है!

कोई सवाल नहीं! हम इसे काट सकते हैं।

इस मामले में, किसी को स्थिति के विवरण के साथ EWG या LEWG (स्थिति के आधार पर) में एक पत्र लिखने की आवश्यकता होगी, और काम करने वाले ड्राफ्ट IS से सुविधा को हटाने की पेशकश की जाएगी। ये समूह अपील पर विचार करेंगे, और यदि वे तय करते हैं कि फीचर टूट गया है (और प्लेनम उनसे सहमत है), तो अगले सी ++ रिलीज तक यह सुविधा स्थगित रहेगी। हमने पहले ही C ++ 0x अवधारणाओं के साथ ऐसा किया था।

लेकिन (1) के मामले में, हम न केवल इस सुविधा को स्थानांतरित करेंगे, बल्कि C ++ 20 से C ++ 23 तक सुविधाओं का पूरा सेट ! वह होगा ... बस्ट।

क्या दृष्टिकोण (2) का अर्थ "प्रमुख / लघु" है?

नहीं। पहले तो हमने यह कहा जब तक हमें एहसास नहीं हुआ कि (2) का अर्थ केवल यह है कि आपको "मुख्य / माध्यमिक" रिलीज के दृष्टिकोण से भी सुविधाओं का एक सेट चुनने की आवश्यकता नहीं है।

दृष्टिकोण (2) का अर्थ केवल "हम जो तैयार करते हैं उसे जहाज करते हैं" है। विज्ञप्ति प्राप्त की हैं:

• सुविधाओं के लिए एक ही आकार (जो आमतौर पर औसत है) "छोटा" है क्योंकि उनके विकास पर कम समय खर्च किया जाता है (जैसे, प्रत्येक तीन साल से कम), और सामान्य तौर पर हमें रिलीज़ में समान संख्या में पूर्ण सुविधाएँ मिलती हैं;
  
• और "बड़ा" सुविधाओं के लिए एक चर आकार (यह एक या दो बार आवश्यक नहीं है), जो अधिक समय लेते हैं (कहते हैं, प्रत्येक तीन साल से अधिक), और प्रत्येक आईएस रिलीज में इनमें से कई विशेषताएं शामिल हैं जैसे कि वे रिलीज के लिए पूरा करने का प्रबंधन करते हैं। इसलिए, कुछ रिलीज में अधिक हैं, दूसरों में कम।
  

C ++ 14 और C ++ 17 अपेक्षाकृत छोटे थे, क्योंकि कार्यान्वयन के प्रस्तावों (उदाहरण के लिए, अनुबंध) और TS में "सुविधा शाखाओं" (उदाहरण के लिए, अवधारणाओं) में वर्णित लंबी-चौड़ी विशेषताओं पर बहुत सारे मानकीकरण प्रयास खर्च किए गए थे।

C ++ 20 एक शानदार रिलीज है ...

हां। C ++ 20 में कई प्रमुख विशेषताएं हैं। तीन सबसे बड़े "ko" (अवधारणाएं, अनुबंध, कॉरआउट) से शुरू होते हैं, इसलिए हम इसे co_cpp20 कह सकते हैं। या सह_निर्भर।

... और C ++ 20 के लिए तीन साल के चक्र में बहुत अधिक नहीं किया गया है?

नहीं, ऊपर देखें "एक बार में एक बार जरूरी नहीं है।"

C ++ 20 बड़ा नहीं है क्योंकि हमने तीन वर्षों में अधिक काम किया है, लेकिन क्योंकि बहुत सारे लंबे विकास हैं (कम से कम दो जिनमें हम वर्तमान रूप में 2012 से पी-वाक्यों और टीएस-शाखाओं के रूप में काम कर रहे हैं) ) तत्परता के चरण तक पहुंच गया और उन्होंने उन्हें उसी रिलीज के मसौदे में शामिल करने का फैसला किया।

लगभग हमेशा, मुख्य विशेषताएं कई वर्षों तक विकसित होती हैं। C ++ 98 और C ++ 11 और दृष्टिकोण (2) के लिए दृष्टिकोण (1) के बीच मुख्य अंतर यह है कि C ++ 98 और C ++ 11 में रिलीज होने में देरी हुई जब तक कि ये सभी विशेषताएं तैयार नहीं हुई थीं, और अब हम बड़े जहाज करते हैं जैसे ही तैयार होगा, और उनके साथ हम और भी बहुत कुछ जारी करेंगे।

C ++ 20 C ++ 14 और C ++ 17 के समान तीन-वर्षीय चक्र के माध्यम से चला गया। हमने पिछले तीन वर्षों में पिछले दो चक्रों की तुलना में अधिक नहीं किया है, हमने मुख्य विशेषताओं में और अधिक जोड़ दिया है। यदि उनमें से कोई भी तैयार नहीं था, तो हमने इसे बाहर फेंक दिया और इसे पहले ही सी ++ 23 के लिए समाप्त कर दिया। यदि ऐसा होता है, तो हम इसे कार्यान्वयन प्रस्ताव में रिपोर्ट करेंगे और कारणों की व्याख्या करेंगे।

C ++ 14 + 17 + 20 ने C ++ 98 (1989-1998) और C ++ 11 (2002-2011) के बाद हमारा तीसरा नौ साल का चक्र (2011-2020) बनाया। लेकिन जब से हमने दृष्टिकोण (2) का पालन किया, हमने तीन साल और छह साल के चक्र के अंत में तैयार होने वाले विकास को भी जारी किया।

क्या किसी उत्पाद के विकास के तहत बग को पकड़ना बेहतर है, और जारी होने के बाद नहीं?

बेशक यह बेहतर है।

लेकिन अगर हम C ++ मानक के जारी होने में देरी के कारणों के बारे में बात कर रहे हैं, तो यह सवाल दो गलत धारणाओं का कारण बनता है:

• इससे पहले कि मानक जारी किया गया था, सुविधाएँ बाहर नहीं आई थीं और उपयोग नहीं की गईं थीं (कई के लिए, उत्पादन में पहले से ही अनुभव है);
  
• और यह कि सभी सुविधाओं का उपयोग तब तक किया जा सकता है जब तक कि मानक जारी नहीं किया जाता है (अनुमति नहीं है)।
  

मैं समझाता हूं:

1. C ++ 20 की अधिकांश प्रमुख विशेषताओं को उस रूप में लागू किया गया था जिसमें वे कम से कम एक संकलक में मानक के वर्तमान मसौदे में परिलक्षित होते हैं, और ज्यादातर मामलों में पहले से ही उत्पादन कोड में उपयोग किया गया है (अर्थात, वे पहले से ही बहुत संतुष्ट हैं जो उपयोगकर्ताओं के लिए उपलब्ध हैं) । उदाहरण के लिए, कोरआउट्स (इस लेख के ठीक पांच महीने पहले पेश किए गए) का इस्तेमाल MSVC में दो साल और क्लैंग में एक साल के लिए किया गया था, जो बड़े ग्राहकों (उदाहरण के लिए, Azure और Facebook) से बहुत खुश था।
2. हम सुविधाओं के बीच बातचीत की कई समस्याओं को तब तक पकड़ने नहीं जा रहे हैं जब तक कि उपयोगकर्ता उन्हें उत्पादन में उपयोग करना शुरू नहीं करते हैं, अर्थात, मानक जारी होने से पहले, क्योंकि कई डेवलपर्स विभिन्न परियोजनाओं को लागू करने के लिए इसके जारी होने का इंतजार करेंगे। और अगर हम रिलीज के समय के बारे में अनिश्चितता दिखाते हैं, तो इन कार्यान्वयनों में भी देरी होगी। ठीक है, वे अभी भी कुछ को लागू करते हैं, लेकिन बहुत तब तक रोक दिया जाएगा जब तक कि डेवलपर्स को यकीन नहीं हो जाता है कि हम रिलीज के लिए तैयार हैं। <पसंदीदा संकलक नाम> के रचनाकारों से पूछें कि क्या हुआ जब उन्होंने प्रकाशित मानक में दिखाई देने से पहले <बड़ी विशेषता नाम> लागू किया। कई मामलों में, बार-बार लागू करना और उपभोक्ताओं को बार-बार तोड़ना आवश्यक है। इसलिए, डेवलपर्स कुछ विशेषताओं को अनुमोदित करने के लिए समिति की प्रतीक्षा करना पसंद करते हैं।

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

मानक कभी भी सही नहीं होगा ... क्या आप बग जारी नहीं करते हैं?

हां।

यदि हम देखते हैं कि सुविधा तैयार नहीं है, तो हमें इसे रिलीज़ से हटा देना चाहिए।

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

हम जानबूझकर उन सुविधाओं को जारी करते हैं जिन्हें हम भविष्य में सुधारने की योजना बनाते हैं, जबकि हमें विश्वास है कि हम पिछड़े संगतता को बनाए रख सकते हैं।

लेकिन क्या आपको रिलीज़ त्रुटियों को कम करने की कोशिश नहीं करनी चाहिए?

हां। हम कोशिश कर रहे हैं।

लेकिन हम सभी जोखिमों से बचने की कोशिश नहीं करते हैं। हमें जो भी तैयार लगता है उसे जारी करने से इनकार करने का एक जोखिम और (संभव) मूल्य भी है। और अधिक बार नहीं, हम सही हैं।

क्या आप सुनिश्चित हैं कि अब दृष्टिकोण (1) का उपयोग करने की तुलना में गुणवत्ता बेहतर है?

हां।

वस्तुनिष्ठ मेट्रिक्स के अनुसार, विभिन्न देशों और बग रिपोर्ट, C ++ 14 और C ++ 17 की टिप्पणियों की मात्रा हमारी सबसे स्थिर रिलीज़ थी, और इन मैट्रिक्स द्वारा वे C ++ 98 और C ++ 11 की तुलना में 3-4 गुना अधिक थे। और इसका कारण रिलीज की नियमितता में ठीक है, टीएस शाखाओं में पहली बार बड़ी विशेषताओं को रखने में (मुख्य मानक के साथ उनके एकीकरण के पूर्ण विवरण सहित) और उनके बाद के जलसेक में, जब हम तत्परता के बारे में आश्वस्त होते हैं।

2012 के बाद से, मुख्य मानक हमेशा लगभग तैयार-टू-शिप राज्य में बनाए रखा गया है (इसलिए सी ++ 98 और सी ++ 11 मानकों के रिलीज के समान उच्च गुणवत्ता वाले ड्राफ्ट काम कर रहे हैं)। यह पहले कभी नहीं हुआ, जब हमने रोगी को लंबे समय तक असुरक्षित रखा, समस्याओं और अंगों की लंबी सूची के साथ, जो चारों ओर फैल गया, जिसे हम जल्द ही वापस लाने जा रहे हैं। अब हम जानते हैं कि हम उच्च गुणवत्ता वाले काम के साथ एक कार्यक्रम बनाए रख सकते हैं, क्योंकि हम हमेशा रिहाई के लिए करीबी तत्परता की स्थिति में रहते हैं। यदि आप चाहें, तो आप कोलोन में मिलने के बिना भी, अब भी एक सीडी जारी कर सकते हैं, और अभी भी गुणवत्ता सीडी सी ++ 98 या सी ++ 11 (सत्य में, और उनके प्रकाशित मानकों) के साथ पहले से कहीं अधिक होगी। । और यह देखते हुए कि C ++ 98 और C ++ 11 सफल थे, यह समझ कि अब गुणवत्ता अधिक है इसका मतलब है कि हम सही रास्ते पर हैं।

C ++ 98 और C ++ 11 लगभग 9 वर्षों के लिए विकसित किए गए थे और बहुत अच्छे उत्पाद थे ...

हां: 1989-1998 और 2002-2011।

... और C ++ 14 और C ++ 17 मामूली रिलीज़ थे। क्या C ++ 20 एक बड़ी रिलीज़ है?

मैं दोहराता हूं, मेरा मानना ​​है कि यह C ++ 14 + 17 + 20 की तुलना में सही है: यह हमारा नौ साल का चक्र है, लेकिन जब से हमने दृष्टिकोण (2) का पालन किया है, हमने उन विकासों को भी जारी किया जो तीन साल और छह साल के चक्र को पूरा करने के लिए तैयार थे। ।

दृष्टिकोण (2) आपको अगले C ++ के लिए P0592 जैसे सुविधा-आधारित लक्ष्य प्राप्त करने की अनुमति देता है?

बेशक! हालांकि इसमें कोई शब्द नहीं हैं जैसे "इन सुविधाओं को शामिल करना चाहिए", क्योंकि तब यह दृष्टिकोण (1) होगा।

सुविधाओं के एक निश्चित सेट के लिए प्रयास करना और उनमें से एक को प्राथमिकता देना सामान्य है, लेकिन फिर यह प्राथमिकता का विषय है। अब तक, हम केवल वही लेंगे जो तैयार है, लेकिन हम यह चुन सकते हैं कि जितनी जल्दी हो सके तैयार करने के लिए सबसे पहले क्या काम करना है।