MFC और ATL में मूलभूत अंतर क्या है?

Question

यह मानते हुए कि मैं केवल "सामान्य" जीयूआई कार्यक्रमों (कोई COM, कोई ActiveX, कुछ भी नहीं फैंसी) के लिए उनका उपयोग कर रहा हूं , मुझे एटीएल और एमएफसी के बीच मौलिक अंतर क्या दिखाई देगा, मुझे यह जानने में मदद करने के लिए कि कौन सा उपयोग करना है?

---

मैंने वेब पर कुछ खोजें की हैं, लेकिन अंततः किसी भी उत्तर ने वास्तव में मेरे प्रश्न का उत्तर नहीं दिया:

• http://msdn.microsoft.com/en-us/library/bk8ytxz5(v=vs.80) .aspx :

  • "ATL C ++ में COM घटक बनाने और एक छोटे पदचिह्न को बनाए रखने के लिए एक तेज़, आसान तरीका है। एक नियंत्रण बनाने के लिए ATL का उपयोग करें यदि आपको सभी अंतर्निहित कार्यक्षमता की आवश्यकता नहीं है जो MFC स्वचालित रूप से प्रदान करता है।"

    वास्तव में मेरे सवाल का जवाब नहीं है, क्योंकि:

    • मैं COM के साथ काम नहीं कर रहा हूँ।

    • क्या इसका मतलब यह है कि MFC तेज नहीं है? क्यों कैसे?

  • "MFC आपको पूर्ण एप्लिकेशन, ActiveX नियंत्रण और सक्रिय दस्तावेज़ बनाने की अनुमति देता है। यदि आपने पहले ही MFC के साथ नियंत्रण बना लिया है, तो आप MFC में विकास जारी रखना चाह सकते हैं। एक नया नियंत्रण बनाते समय, यदि आपको ज़रूरत नहीं है तो ATL का उपयोग करने पर विचार करें। सभी MFC की अंतर्निहित कार्यक्षमता। "

    इसके अलावा मेरे सवाल का जवाब नहीं है, क्योंकि:

    • मैं वास्तव में भी नहीं जानते हो क्या ActiveX है पहली जगह में।

    • ऐसा लग रहा है कि Microsoft MFC के उपयोग को हतोत्साहित कर रहा है, लेकिन मैं यह पता नहीं लगा सकता कि क्यों।

    • वास्तव में क्या है MFC की "अंतर्निहित कार्यक्षमता" जो ATL प्रदान नहीं करता है?

  • सामान्य तौर पर, यह मेरे प्रश्न का उत्तर नहीं देता है क्योंकि यह डाउनसाइड और उनके पीछे के कारणों की व्याख्या नहीं करता है।

क्योंकि प्रत्यक्ष या अप्रत्यक्ष रूप से, सब कुछ पिछले पृष्ठ पर वापस लिंक करना प्रतीत होता है:

• मैं यह कैसे तय करूं कि ATL, MFC, Win32 या CLR का उपयोग किसी नए C ++ प्रोजेक्ट के लिए किया जाए?

  • "एटीएल और एमएफसी के बीच का फैसला करने के लिए कुछ हद तक पेचीदा है। [[कोई मजाक नहीं!]] मैं आपको उन दोनों के बीच फैसला करने के लिए चुनने के लिए MSDN के पेज पर संदर्भित करूंगा।"

    जाहिर है , यह मेरे सवाल का जवाब नहीं है। :)

• http://www.codeguru.com/forum/archive/index.php/t-64778.html

• आदि।

वर्तमान में मैंने क्या देखा है (पिछले कुछ दिनों के भीतर, दोनों सीखने की कोशिश करते हुए):

• ATL टेम्प्लेट, या संकलन-समय के बहुरूपता पर आधारित है।
  • ATL विधियाँ गैर-आभासी होती हैं, और संदर्भों को वापस करने की प्रवृत्ति होती है।
• MFC वर्चुअल विधियों, या रन-टाइम बहुरूपता पर आधारित है।
  • MFC विधियाँ आभासी होती हैं, और संकेत वापस करने के लिए होती हैं।

