क्या आधुनिक C ++ की प्रयोगात्मक विशेषताएं दीर्घकालिक परियोजनाओं के लिए विश्वसनीय हैं?

Question

मेरे पास एक प्रोजेक्ट है जो वर्तमान में C ++ 11/14 का उपयोग करता है, लेकिन इसके लिए कुछ ऐसा चाहिए std::filesystem, जो केवल C ++ 17 में उपलब्ध हो, और इसलिए मुझे वर्तमान में इसका उपयोग करने का मौका नहीं है। हालाँकि, मैं देख रहा हूँ कि यह मेरे वर्तमान संकलक के रूप में उपलब्ध है std::experimental::filesystem। क्या प्रायोगिक सुविधाओं का उपयोग करना एक अच्छा विचार है, यह मानते हुए कि मैं भविष्य में कुछ ऐसा जोड़ सकता हूं:

#ifdef CXX17 //if this is C++17
std::filesystem::something ...;
#else
std::experimental::filesystem::something ...;
#endif

मेरी चिंताएं हैं:

1. क्या यह गारंटी है कि सभी आज्ञाकारी संकलक में समान प्रयोगात्मक विशेषताएं हैं?

2. क्या प्रायोगिक विशेषताएं बड़े बदलावों से जुड़ी हैं जो उन्हें अविश्वसनीय बनाती हैं?

शायद इसके बारे में आश्चर्य करने के लिए और चीजें हैं। मुझे उनका उपयोग क्यों करना चाहिए या नहीं करना चाहिए? मैं एक नई परियोजना के साथ हैरान हूँ और पता नहीं क्या फैसला करना है।

Comments

क्या शब्द प्रायोगिक आपके सवालों का जवाब नहीं देता है ?

— 101010

मुख्य रूप से स्वाद की बात है, लेकिन मैं कोड को अव्यवस्थित करने से बचूंगा #idef CXX17। IMHO, पोर्टेबल तरीका यह है कि सभी फाइल सिस्टम से संबंधित कोड को एक एकल संकलन इकाई (एक वर्ग हो सकता है) में रखा जाए, इसे कोड के शेष हिस्सों में उपयोग करें, इसे वर्तमान C ++ 11/14 मानक के साथ कोड करें। दस्तावेज़ यह है कि आप इसे क्यों लिखते हैं, और अंत में इसे C ++ 17 में रखरखाव चरण के दौरान पोर्ट कर देते हैं, अगर यह समझ में आता है। (मूल प्रश्न पर टिप्पणी करते हुए)

— सर्ज बैलस्टा

मानक में प्रवेश करने के लिए एक उम्मीदवार के रूप में यह केवल "प्रयोगात्मक" था। यह कोड की गुणवत्ता का प्रतिबिंब नहीं है।

— गैलिक

"प्रायोगिक" और अंतिम C ++ 17 संस्करण के बीच काफी कुछ बदलाव थे, दस्तावेज़ P0492R1

— Bo Persson

यदि filesystemआप इसे अन्य चीजों की तुलना में उपयोग करने में बहुत कम जोखिम उठाते हैं, जैसा कि आप पहले से ही जानते हैं कि यह C ++ 17 में मानकीकृत हो जाता है, और इसका सटीक C ++ 17 विनिर्देश सार्वजनिक रूप से उपलब्ध है। इसलिए आपको केवल यह सुनिश्चित करना है कि आप केवल उन experimental::filesystemविशेषताओं का उपयोग करें जो C ++ 17 विनिर्देश में हैं। और निश्चित रूप से आपको यह जानना होगा कि आपके सभी लक्षित प्लेटफ़ॉर्म एक experimental::filesystemया C ++ 17 का समर्थन करते हैं std::filesystem।

— हावर्ड हिनांट

Answer 1

1. क्या यह गारंटी है कि सभी आज्ञाकारी संकलक में समान प्रयोगात्मक विशेषताएं हैं?

नहीं, प्रायोगिक सुविधाएँ वैकल्पिक हैं।

2. क्या प्रायोगिक विशेषताएं बड़े बदलावों से ग्रस्त हैं जो उन्हें अविश्वसनीय बनाती हैं?

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

आम तौर पर, प्रायोगिक सुविधाओं पर निर्भर रहना अच्छा नहीं है। प्रायोगिक विशेषताएं ठीक वही हैं जो शब्द कहता है (यानी, प्रयोग करने के लिए)।

Comments

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

— क्वांटम भौतिक विज्ञानी

