क्यों एमएफसी कंटेनरों पर एसटीएल कंटेनरों को प्राथमिकता दी जाती है?

Question

पहले, मैं एमएफसी संग्रह कक्षाओं जैसे CArray और CMap का उपयोग करता था। थोड़ी देर बाद मैंने एसटीएल कंटेनर में स्विच किया और थोड़ी देर के लिए उनका इस्तेमाल कर रहा हूं। हालांकि मुझे एसटीएल बहुत बेहतर लगता है, मैं इसके लिए सटीक कारणों को इंगित करने में असमर्थ हूं। तर्क से कुछ जैसे:

1. यह MFC की आवश्यकता है: नहीं रखता है क्योंकि मेरे कार्यक्रम के अन्य भागों MFC का उपयोग करता
2. यह मंच निर्भर है:। क्योंकि मैं केवल खिड़कियों पर अपने आवेदन को चलाने के नहीं रखता है (कोई पोर्टेबिलिटी के लिए की जरूरत है)
3. यह सी ++ मानक में परिभाषित किया गया है: ठीक है, लेकिन MFC कंटेनर अभी भी काम

एकमात्र कारण मैं ऊपर आ सकता है कि मैं कंटेनरों पर एल्गोरिदम का उपयोग कर सकते हैं। क्या कोई अन्य कारण है कि मैं यहां याद कर रहा हूं - एमएफसी कंटेनर की तुलना में एसटीएल कंटेनर बेहतर क्या बनाता है?

Answer 1

रोनाल्ड Laeremans, कुलपति ++ उत्पाद यूनिट प्रबंधक, यहां तक ​​कि said to use STL जून 2006 में:

और स्पष्ट रूप से टीम आप एक ही जवाब दे देंगे। एमएफसी संग्रह कक्षाएं पीछे की संगतता के लिए केवल वहां हैं। सी ++ में संग्रह कक्षाओं के लिए मानक है और यह मानक सी ++ लाइब्रेरी है। एमएफसी आवेदन में किसी भी मानक पुस्तकालय का उपयोग करने के लिए कोई तकनीकी कमी नहीं है।

हम इस क्षेत्र में महत्वपूर्ण बदलाव करने की योजना नहीं बनाते हैं।

रोनाल्ड Laeremans
कार्यवाहक उत्पाद यूनिट प्रबंधक
विजुअल C++ टीम

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

Answer 2

वास्तव में you can use STL algorithms on some of MFC containers as well। हालांकि, एसटीएल कंटेनरों को एक और बहुत व्यावहारिक कारण के लिए प्राथमिकता दी जाती है: कई तृतीय पक्ष पुस्तकालय (बूस्ट, अरबीका, क्रिप्टो ++, यूटीएफ-सीपीपी ...) को एसटीएल के साथ काम करने के लिए डिज़ाइन किया गया है, लेकिन एमएफसी कंटेनर के बारे में कुछ भी नहीं पता है।

Answer 3

यह वह काम है जो आप जो काम करना चाहते हैं उसके लिए काम करते हैं, और 'बेहतर' एक व्यक्तिपरक शब्द है।

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

यदि आप निश्चित हैं कि आपका कोड एमएफसी-भूमि में रहेगा, और एमएफसी कंटेनर आपके लिए काम करते हैं, तो उनका उपयोग क्यों न करें?

एसटीएल कंटेनर एमएफसी कंटेनर से स्वाभाविक रूप से बेहतर नहीं हैं, हालांकि वे मानक का हिस्सा हैं, वे संदर्भों की एक विस्तृत श्रृंखला में अधिक उपयोगी हैं।

Answer 4

एसटीएल कंटेनर:

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

Answer 5

• संगतता। यह एक गैर-तुच्छ लाभ है।
• एसटीएल का उपयोग करना एक कौशल विकसित करेगा जो अन्य संदर्भों में उपयोगी होने की संभावना है। एमएफसी इतनी व्यापक रूप से उपयोग नहीं किया जाता है; एसटीएल है।
• एसटीएल का उपयोग करने से एक मानसिकता विकसित होगी जो आप स्वयं लिखने वाले कोड में उपयोगी (या नहीं) पा सकते हैं।

एसटीएल के अलावा कुछ और उपयोग करना स्वाभाविक रूप से गलत नहीं है।

Answer 6

मुझे लगता है कि यह एक साधारण प्रश्न के लिए उबालता है: आप किस पर भरोसा करते हैं? यदि आप माइक्रोसॉफ्ट पर भरोसा करते हैं, तो एमएफसी वेरिएंट का उपयोग करना जारी रखें। यदि आप उद्योग पर भरोसा करते हैं, तो एसटीएल का उपयोग करें।