लेकिन उनके बीच कोई वास्तु अंतर प्रतीत नहीं होता है :

• दोनों संदेश मानचित्र का उपयोग करते हैं ( BEGIN_MSG_MAPबनाम BEGIN_MESSAGE_MAP... बड़ी बात)
• दोनों Win32 विधियों को कक्षाओं में लपेटते हैं
• दोनों में एक जैसी कक्षाएं लगती हैं CWnd।CWindow

लेकिन फिर, यदि संकलन-समय बनाम रन-टाइम पहलू के अलावा कोई वास्तविक अंतर नहीं है, तो दोनों क्यों मौजूद हैं? उनमें से एक पर्याप्त नहीं होना चाहिए?

मुझे यहां क्या समझ नहीं आ रहा है?

Comments

मैं गलत हो सकता हूं, लेकिन मुझे पता है कि MFC को थोड़े से रनटाइम DLL की आवश्यकता है, जबकि मुझे लगता है कि ATL सभी एक्स में बनाता है। एटीएल सामान्य रूप से हल्का होता है। इसके अलावा,

— मेरलिन मॉर्गन-ग्राहम

@ मर्लिन: सही है, लेकिन यह एक भारी रनटाइम DLL की आवश्यकता क्यों है? मूल अंतर क्या है जो इसका कारण बनता है?

— user541686

एक DLL से जुड़े पूर्व संकलित वर्गों को विरासत में मिला, और स्रोत कोड समावेशन / इंस्टेंटेशन इंस्ट्रूमेंटेशन द्वारा लिंक किए गए इनहेरिट किए गए टेम्प्लेट के बीच समान अंतर। टेम्पलेट आमतौर पर "हेडर-ओनली" लाइब्रेरी होते हैं। मेरा उत्तर अधूरा है, इसलिए टिप्पणियों में :) MFC अभी भी विशाल गोद लेने और पीछे की संगतता के कारण मौजूद है। अन्यथा MS ने इसे फेंक दिया होता जब उन्होंने नए win32 रैपर बनाए। वे अपने सॉफ़्टवेयर पर अलग-अलग समर्थन अनुबंध करते हैं (अलग-अलग, लेकिन 10 साल तक)। समर्थन मूल्यह्रास, थियो के साथ असंगत नहीं है।

— मर्लिन मॉर्गन-ग्राहम

@ मेरिलिन: तो मैं क्या समझ रहा हूं कि मुझे एमएफसी का उपयोग नहीं करना चाहिए? वह "अतिरिक्त कार्यक्षमता" क्या है जिसका वे उल्लेख करते रहते हैं? क्या मुझे इसकी आवश्यकता है?

— user541686

@ मर्लिन: ATL.DLL के बारे में सुना है? सुना है "स्टैटिक लाइब्रेरी के रूप में MFC का उपयोग करें"?

— अजय

Answer 1

मुझे लगता है कि आपके प्रश्न का उत्तर ज्यादातर ऐतिहासिक है, अगर आप पीछे देखते हैं कि कैसे दो पुस्तकालयों की उत्पत्ति हुई और समय के माध्यम से विकसित हुआ।

संक्षिप्त उत्तर है, यदि आप "फैंसी" कुछ भी नहीं कर रहे हैं, तो एटीएल का उपयोग करें। COM में फेंके गए साधारण यूजर इंटरफेस के लिए यह बहुत अच्छा है।

लंबे उत्तर: MFC को 90 के दशक की शुरुआत में C ++ नामक इस नई भाषा को आज़माने और इसे विंडोज पर लागू करने के लिए बनाया गया था। इसने कार्यालय को विकास समुदाय के लिए उपलब्ध सुविधाओं की तरह बनाया जब ओएस उन्हें अभी तक नहीं था।

