😾 👨‍👨‍👧 🤳🏽 डे डे स्टैंडर्ड लाइब्रेरी 👨🏽 👩🏽‍💻 🕕

प्राग में दूसरे दिन, C ++ मानकीकरण समिति ने ABI को बदलने के मुद्दे पर कई सर्वेक्षण किए, और अंततः इसमें कुछ भी नहीं बदलने का निर्णय लिया गया। हॉल में तालियां नहीं बज रही थीं।
मुझे लगता है कि हमें इस नतीजे का पूरी तरह से एहसास नहीं था कि यह फैसला लागू होगा, और मुझे विश्वास नहीं है कि, सिद्धांत रूप में, यह भाषा के विकास को सकारात्मक रूप से प्रभावित कर सकता है।

ABI क्या है?

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

आप अपने संकलित पुस्तकालय के नए संस्करण में निर्यात किए गए प्रतीक का उपयोग नहीं कर सकते हैं यदि आपने निम्न में से कोई किया:

मौजूदा वर्ग में एक नया क्षेत्र जोड़ा गया
वर्ग / फ़ंक्शन के टेम्प्लेट मापदंडों को बदल दिया, टेम्पलेट फ़ंक्शन को गैर-टेम्पलेट में बदल दिया, या इसके विपरीत, एक वैरेडिक टेम्पलेट जोड़ा
कुछ के लिए इनलाइन निर्दिष्ट लागू करें
फ़ंक्शन घोषणा में डिफ़ॉल्ट पैरामीटर जोड़े गए
नई आभासी विधि की घोषणा की

और बहुत, बहुत अधिक, लेकिन ऊपर दिए गए उदाहरण मुख्य हैं जो समिति द्वारा उल्लिखित हैं, और बहुत ही हैं, जिनके लिए मानक में अधिकांश प्रस्ताव मौके पर ही नष्ट हो जाते हैं। मैंने एबीआई का उल्लंघन करने के विकल्पों को छोड़ दिया, जिसके दौरान कार्यक्रम का स्रोत कोड भी टूट जाता है (उदाहरण के लिए, फ़ंक्शन को हटाना या बदलना)। हालांकि, यह हमेशा सच नहीं है। उदाहरण के लिए, फ़ंक्शन को हटाना हमेशा स्रोत कोड को तोड़ने में प्रवेश नहीं करता है। std::stringइसमें एक रूपांतरण ऑपरेटर है std::string_view, जिससे मैं ख़ुशी से छुटकारा पाऊंगा, और यद्यपि इसे हटाने से ABI टूट जाएगा, इससे स्रोत कोड में महत्वपूर्ण समस्याएं नहीं होंगी।

हमें एबीआई को क्यों तोड़ना चाहिए

सबसे पहले, मानक पुस्तकालय के कार्यान्वयन में कई उपयोगी परिवर्तन हैं जिन्हें आप वर्तमान एबीआई को तोड़ने पर लागू कर सकते हैं:

सहयोगी कंटेनरों (बहुत) को तेज करें
अपने काम को गति दें std::regex(फिलहाल, PHP को चलाना और मानक एक का उपयोग करने की तुलना में नियमित अभिव्यक्ति के साथ उस पर खोज करना तेज़ है std::regex)
कुछ परिवर्तन std::string, std::vectorसाथ ही साथ अन्य कंटेनरों के लेआउट में भी
क्लास इंटरफ़ेस की एकता: फिलहाल, उनके कुछ कार्यान्वयन जानबूझकर स्थिरता के लिए एक इंटरफेस के अनुरूप नहीं हैं

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

std::scoped_lock अभय परिवर्तन को तोड़ने के लिए नहीं जोड़ा गया था lock_guard
int128_t , intmax_t. , , , intmax_t deprecated
std::unique_ptr , zero-overhead
error_code - , ABI
status_code ABI
recursive_directory_iterator , ABI
<cstring> constexpr ( strlen) , ABI
UTF-8 std::regex — ABI
reallocआवंटित मेमोरी के आकार में समर्थन जोड़ना और पॉलीमॉर्फिक आवंटनकर्ताओं के लिए एक एबीआई ब्रेकडाउन है
पॉलीमॉर्फिक प्रकारों के लिए निहित आभासी विध्वंसक बनाना
push_backयदि वर्तमान एबीआई को तोड़ा जाता है तो रिटर्न टाइप y को बदला जा सकता है
सामान्य तौर पर, क्या हमें वास्तव में जरूरत है push_backऔर emplace_back?
std::shared_ptr एबीआई के टूटने का कारण भी बनता है
[[no_unique_address]] संकलक द्वारा आउटपुट किया जा सकता है अगर हम वर्तमान एबीआई को बचाने के बारे में परवाह नहीं करते हैं

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

