अवधारणाओं को अलग रखना शायद एक अच्छा विचार है।
पहला, सी ++ एक भाषा है, और यह किसी प्लेटफॉर्म को लक्षित करने के बारे में कुछ भी निर्दिष्ट नहीं करता है। सिद्धांत रूप में, सीधे सी ++ कोड मूल x86 असेंबलर, जावा बाइटकोड, एमएसआईएल या किसी और चीज के बारे में सोचने के लिए संकलित किया जा सकता है। मेरा मानना है कि एडोब ने हाल ही में एक सी ++ कंपाइलर बनाया है जो फ्लैश बाइटकोड उत्पन्न करता है।
दूसरा, सामान्य अनिश्चितता के साथ, माइक्रोसॉफ्ट ने दो सी ++ - व्युत्पन्न भाषाओं को .NET को लक्षित किया है। सबसे पहले, उन्होंने "सी ++ के लिए प्रबंधित एक्सटेंशन" बनाए। फिर उन्होंने फैसला किया कि यह चूस गया है, इसे छीन लिया है और नाटक करने की कोशिश की है कि यह कभी अस्तित्व में नहीं था।
अब .NET-style C++ के लिए उनकी सर्वश्रेष्ठ शर्त को C++/CLI कहा जाता है, लेकिन यह C++ नहीं है। यह कई गैर-मानक तरीकों से भाषा को बढ़ाता है और बदलता है। (और मुझे विश्वास है कि सी ++ मानक समिति ने अनुरोध किया है कि वे भ्रम से बचने के लिए नाम बदल दें। लेकिन उन्होंने नहीं किया)
विजुअल स्टूडियो 2005 और नया सी ++/सीएलआई का समर्थन करता है। ("प्रोजेक्ट जोड़ें" में, वे विजुअल सी ++ -> सीएलआर के तहत सूचीबद्ध हैं)
हालांकि (आपने नहीं सोचा था कि यह इतना आसान था, क्या आपने किया?), माइक्रोसॉफ्ट ने इसे फिर से किया है। सी ++/सीएलआई निर्दिष्ट करने के बाद, जो वास्तव में सीएलआई के साथ सी ++ को एकीकृत करने के लिए एक उचित रूप से अच्छी तरह से डिज़ाइन किया गया प्रयास है, उन्होंने महसूस किया कि लगभग कोई भी इसका उपयोग नहीं करता है! यह पता चला है कि सी ++ प्रोग्रामर आम तौर पर सी # का उपयोग करना पसंद करते हैं जब वे .NET में काम कर रहे हैं, और उचित, मूल C++ अन्यथा।
तो अब, वे देशी सी ++ और .NET सरल और अधिक शक्तिशाली के बीच इंटरऑप बनाने पर ध्यान केंद्रित कर रहे हैं। हालांकि, सी ++/सीएलआई दूर जाने की संभावना नहीं है। यह काम करता है, और कुछ मामलों में यह उपयोगी है। यह सिर्फ सी ++ नहीं है - हत्यारा जिसे उन्होंने मूल रूप से आशा की थी।
विजुअल स्टूडियो (हमेशा के लिए) देशी सी ++ अनुप्रयोगों का भी समर्थन करता है, जो x86 मशीन कोड से संकलित है, जो .NET द्वारा अनचाहे है। ये Visual C++ -> Win32 के अंतर्गत "प्रोजेक्ट जोड़ें" संवाद में सूचीबद्ध हैं।
तो यदि आप सी ++ सीखना चाहते हैं, तो आपके पास दो विकल्प हैं: सी ++/सीएलआई सीखें, जो आपको एमएस-केवल भाषा तक सीमित करता है, जो हाँ, मूल मशीन कोड के बजाय एमएसआईएल उत्पन्न करता है, और चलाने के लिए .NET की आवश्यकता होती है, और आम तौर पर परेशान नहीं है क्योंकि यदि आप .NET पर निर्भरता लेने जा रहे हैं, तो, क्यों नहीं सी # में लिखें?
या उचित सी ++ सीखें, जो .NET से पूरी तरह से अलग है और सीधे .NET असेंबली का संदर्भ नहीं दे सकता है।
कुंजी टेकवे पॉइंट यह है कि वे अलग-अलग भाषाएं हैं। या तो आप सी ++/सीएलआई के रूप में संकलित करते हैं, जिसका अर्थ है कि संकलक आपको .NET असेंबली का संदर्भ देने की अनुमति देगा, और एमएसआईएल कोड उत्पन्न करेगा, या आप सी ++ के रूप में संकलित करेंगे, इस मामले में .NET दुनिया मौजूद नहीं है।
और अंत में, सावधानी का एक नोट। उपरोक्त मेरे शब्द के बावजूद ("उचित सी ++" और ".NET द्वारा अनचाहे"), सी ++ "बेहतर" नहीं है। कई मामलों में, यह या तो तेज़ नहीं है। C++ में संभावित तेज होने के लिए है, लेकिन यह प्रोग्रामर पर बहुत अधिक निर्भर करता है।
सी # कंपाइलर काफी कुछ भी उचित रूप से कुशल कोड में बदल देगा। दूसरी तरफ सी ++, संकट से भरा है जो आपके कोड समकक्ष समकक्ष सी # से बना देगा।
http://blogs.msdn.com/ricom/archive/2005/05/10/416151.aspx और ब्लॉग पोस्ट के संदर्भ दो भाषाओं में लिखे गए समान कोड के प्रदर्शन के बारे में उत्सुक किसी के लिए पढ़ने के लायक हैं।
केवल एक ऐसा क्षेत्र है जहां सी ++ अनुप्रयोग लगातार तेज़ी से होंगे, और यह स्टार्टअप समय में है। एक .NET अनुप्रयोग को .NET ढांचे और जेआईटी को एमएसआईएल कोड लोड करना पड़ सकता है, जहां एक मूल आवेदन ... बस शुरू होता है।
लेकिन इसके अलावा, यह संभवतः यह मानने की गलती है कि सी ++ तेज होगा। यह हो सकता है, क्योंकि यह आपको थोड़ा अधिक नियंत्रण देता है। लेकिन आमतौर पर, इसका मतलब यह है कि संकलक आपको आपके कोड में बनाए गए अक्षमता से बचाने में कम सक्षम है।
"नेट खोल" में :) –