[संपादित करें: मैं Microsoft में काम नहीं करता था, इसलिए मुझे नहीं पता कि क्या कार्यालय कभी MFC पर बनाया गया था, लेकिन मुझे लगता है कि इसका उत्तर नहीं है। विन 3.1 में वापस, 95 दिनों में जीतें, ऑफिस यूआई टीम नए नियंत्रणों का आविष्कार करेगी, उन्हें पुस्तकालयों में पैकेज करेगी, फिर विंडोज और एमएफसी की टीमें रिडिस्ट्रांएबल डीएल के साथ उन नियंत्रणों के लिए रैपर और एपीआई को शामिल करेंगी। मुझे लगता है कि उन टीमों के बीच सहयोग और कोड साझा करने का एक सा था। अंततः वे नियंत्रण इसे सर्विस पैक या अगले विंडोज संस्करण में आधार ऑपरेटिंग सिस्टम में बदल देंगे। यह पैटर्न ऑफिस रिबन के साथ जारी रहा जिसे ऑफिस शिप के बाद विंडोज में ऐड-ऑन कंपोनेंट के रूप में जोड़ा गया था, और अब यह विंडोज ओएस का हिस्सा है।]

उस समय पुस्तकालय काफी आदिम था, क्योंकि C ++ भाषा और संकलक दोनों नए होने के कारण, और Microsoft ने समय के साथ कार्यालय का निर्माण किया।

इस इतिहास के कारण, MFC:

1. एक काफी स्पष्ट डिजाइन है। यह विंडोज एपीआई के आसपास एक हल्के आवरण के रूप में शुरू हुआ, लेकिन बढ़ता गया। थोड़ा 'फीचर्स' का एक गुच्छा है, जिसका आविष्कार किया जाना था क्योंकि संकलक और भाषा ने उनका समर्थन नहीं किया। कोई टेम्प्लेट नहीं थे, उन्होंने एक स्ट्रिंग क्लास का आविष्कार किया, उन्होंने सूची कक्षाओं का आविष्कार किया, उन्होंने अपने स्वयं के रन टाइम प्रकार की पहचान तैयार की, आदि।
2. कार्यालय और विंडोज विकास के 20 वर्षों को शामिल करता है, जिसमें आपके द्वारा उपयोग किए जाने वाले सामान का पूरा बोझ शामिल होता है: एकल और एकाधिक दस्तावेज़ इंटरफ़ेस, DDE, COM, COM +, DCOM, दस्तावेज़ लिंकिंग और एम्बेडिंग (ताकि आप किसी शब्द दस्तावेज़ को एम्बेड कर सकें। यदि आप चाहते हैं कि आपका ऐप), ActiveX नियंत्रण (वेब ​​के लिए ऑब्जेक्ट एम्बेडिंग का विकास!), संरचित दस्तावेज़ संग्रहण, सीरियललाइज़ेशन और संस्करण, स्वचालन (प्रारंभिक VBA वर्षों से), और निश्चित रूप से MVC। नवीनतम संस्करणों में विज़ुअल स्टूडियो स्टाइल विंडो डॉकिंग और ऑफिस रिबन के लिए समर्थन है। मूल रूप से 20 साल में रेडमंड से बाहर हर तकनीक कहीं न कहीं है। यह सिर्फ बड़ा है!
3. एक छोटी सी गौचे, कीड़े, वर्कअराउंड, मान्यताओं, उन चीजों के लिए समर्थन है जो अभी भी वहां हैं जो आप कभी भी उपयोग नहीं करेंगे, और वे समस्याएं पैदा करते हैं। आपको कई वर्गों के कार्यान्वयन के साथ अंतरंग रूप से परिचित होना चाहिए और वे एक सभ्य आकार की परियोजना पर इसका उपयोग करने के लिए कैसे बातचीत करते हैं। डिबगिंग के दौरान MFC सोर्स कोड में डिलीट होना आम है। कुछ पॉइंटर पर 15 साल पुराने तकनीकी नोट को खोजने से अशक्त होने का कारण बनता है। प्राचीन दस्तावेज़ एम्बेड करने वाले सामान के प्रारंभिककरण पर अनुमान आपके आवेदन को अजीब तरीकों से प्रभावित कर सकते हैं। एमएफसी में अमूर्तता जैसी कोई चीज नहीं है, आपको इसके साथ रोजाना quirks और internals के साथ काम करने की आवश्यकता है, यह कुछ भी नहीं छिपाता है। और मुझे क्लास के जादूगर पर शुरू मत करो।