हम और क्या बदलना चाहते हैं?

मुझे नहीं पता। और मुझे नहीं पता कि मैं क्या नहीं जानता। लेकिन अगर मुझे अनुमान लगाने के लिए कहा गया, तो मैं निम्नलिखित कहूंगा:

C++23 ABI, - , ABI.
, , , , ABI
ABI,
, ABI
Tombstone ABI

ABI

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

मुख्य तथ्य:

WG21 23 में एबीआई को तोड़ना नहीं चाहता है
WG21 इसे C ++ (C ++ 26 या बाद के संस्करण) के ABI संस्करणों में तोड़ना आवश्यक समझता है
WG21 एबीआई का उल्लंघन करने वाले प्रस्तावों पर विचार करने के लिए समय लेगा
WG21 शाश्वत स्थिरता का वादा नहीं करता है
WG21 भाषा की स्थिरता की कीमत पर भी प्रदर्शन पर प्राथमिकता बनाए रखना महत्वपूर्ण मानता है

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

भविष्यवाणी

परिवर्तनों का इंतजार करने के लिए C ++ के किस संस्करण में

इन सभी चुनावों का स्पष्ट दोष यह है कि हमने तय नहीं किया है कि वास्तव में हम एबीआई को कब तोड़ना चाहते हैं।

सी ++ में 23? नहीं, निश्चित रूप से पहले से ही नहीं।

C ++ 26 में? कुछ लोग वोट देने का इरादा रखते हैं, लेकिन एक अन्य हिस्सा C ++ 41 या उस समय के लिए मतदान करते हैं जब वे सेवानिवृत्त होते हैं और उन्हें अपने वर्तमान प्रोजेक्ट का समर्थन करने की आवश्यकता नहीं होती है। सवालों में से एक सिर्फ सी ++ का उल्लेख किया - कुछ ; बहुत आराम से!

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

मुझे नहीं लगता कि तीन वर्षों में किए गए सर्वेक्षण में कुछ बदल जाएगा। यह ग्लोबल वार्मिंग की तरह है: हर कोई इस बात से सहमत है कि किसी दिन हमें इस समस्या से निपटने की आवश्यकता है। और फिर 2070 में डीजल पर प्रतिबंध लगा दें?

अगले पांच वर्षों में जो कुछ भी करने की योजना नहीं है, वह कभी नहीं होने की संभावना है।

एबीआई का उल्लंघन करने वाले प्रस्तावों के बारे में

WG21 ने वर्तमान एबीआई का उल्लंघन करने वाले प्रस्तावों के लिए अधिक समय समर्पित करने के लिए मतदान किया। इसका मतलब है कुछ चीजें:

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

एबीआई स्थिरता की तुलना में प्रदर्शन अधिक महत्वपूर्ण है

यह पूछना पसंद है कि क्या पांच साल का बच्चा कैंडी चाहता है। निश्चित रूप से हम प्रदर्शन के महत्व पर मतदान करेंगे। हालांकि, मुझे चिंता है कि कुछ लोगों ने अभी भी वोट दिया है।

मुझे ऐसा लगता है कि समिति एक ही समय में दो कुर्सियों पर बैठना चाहती है। और यह असंभव है:

ब्रायस एडेलस्टीन लेलबैक @blebach
- प्रदर्शन
- स्थिरता एबीआई
- कुछ बदलने की क्षमता

प्रस्तावित लोगों में से दो विकल्प चुनें।

भाषा और ABI की स्थिरता, निश्चित रूप से, एक दूसरे से टकराती है, जिससे हमें इस तरह के मौलिक प्रश्न पूछने को मजबूर होना पड़ता है - C ++ क्या है और इसकी मानक लाइब्रेरी क्या है?

आमतौर पर, इस मामले में, शब्द "प्रदर्शन", " शून्य-लागत अमूर्तता", " जो आप उपयोग नहीं करते हैं उसके लिए भुगतान न करें " को याद किया जाता है । और ABI की स्थिरता इस सब के बीच है।

दूरगामी परिणाम

