मूल एसटीएल और उसके उन हिस्सों के बीच विशिष्ट अंतर क्या हैं जो सी ++ मानक पुस्तकालय में समाप्त हुए?

Question

मैं जानना चाहता हूं कि एसटीएल के बीच SGI और आईएसओ सी ++ मानक पुस्तकालय द्वारा जारी किए गए विशिष्ट अंतर क्या हैं। this question द्वारा सूचित किया गया और सभी उत्तर this question द्वारा उत्तर दिया गया।

कुछ अंतर स्पष्ट हैं, जैसे कि slist और hash_set कक्षाएं जो इसे मानक में कभी नहीं बनाती हैं। मैं अधिक सूक्ष्म मतभेदों की तलाश भी कर रहा हूं, जैसे तरीकों पर वापसी मूल्य/पैरामीटर अंतर, या विभिन्न जटिलता आवश्यकताओं, या विभिन्न इटरेटर अमान्यता की स्थिति।

Answer 1

क्या larsmans already wrote के अलावा

:

• std::basic_string एक एसटीएल कंटेनर इंटरफेस के साथ सुसज्जित किया गया।

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

Answer 2

एसजीआई एसटीएल सामान "लापता" सी ++ मानक में

• slist
• bit_vector
• hash_set, hash_map, hash_multiset, hash_multimap भी शामिल है और सब कुछ कार्यों
• rope
हैश से संबंधित
• iota
• lexicographical_compare_3way
• random_sample और random_sample_n
• MonoidOperation और Trivial Iterator अवधारणाओं
• ऐसे algo.h

के रूप में पिछड़े compat हेडर के एक मेजबान ... और मुझे यकीन है आप कुछ पा सकते हैं अधिक।

Answer 3

एसटीएल में कुछ कार्यात्मक सामान भी थे जो दुर्भाग्य से stdlib में चूक गए थे, हालांकि सी ++ 0x इसे हल करता है।

एसटीएल दस्तावेज़ से रचना fuctors के लिए an example के शब्दों में

एक सीमा के प्रत्येक तत्व के लिए sin (x)/(x + DBL_MIN) गणना करता है।

transform(first, last, first, 
      compose2(divides<double>(), 
        ptr_fun(sin), 
        bind2nd(plus<double>(), DBL_MIN))); 

या, pair selectors के लिए:

transform(M.begin(), M.end(), ostream_iterator<double>(cout, " "), 
      select2nd<map<int, double>::value_type>()); 

Answer 4

operator[]std::map में अंतर यह है कि मानक में यह (*((insert(make_pair(x, T()))).first)).second लौटने, जबकि एसटीएल में m[k](*((m.insert(value_type(k, data_type()))).first)).second के बराबर के रूप में परिभाषित के रूप में परिभाषित किया गया है है।

अंतर यह है कि सी ++ कार्यान्वयन के अनुरूप make_pair पर कॉल करें जबकि एसटीएल सीधे जोड़ी को बनाता है। मैं दो मतभेदों के बारे में सोच सकता हूं:

1) मानक यूवी की एक अतिरिक्त प्रति (और इसलिए कुंजी और डेटा ऑब्जेक्ट्स) की अनुमति देता है, यदि आरवीओ make_pair पर कॉल के लिए लात मारने में विफल रहता है। जैसा कि मैंने इसे पढ़ा है, एसटीएल इस प्रतिलिपि की अनुमति नहीं देता है (हालांकि insert में लाइन के नीचे एक और प्रतिलिपि है)। यह मायने रखता है कि यदि कुंजी या मान प्रकार में अवलोकन करने वाले साइड इफेक्ट्स के साथ प्रतिलिपि बनाने वाले निर्माता हैं।

2) उपयोगकर्ता std::make_pair या std::pair का विशेषज्ञ कर सकते हैं। यदि वे make_pair विशेषज्ञ हैं तो उनके कोड को मानक सी ++ में कॉल करने की गारंटी है, और एसटीएल में कॉल नहीं होने की गारंटी है।

इस तरह की विशेषज्ञता, यूबी कारण अगर वे टेम्पलेट की आवश्यकताओं को संतुष्ट नहीं है, हालांकि, और make_pair के मामले में मुझे लगता है कि अगर यह किसी भी नमूदार जोड़ी बनाने के अलावा अन्य असर पड़ता है, तो यह नहीं है लगता है आवश्यकताओं को पूरा करें। तो इस मामले में की गारंटी देने के लिए इस मामले में मुश्किल या असंभव हो सकता है ताकि आप यह कह सकें कि इसे कॉल किया गया है या नहीं। व्यावहारिक रूप से यदि कार्यान्वयन ने स्पष्ट बात की है और मानक से कोड का उपयोग किया है, तो आप आसानी से एक अंतर देखेंगे ...

उपयोगकर्ता एडीएल-ओवरलोड make_pair, एक ही चेतावनी, अतिरिक्त जटिलताओं के साथ मैं ' मुझे कभी भी यकीन नहीं है कि अयोग्य फंक्शन कॉल के मानक में उल्लेख की आवश्यकता है कि कार्यान्वयन एक ही अयोग्य कॉल करें। मुझे यकीन है कि मैंने सुना है कि कुछ कार्यान्वयन ने ऐसे मामलों में std::whatever पर पूरी तरह से योग्य कॉल की है, शायद गलती से।

क्या यह इस तरह की चीज है जिसके बाद आप हैं?

Answer 5

मैं एक विस्तृत सूची से परिचित नहीं हूं। हालांकि, get the original STL पर यह संभव है और यह मानक के साथ तुलना करें कि आपके पास कितना समय है और आप कितना विस्तार चाहते हैं।

Answer 6

एसटीएल में, std::list::splice के चार-तर्क संस्करण की स्थिर समय जटिलता होने की गारंटी है, भले ही एक सूची का एक हिस्सा अलग सूची में विभाजित किया जा रहा हो। नतीजतन, std::list::size की निरंतर जटिलता की गारंटी नहीं है, वास्तव में कम से कम कुछ मामलों में ओमेगा (एन) होने की गारंटी है। मैंने जांच नहीं की है कि क्या एसजीआई कार्यान्वयन सभी मामलों में ओमेगा (एन) बनाता है।

सी ++ 03 मानक में, 4-आर्ग splice केवल जब एक सूची का एक वर्ग एक ही सूची में एक अलग जगह के लिए ले जाया जा रहा है लगातार जटिलता के लिए गारंटी है। इसका मतलब है कि सूची का आकार बदलता नहीं है, और इसलिए कार्यान्वयन की अनुमति देता है जिसमें size() निरंतर समय है। जीएनयू एसटीएल दृष्टिकोण से फंस गया, लेकिन मेरा मानना ​​है कि डिनकम ने स्थिर समय size() का चयन किया था।

सी ++ 11 मानक में, size() लगातार समय के लिए आवश्यक है, और प्रभाव splice में इसलिए ओमेगा कुछ मामलों में (एन) होने की गारंटी है। एसटीएल दृष्टिकोण अब अनुरूप नहीं है, और इसके परिणामस्वरूप जीसीसी में बाइनरी असंगतता है जब उन्होंने आकार क्षेत्र को std::list पर जोड़ा।

Answer 7

एसटीएल संभावना के लिए अनुमति देता है कि सी ++ कार्यान्वयन सदस्य फ़ंक्शन टेम्पलेट्स का समर्थन नहीं करता है (इस मामले में, सभी सदस्य फ़ंक्शन टेम्पलेट्स और कन्स्ट्रक्टर टेम्पलेट अनुपलब्ध हैं)। स्पष्ट रूप से मानक उस परमिट नहीं करता है।