AT ++ का आविष्कार C ++ भाषा के रूप में हुआ, और टेम्प्लेट आए। ATL MFC लाइब्रेरी की रन-टाइम समस्याओं से बचने के लिए टेम्प्लेट का उपयोग करने का एक प्रदर्शन था:

1. संदेश मैप्स: चूंकि वे टेम्पलेट आधारित हैं, इसलिए प्रकारों की जांच की जाती है, और यदि आप बाध्य फ़ंक्शन को पेंच करते हैं, तो यह निर्माण नहीं करता है। MFC मेसेज में मैप्स मैक्रो बेस्ड और रन-टाइम बाउंड होते हैं। यह अजीब बग पैदा कर सकता है, संदेश गलत विंडो में रूट हो जाता है, एक क्रैश यदि आपके पास फ़ंक्शन या मैक्रो गलत तरीके से परिभाषित है, या बस काम नहीं करता है क्योंकि कुछ सही नहीं है। डिबग करने के लिए बहुत अधिक कठिन है, और बिना सूचना के तोड़ने के लिए आसान है।
2. COM / स्वचालन: संदेश मानचित्रों के समान, COM मूल रूप से मैक्रोज़ का उपयोग करते हुए रन-टाइम बाउंड था, जिसमें बहुत सारी त्रुटि की आवश्यकता होती है और विषम समस्याएं पैदा होती हैं। एटीएल ने इसे खाका आधारित बनाया, समयबद्ध संकलन किया और इससे निपटने के लिए बहुत आसान।

[संपादित करें अलंकरण: जिस समय ATL बनाया गया था, उस समय Microsoft का तकनीकी रोड मैप मुख्य रूप से 'दस्तावेज़ प्रबंधन' पर केंद्रित था। Apple उन्हें डेस्कटॉप प्रकाशन व्यवसाय में मार रहा था। इस स्पेस में प्रतिस्पर्धा करने के लिए ऑफिस के 'डॉक्यूमेंट मैनेजमेंट' फीचर्स को बढ़ाने के लिए ऑफिस 'डॉक्यूमेंट लिंकिंग एंड एंबेडिंग' एक मुख्य घटक था। COM एक मुख्य प्रौद्योगिकी थी जिसे एप्लिकेशन एकीकरण के लिए आविष्कार किया गया था, और दस्तावेज़ एंबेडिंग एपीआई कॉम पर आधारित थे। इस उपयोग के मामले के लिए MFC का उपयोग करना मुश्किल था। ATL, COM को लागू करने और दस्तावेज़ एम्बेडिंग सुविधाओं का उपयोग करने के लिए 3 जी पार्टी के लिए इस विशेष तकनीक को आसान बनाने के लिए एक अच्छा समाधान था।]

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

दुर्भाग्य से एटीएल स्थिर हो गया। यह विंडोज़ एपीआई और COM समर्थन के लिए रैपर था, और फिर यह वास्तव में कभी भी इससे आगे नहीं बढ़ा। जब वेब बंद हुआ, तो यह सब सामान पुरानी खबरों की तरह भूल गया।

[संपादित करें अलंकरण: Microsoft ने महसूस किया कि यह 'इंटरनेट थिंग' बड़ा होने जा रहा था। डिस्ट्रिब्यूटेड ट्रांजैक्शन सर्वर में इंटरनेट एक्सप्लोरर, विंडोज सर्वर, आईआईएस, एएसपी, एसक्यूएल सर्वर, कॉम / डीसीओएम पर ध्यान केंद्रित करने के लिए उनके तकनीकी रोड मैप में काफी बदलाव आया। इसलिए डॉक्यूमेंट लिंकिंग और एंबेडिंग अब उच्च प्राथमिकता नहीं थी।]

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

अंत में, जो एक का उपयोग करने के लिए बस प्राथमिकता का मामला है। आपके लिए आवश्यक अधिकांश सुविधाएँ आधार OS API में हैं, जिसे आप लाइब्रेरी से सीधे कॉल कर सकते हैं, अगर लाइब्रेरी में कोई उपयुक्त रैपर नहीं है।

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