मुझे गहरा यकीन है कि 23 वें वर्ष में एबीआई को तोड़ने का निर्णय समिति द्वारा की गई सबसे बड़ी गलती है। और मुझे पता है कि कुछ लोग इसके विपरीत मानते हैं। लेकिन जल्द ही ऐसा होने की संभावना है:

सीखने का दुःस्वप्न

चलो ईमानदार बनें। एबीआई पर भरोसा करने वाले सभी कार्यक्रमों में कहीं न कहीं ओडीआर सिद्धांतों का उल्लंघन करने या असंगत झंडे का उपयोग करने की संभावना है , जो सौभाग्य से, अभी भी काम करते हैं।

नए कार्यक्रमों को स्रोत कोड से संकलित किया जाना चाहिए, हमें स्रोतों से विधानसभा पर निर्मित उपकरणों की आवश्यकता है, और पुस्तकालयों का संग्रह नहीं है जो हमें कहीं से मिला है और किसी तरह परियोजना में डाला गया है।

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

एबीआई का उल्लंघन करने से इनकार करते हुए, समिति खुले तौर पर कहती है कि यह पूरे अस्तित्व में खराब लिखित कार्यक्रमों का समर्थन करेगी। भले ही आप apt-install के माध्यम से प्राप्त पुस्तकालयों से लिंक नहीं करते हैं (जो वास्तव में सिस्टम के लिए अभिप्रेत हैं), अन्य लोग होंगे, क्योंकि समिति ने उन्हें अपना आशीर्वाद दिया था।

यह एक बहुत बड़ा कदम है। यदि हम ऐसा करने के लिए कोई प्रोत्साहन नहीं देते हैं तो हम दूसरों को अच्छी भाषा अभ्यास कैसे सिखा सकते हैं?

मानक पुस्तकालय में ब्याज की हानि

एबीआई का उल्लंघन करने की हमारी अनिच्छा के कारण पुस्तकालय प्रदर्शन में अनुमानित नुकसान 5-10% अनुमानित है। यह संख्या केवल समय के साथ बढ़ती जाएगी। आइए उदाहरण देखें:

यदि आप एक बड़ी कंपनी हैं, तो आप अपने आप को एक नया डेटा सेंटर खरीद सकते हैं या प्रोग्रामर की एक टीम का भुगतान कर सकते हैं जो अपने स्वयं के पुस्तकालय का समर्थन करेंगे
, 5% ,
, 5-10% , VR-
, —

मुझे लगता है, यहाँ, विली-नीली, के बीच सवाल उठता है: "मुझे निश्चित रूप से सी ++ और इसकी मानक लाइब्रेरी का उपयोग करना चाहिए!" और "शायद मुझे मानक पुस्तकालय का उपयोग नहीं करना चाहिए? या शायद मुझे सिद्धांत रूप में C ++ का उपयोग नहीं करना चाहिए? शायद .NET, जूलिया या रस्ट एक बेहतर समाधान होगा? ” बेशक, ऐसे कई कारक हैं जो उत्तर को प्रभावित करते हैं, लेकिन हम देखते हैं कि हाल ही में क्या हो रहा है।

कई खेल डेवलपर्स मानक पुस्तकालय से बेहद उलझन में हैं। वे एसटीएल का लाभ लेने के बजाय ईएएसटीएल जैसे अपने स्वयं के विकल्प विकसित करेंगे । फेसबुक है मूर्खता , गूगल है abseil और इतने पर।

यह एक स्नोबॉल की तरह है। यदि लोग मानक पुस्तकालय का उपयोग नहीं करते हैं, तो उन्हें इसे सुधारने में कोई दिलचस्पी नहीं है। प्रदर्शन प्रमुख कारक है जो पुस्तकालय को बचाए रखता है। प्रदर्शन की गारंटी के बिना, इसके विकास में बहुत कम प्रयास किए जाएंगे।

>> जोनाथन मुलर @foonathan
क्या मानक पुस्तकालय से कंटेनरों का इस्तेमाल करता है, तो वे बेहतर प्रदर्शन प्रदान नहीं करते की बात है?

टाइटस विंटर्स @TitusWinters
शायद क्योंकि वे आम और आसानी से सुलभ हैं? (इन दोनों तथ्यों का एक ही मतलब नहीं है)।
एबीआई संरक्षण के लिए मतदान यह कहने जैसा है कि मानक पुस्तकालय को मैकडॉनल्ड्स होने का प्रयास करना चाहिए - यह भी हर जगह है, यह स्थिर है और तकनीकी रूप से कार्यों को हल करता है।