मैं एसटीएल के लिए वोट देता हूं क्योंकि आज विंडोज़ पर चलने वाले कोड को किसी अन्य प्लेटफ़ॉर्म पर पोर्ट करने की आवश्यकता हो सकती है। :)

Answer 7

मैं हमेशा अधिक मानक/संगत पुस्तकालयों का उपयोग करना पसंद करता हूं, जहां से मैं भविष्य की परियोजनाएं कर सकता हूं क्योंकि मैं कोड के एक हिस्से का पुन: उपयोग कर सकता हूं। मुझे नहीं पता कि पुस्तकालय भविष्य की परियोजनाओं का उपयोग किस प्रकार करेंगे, लेकिन अगर मैं मानक/संगत सामान का उपयोग करता हूं तो मेरे कोड को पुन: प्रयोज्य बनाने का एक बेहतर मौका है।

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

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

Answer 8

• एसटीएल MFC
की तुलना में अधिक संग्रह प्रकार
• दृश्य स्टूडियो (2008 +) डिबगर एसटीएल ज्यादा MFC की तुलना में बेहतर की परिकल्पना करती है। (AUTOEXP.DAT जादू है कि ठीक कर सकते हैं - लेकिन यह एक दर्द अपने डिबगर डिबगिंग जब आप इसे पेंच अप जैसा कुछ भी नहीं है ...)

MFC के साथ एक अच्छी बात अभी भी का विशाल संग्रह है कि वहाँ है वहाँ एमएफसी कोड। अन्य उत्तर तीसरे पक्ष की संगतता के बारे में बात करते हैं। तीसरे पक्ष के एमएफसी आधारित सामान मत भूलना।

Answer 9

एमएफसी कंटेनर CObject और CObject से प्राप्त हुए हैं असाइनमेंट ऑपरेटर निजी बना दिया है। मुझे अभ्यास में यह बहुत परेशान पाया गया है।

std::vector, CArray unlinke, गारंटी देता है कि स्मृति ब्लॉक सटा हुआ है, इस प्रकार आप आसानी से सी प्रोग्रामिंग इंटरफेस के साथ Interop कर सकते हैं:

std::vector<char> buffer; 
char* c_buffer = &*buffer.begin(); 

Answer 10

क्योंकि एक पुस्तकालय iterators का उपयोग करता है एल्गोरिदम के साथ किसी भी तरह के दृश्यों गठबंधन करने के लिए ताकि ए) सभी समझदार क्रमिकताएं संभव हों और बी) यह सार्वभौमिक रूप से विस्तार योग्य है, (जब आप एक कंटेनर लाइब्रेरी की अपनी अवधारणा के बारे में सोचते हैं क्योंकि यह 15 साल पहले था) इस तरह के दिमाग में आश्चर्यजनक विचार है कि यह काफी उड़ा हुआ है एक दशक से भी कम समय में पानी की सब कुछ?

गंभीरता से, एसटीएल की त्रुटियां हैं (क्यों नहीं iterators की बजाय श्रेणियां हैं? और यह मिटाएं-हटाएं मुहावरे बिल्कुल सुंदर नहीं है), लेकिन यह एक शानदार विचार पर आधारित है और हमें बहुत अच्छे कारण हैं जिन्हें हमें सीखने की आवश्यकता नहीं है प्रत्येक बार जब हम एक नई नौकरी शुरू करते हैं तो एक नया कंटेनर/एल्गोरिदम लाइब्रेरी।

Answer 11

उल्लिखित पहलुओं के आगे: अच्छी तरह से समर्थित, मानक उपलब्ध, प्रदर्शन के लिए अनुकूलित, एल्गोरिदम के साथ उपयोग के लिए डिज़ाइन किया गया, मैं एक और पहलू जोड़ सकता हूं: टाइप-सुरक्षा, और संकलन-समय जांच का भार। आप std::set<int> में से double ड्राइंग की कल्पना भी नहीं कर सकते हैं।

Answer 12

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

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

Answer 13

अब यह माना जाता है कि सी ++ डेवलपर्स कम से कम एसटीएल से परिचित हैं। एमएफसी कंटेनर के लिए ऐसा नहीं है। इसलिए यदि आप अपनी टीम में एक नया डेवलपर जोड़ रहे हैं, तो आपके पास एमएफसी कंटेनर की तुलना में एसटीएल को जानने वाला एक आसान समय होगा, और इस प्रकार तुरंत योगदान करने में सक्षम हो जाएगा।