---

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

Comments

+1 मैं चाहता हूं कि मैं इसे +10 कर सकता हूं। उत्कृष्ट इतिहास विवरण के लिए धन्यवाद - यह बहुत अच्छी तरह से लिखित और जानकारीपूर्ण है! :)

— user541686

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

— user541686

तो क्या Microsoft दोनों का उपयोग करके नए प्रोग्राम बनाता है, या क्या उन्होंने एक दूसरे का उपयोग करने का निर्णय लिया है?

— मफिन मैन

मुझे लगा कि मुझे अंतर पता है..लेकिन इतनी सुंदर और विस्तृत व्याख्या कभी नहीं देखी..उम्मीद है कि..एक टन :)

— shivi

इस विषय पर मैंने जो सबसे अच्छा जवाब पढ़ा है; आपको

— Pat

Answer 2

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

मैं अनुशंसा करता हूं कि आप WTL पर एक नज़र डालें , क्योंकि यह ATL पर बनाता है।

वह "अतिरिक्त कार्यक्षमता" क्या है जिसका वे उल्लेख करते रहते हैं? क्या मुझे इसकी आवश्यकता है?

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

लेकिन यहां एक लेख है जो एमएफसी में कुछ विशेषताओं का वर्णन करता है जो सीधे डब्ल्यूटीएल / एटीएल द्वारा समर्थित नहीं हैं।

MFC इस बिंदु पर भी विकसित हुई है कि यह कई वांछित सुविधाओं का समर्थन करती है, जैसे MAPI, अन्य Windows लोगो आवश्यकताओं, सॉकेट्स, दस्तावेज़ों के लिए समर्थन (यदि आपको पसंद है और / या उस पैटर्न का उपयोग करें), और यौगिक दस्तावेज़ फ़ाइलें। WTL में कूल फीचर्स की हिस्सेदारी है, लेकिन MFC स्पष्ट फीचर शैंपू है। दोनों वातावरण फ़्रेमयुक्त मुख्य विंडो आर्किटेक्चर (अलग-अलग दृश्य विंडो के साथ फ़्रेम विंडो), एसडीआई और एमडीआई एप्लिकेशन, स्प्लिट विंडो, डायलॉग-आधारित एप्लिकेशन और COM समर्थन के लिए विभिन्न COM- आधारित कक्षाओं का समर्थन करते हैं।

Comments

जय के जवाब ने यह मात दी। कुछ अंतरों को समझाते हुए लेख के लिंक के लिए इसे छोड़ना।

— मेरलिन मॉर्गन-ग्राहम

Answer 3

ATL, COM ऑब्जेक्ट्स के कार्यान्वयन को आसान बनाने के लिए बनाई गई कक्षाओं का एक समूह है।

आप इसे MFC के बिना उपयोग कर सकते हैं। मेरी नौकरी पर, हम कम्प्यूटेशनल कोड में COM इंटरफेस को बेनकाब करने के लिए एटीएल का उपयोग करते हैं। कोई जीयूआई शामिल नहीं है, यह हमारे लिए है कि हम इस कम्प्यूटेशनल कोड को कॉल कर सकें। एक्सेल VBA।

कुछ COM गाइड / ट्यूटोरियल देखें कि यह क्या सार है।

MFC, Win32 API के लिए GUI रैपर कक्षाओं का एक सेट है। कुछ अमूर्त एपीआई ट्यूटोरियल को देखें कि यह क्या सार है।

Comments

ATL का उपयोग बिना किसी COM के भी किया जा सकता है। इसमें कई वर्गों का COM से कोई संबंध नहीं है जो WTL को देखते समय और भी अधिक स्पष्ट हो जाता है।

— 0xC0000022L

@ 0xC0000022L: CWindowImplजब मैंने यह लिखा था तो मुझे और दोस्तों को जानकारी नहीं थी । अब मुझे एटीएल के साथ अधिक अनुभव है, मैं इस उत्तर को फिर से लिखने की कोशिश कर सकता हूं। विशेष रूप से, ATL / WTL वस्तुतः MFC के सभी को बदल सकता है।

— अलेक्जेंड्रे सी।