एक समिति एबीआई को तोड़ने वाले प्रस्तावों पर कैसे विचार कर सकती है?

यदि वे ABI का उल्लंघन करते हैं तो ऑफ़र स्वीकार करने में असमर्थता के कारण दर्द निवारण के रूप में कई विकल्प पेश किए जाते हैं:

नए नाम जोड़ना

यह पहला और स्पष्ट समाधान है। अगर हम नहीं बदल std::unordered_mapसकते, तो क्या हम जोड़ सकते हैं std::fast_map? इसके खराब होने के कई कारण हैं। समर्थन की लागत और शिक्षा के संदर्भ में, मानक पुस्तकालय में प्रकार जोड़ना महंगा है। नई कक्षा की शुरुआत के बाद, हजारों लेख अनिवार्य रूप से दिखाई देंगे, जिसमें समझा जाएगा कि किस कंटेनर का उपयोग किया जाना चाहिए। उदाहरण के लिए, मुझे उपयोग करना चाहिए std::scoped_lockया std::lock_guard? मुझे पता नहीं है! मुझे हर बार Google की आवश्यकता है। समस्या यह भी है कि अच्छे नाम जल्दी या बाद में समाप्त हो जाते हैं। कार्यक्रम के निष्पादन के दौरान हमें कुछ ओवरहेड भी मिलते हैं, क्योंकि सभी कंटेनरों को लगातार एक दूसरे में परिवर्तित किया जाना चाहिए, वर्ग में भारी संख्या में रूपांतरण ओवरलोड को नियंत्रित करना मुश्किल हो जाता है, आदि।

यह विडंबना है, लेकिन वे लोग जो ऊपर दिए गए समाधान का समर्थन करते हैं, वे यह भी तर्क दे सकते हैं कि C ++ एक भाषा बहुत जटिल है। लाइब्रेरी में डुप्लिकेट जोड़ना निश्चित रूप से आसान नहीं होगा।

लेकिन हम इस प्रस्ताव को एक मानक के रूप में स्वीकार कर सकते हैं!

कुछ पुस्तकालय डेवलपर्स का दावा है कि उनके प्रस्तावों को एबीआई उल्लंघन के कारण खारिज कर दिया गया था, हालांकि वे वास्तव में किसी भी चीज का उल्लंघन नहीं करते थे, या उन्हें एबीआई विफलता को नाकाम करने के लिए बदला जा सकता था।

एक सनकी व्यक्ति के रूप में, मेरे लिए यह मानना थोड़ा कठिन है। तथ्य यह है कि पहले इस तरह के प्रस्ताव नहीं थे, और जिन परिदृश्यों में उन्हें लागू किया जा सकता है, वे बहुत सीमित हैं। ABI समीक्षा समूह (ARG) इस मामले में मदद कर सकता है, लेकिन वे फिर से कक्षा / समारोह के लिए एक और नाम की सिफारिश करने की संभावना है।

आंशिक अबी उल्लंघन

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

सूचकांक का एक और स्तर

ABI के साथ कुछ समस्याओं का समाधान एक पॉइंटर के माध्यम से कक्षा के डेटा तक पहुंचने की क्षमता होगी, फिर क्लास का मार्कअप सिर्फ उस पॉइंटर का होगा। यह विचार PIMPL मुहावरे के बहुत करीब है , जो कि ABI के कारण सक्रिय रूप से Qt में प्रयोग किया जाता है । हाँ, यह वर्ग के सदस्यों के साथ समस्या को हल करेगा, लेकिन आभासी तरीकों के साथ क्या करना है?

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

नतीजतन, इस दृष्टिकोण की कीमत बहुत बड़ी होगी।

इस समस्या के समाधान के रूप में, मानक में पहले से ही कई प्रस्ताव हैं। उनमें से कुछ PIMPL को भाषा की विशेषताओं में से एक बनाना चाहते हैं, इसलिए आप एबीआई स्थिरता और उच्च प्रदर्शन के बीच चयन कर सकते हैं।

विडंबना यह है कि, लेकिन पुस्तकालय प्रकारों को PIPML प्रकारों में बदलने के लिए, हमें ... ABI को तोड़ने की आवश्यकता है।

हर तीन साल में सभी कोड फिर से इकट्ठा करें

बस मेरे विचार ज़ोर से।