@ TheQuantumPhysicist: "पहले से ही स्वीकृत" एक मुश्किल अवधारणा है। बाद में इसे हटाने के लिए परिवर्तन की स्वीकृति के द्वारा किसी भी समय कुछ भी हटाया जा सकता है, और यह हर मानक के साथ हुआ है। आप संभवतः कम से कम ड्राफ्ट इंटरनेशनल स्टैंडर्ड तक इंतजार करना चाहते हैं, क्योंकि फीचर सेट काफी विश्वसनीय है।

— केरेक एसबी

@KerrekSB: क्या आपका मतलब फाइनल ड्राफ्ट इंटरनेशनल स्टैंडर्ड उर्फ ​​एफडीआईएस नहीं है। ? आलेखन एक बहुत स्थायी प्रक्रिया है।

— MSalters 10:17

@ स्तनधार: नहीं, अगर आप जल्दी में हैं तो डीआईएस काफी अच्छा है। और हमारे पास इस समय एफडीआईएस नहीं हो सकता है।

— केरेक एसबी

@KerrekSB: मैं बहुत ज्यादा C ++ 03 के आसपास नीदरलैंड के लिए राष्ट्रीय निकाय था;)। हमारे पास SC22 के लिए एक राष्ट्रीय सचिव था जो आईएसओ प्रक्रियाओं और एफडीआईएस का उत्तर देने के बारे में जानता था, लेकिन क्या नहीं। हमारे WG14 प्रतिनिधि रैंडी मार्केस के अलावा) हमारे SC22 प्रतिनिधियों में से कोई भी C ++ के बारे में कुछ नहीं जानता था। और रैंडी सिर्फ तथ्य यह है कि सी ++ अपने सभी यूबी से सी में परिभाषित किया गया व्यवहार के लिए आवश्यक परिभाषित करने के लिए और अधिक पृष्ठों की आवश्यकता होगी मजाक बना रहा था - उसे जवाब देने के लिए नहीं करना चाहते एफ डी आई कि;)

— MSalters

Answer 2

दर्शकों से किसी ने "C ++ स्टैंडर्ड लाइब्रेरी पैनल" के दौरान CppCon 2016 ( YouTube ) में बात करते हुए एक सवाल पूछा कि नाम के संभावित experimentalउपयोगकर्ताओं को नामस्थान के भीतर कुछ भी उपयोग करने से डराने के लिए:

क्या आप लोग यह मानते हैं कि [ std::experimentalनामस्थान की सामग्री ] उत्पादन तैयार है और क्या यह तर्क दिया जा सकता है, [कि] यह अगले ३ वर्षों के लिए प्रभावी रूप से तैयार है, और हो सकता है कि आपको ३ साल बाद अपना कोड बदलना पड़े, हो सकता है?

माइकल वोंग (SG5 और SG14 की कुर्सी और कंज्यूरिटी टीएस के संपादक) ने इस सवाल को सबसे पहले रखा:

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

इसके बाद एलिसडेयर मेरेडिथ (LWG की पूर्व अध्यक्ष):

मैं यहाँ विपरीत स्थिति लेने जा रहा हूँ। हर्ब [सटर] में से एक ने WG21 के संयोजक के रूप में कहा, मानक समूह, जब हमने टीएस का रास्ता बंद कर दिया है, उन्होंने यह नहीं सोचा था कि टीएस तब तक सफल होगा जब तक हम कुछ आगे लाने में असफल नहीं होते, क्योंकि यह इसका मतलब है कि हम पर्याप्त प्रायोगिक नहीं हैं, हम उस महत्वाकांक्षी के रूप में पर्याप्त नहीं हैं जो हम टीएस के लिए उपयोग कर रहे हैं। हम वास्तव में यही चाहते हैंexperimentalएक संकेत है कि, हाँ, ये चीजें परिवर्तन के अधीन हैं, हम उस के लिए बाध्य नहीं हैं, और हम चीजों को गलत कर सकते हैं। यह उन चीजों के लिए हमारी बाधा को कम करने के लिए है जिन्हें हम महत्वाकांक्षी मानते हैं और जितना हम कर सकते हैं, […] अब तीन साल के रिलीज चक्र पर मानक लगता है, हमें वास्तव में प्रायोगिक सुविधाओं को रखने में बहुत अधिक महत्वाकांक्षी होना चाहिए टीएस में, और शायद मुख्य मानक में ही चीजों को अधिक तेजी से आगे बढ़ाना। लेकिन फिर, यह हमारे लिए अगले कुछ [सी ++ मानक समिति] बैठकों में चर्चा करने के लिए एक मजेदार विषय होगा।

Stephan T. Lavavej (माइक्रोसॉफ्ट के एसटीएल कार्यान्वयन के अनुरक्षक) का जवाब देने के लिए अंतिम था:

इंटरफ़ेस की प्रयोगात्मकता और कार्यान्वयन की प्रयोगात्मकता के बीच अंतर करना महत्वपूर्ण है, क्योंकि जब आप "उत्पादन तैयार" कहते हैं, तो इसका क्या मतलब है? आमतौर पर, "प्रोडक्शन रेडी", आपको लगता है कि कार्यान्वयन के बारे में बात करेंगे। यह std::experimentalपूरी तरह से [...] बुलेटप्रूफ होने के लिए [कुछ में ] के कार्यान्वयन के लिए काफी संभव है । [...] कुछ ऐसा [...] <random>TR1 में हैडर, [यह था] वास्तव में, वास्तव में TR1 में बहुत अच्छा है, और आप उस का एक बिल्कुल बुलेट प्रूफ कार्यान्वयन हो सकता था, लेकिन यह पता चला है कि इंटरफ़ेस मंथन किया काफी हद तक [C ++ 11 और [...] की रिलीज़ से पहले अगर हम वापस जानते थे तो अब हम क्या करते हैं, experimentalलोगों के लिए एक बेहतर संकेत होता है कि, "अरे, शायद आप नहीं चाहते हैं" उपयोगstd::experimental::variate_generator क्योंकि, हा-हा, यह C ++ 11 में गायब होने वाला है।

इसलिए ऐसा लगता है कि मानक पुस्तकालय डेवलपर्स और समिति के सदस्यों के बीच कुछ इच्छाएं हैं, जो कि भविष्य में कम से कम, std::experimentalनाम स्थान की सामग्री को वास्तव में "प्रायोगिक" होना चाहिए, और इसे इस लिए नहीं लेना चाहिए कि कुछ में std::experimentalहोगा इसे C ++ मानक में बनाएं।

और नहीं, जहां तक ​​मैं समझता हूं, यह मानक पुस्तकालय विक्रेताओं पर निर्भर है कि क्या वे विभिन्न सुविधाओं के लिए कार्यान्वयन प्रदान करते हैं std::experimental।

Comments

10 साल बाद मैंने पहली बार नाम पढ़ा, तथ्य यह है कि माइक्रोसॉफ्ट के एसटीएल अनुरक्षक का नाम एसटीएल है फिर भी मुझे चकली बनाता है।

— जॉर्ग डब्ल्यू मित्तग

@ JörgWMittag आपको उनके कंपाइलर मेंटेनर, माइकल सैम विक्टर कॉलिन्स से मिलना चाहिए

— MM

Answer 3

"प्रायोगिक" एक थोड़ा अतिरंजित शब्द है। filesystemपुस्तकालय बूस्ट में जन्म लिया है और वहाँ कुछ पुनरावृत्तियों माध्यम से चला गया, आईएसओ को प्रस्तुत किए जाने से पहले।

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

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

Answer 4

शायद इसके बारे में आश्चर्य करने के लिए और चीजें हैं।

विचार करने के लिए कुछ बिंदु:

• आपका प्रोजेक्ट कितना मल्टीप्लायर है? यदि केवल एक संकलक शामिल है, तो आप इसका कार्यान्वयन और निर्णय लेने के लिए ट्रैक रिकॉर्ड का निरीक्षण कर सकते हैं। या उनसे पूछो!

• आपका कोडबेस कितना बड़ा है? परिवर्तनों का प्रभाव कितना बड़ा होगा?

• एपीआई / पुस्तकालय / सुविधा द्वारा प्रदान की जाने वाली विशेषताएं आपकी परियोजना के लिए कितनी मौलिक हैं?

• विकल्प क्या हैं?

  • प्रयोगात्मक सुविधा का उपयोग करें, फिर कोड को अनुकूलित करें जब / यदि यह मानकीकृत हो जाता है। हटाने के रूप में के रूप में आसान हो सकता है experimental::, या workarounds मजबूर करने के रूप में मुश्किल हो सकता है ।
  • एक अमूर्त परत (सर्ज बैलस्टा टिप्पणी) जोड़ें। यदि प्रायोगिक विशेषता में परिवर्तन होता है तो आपके पुन: लिखे को अलग कर दिया जाता है। एक मानक विशेषता के लिए, यह ओवरकिल हो सकता है (std :: filesystem पहले से ही एक अमूर्त परत है ...)।
  • किसी अन्य API / लाइब्रेरी का उपयोग करें। वही सवाल: परिपक्वता? मजबूती? स्थिरता? पोर्टेबिलिटी? उपयोग में आसानी? विशेषताएं?
• एसटीडी :: फाइलसिस्टम (या नेटवर्किंग टीएस) के मामले में, एक विकल्प experimentalया गिरावट के रूप में बढ़ावा देने की जरूरत है: फाइलसिस्टम ( रिस्पांस-प्रमोशन :: एसियो) के मामले में, कोई भी व्यक्ति असफल या हताश नहीं होता है।