मानक के सभी वर्तमान ऑफ़र नष्ट होने चाहिए

विरोधाभासी रूप से, C ++ कभी भी उतनी जीवंत नहीं रही जितनी अब है। प्राग में, 250 लोगों ने उनके लिए कई चीजों पर काम किया, जिनमें शामिल हैं:

अंकीय
रेखीय बीजगणित
ऑडियो
यूनिकोड
एसिंक्रोनस I / O
2 डी और 3 डी ग्राफिक्स
कई अन्य विशेषताएं

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

और फिर, इस तरह के हॉरर नेटवर्किंग के रूप में क्षितिज पर घूमते हैं । यह बहुत ही गैरजिम्मेदार है, जो किसी भी चीज को मानकीकृत करने की कोशिश करता है, जो सुरक्षा समस्याओं को जन्म दे सकता है, और साथ ही बाद में इसे बदलने में सक्षम नहीं है (एबीआई के बारे में याद रखें)।

चूंकि C ++ ने इसे स्थिर बनाने का निर्णय लिया, इसलिए इन सभी सुझावों को नष्ट और जला दिया जाना चाहिए। मैं नष्ट नहीं होना चाहूंगा, लेकिन ऐसा होना चाहिए।

लेकिन वे अभी भी ऐसा नहीं कर रहे हैं।

सर्वोत्तम स्थिति में, हम गलतियों को नहीं बनाएंगे और C ++ के नए संस्करणों में से एक में चीजों की वर्तमान स्थिति को मानकीकृत करेंगे, और फिर सब कुछ धीरे-धीरे विघटित होने देंगे, क्योंकि इसे ठीक करना संभव नहीं होगा (नेटवर्किंग टीएस के मामले में, हम कुछ भी बदलने में असमर्थ प्रतीत होते हैं, इसलिए हमें यह निर्धारित करना होगा कि दस साल पहले क्या अस्तित्व में था, फिर भी पुस्तकालय में अभी भी काफी सुधार हो सकता है, लेकिन आइए इस कहानी को एक दूसरे के लिए छोड़ दें)।

लेकिन निश्चित रूप से, हम कई गलतियाँ करेंगे।

>> Ólafur Waage @olafurw
( , )

, !

. , ( : , , )?

Hyrum Wright @hyrumwright
, , . — , .

कुछ गलतियों को जानबूझकर किया जाता है, क्योंकि वे व्यापार-बंद हैं, जबकि अन्य कई वर्षों से किसी का ध्यान नहीं जाते हैं।

समय बीत जाता है, लेकिन मानक पुस्तकालय अभी भी खड़ा है। पहले किए गए ट्रेड ऑफ धीरे-धीरे हमें परेशान करना शुरू कर रहे हैं, और बाद में मौजूदा कोड में वास्तविक "अड़चनें" बन गए हैं।

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

C ++ अभी भी अगले 40 वर्षों में बरकरार रहेगा। यदि हम किसी भी समय इसे अप्रत्याशित तरीके से बदलने की आवश्यकता महसूस नहीं कर सकते हैं, तो केवल सही कदम इस खेल को सिद्धांत रूप में नहीं खेलना होगा।

हर कोई जानता है कि एक मानक साहचर्य कंटेनर दस साल से कम समय के लिए उपयोग के लिए प्रासंगिक है। लेकिन फिर हम क्यों सोचते हैं कि मानक में बड़े प्रस्ताव अधिक सफल होंगे?

मानक के लिए आपका प्रस्ताव नष्ट हो जाएगा , मेरा उसी तरह नष्ट हो जाएगा।

क्या सिद्धांत में एक समिति एक एबीआई को तोड़ सकती है?

कई लोगों को यकीन है कि समिति, सिद्धांत रूप में, ऐसा निर्णय नहीं ले सकती है, क्योंकि तब पुस्तकालय डेवलपर्स इसे अनदेखा कर देंगे। यह सब दर्द बांह की कुश्ती से मिलता-जुलता है, जिसमें समिति ने नहीं खेलने का फैसला किया।

लेकिन तथ्य यह है कि किसी भी उत्पाद के डेवलपर्स के अपने उपयोगकर्ता हैं। उपयोगकर्ता वे हैं जिन्हें सबसे पहले यह समझने की आवश्यकता है कि उन पर क्या व्यापार-नापसंद हैं।

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

डे डे स्टैंडर्ड लाइब्रेरी