एक प्रोग्रामिंग भाषा से दूसरी भाषा में स्वचालित अनुवादक क्यों नहीं हैं? [बन्द है]

Question

अधिकांश प्रोग्रामिंग लैंग्वेज ट्यूरिंग पूर्ण हैं, जिसका अर्थ है कि किसी भी कार्य को एक भाषा में हल किया जा सकता है या किसी अन्य में भी हल किया जा सकता है। तो फिर ऐसे स्वचालित अनुवादक क्यों नहीं हैं जो किसी भी भाषा से कार्यक्रमों को किसी अन्य भाषा में परिवर्तित कर सकते हैं? मैंने दो भाषाओं के लिए युगल प्रयास देखे हैं, लेकिन वे हमेशा एक भाषा के सीमित उपसमुच्चय पर ही काम करते हैं और शायद ही वास्तविक परियोजनाओं को परिवर्तित करने के लिए उपयोग किया जा सकता है।

क्या यह संभव है, कम से कम सिद्धांत में, सभी भाषाओं के बीच 100% सही अनुवादक लिखने के लिए? व्यवहार में चुनौतियां क्या हैं? क्या कोई मौजूदा अनुवादक काम कर रहे हैं?

Comments

याद रखें, "सभी भाषाओं" में Oook जैसे बेवकूफ भी शामिल हैं! (ट्यूरिंग पूर्णता पूरी कहानी नहीं है; आपको व्यवहार में भी syscalls की आवश्यकता है।)

— डोनल फेलो

कुछ हैं। C से पास्कल और पास्कल से C अनुवादक एक बिंदु पर काफी सामान्य थे। जैसा कि नीचे दिए गए सुझाव हैं, आउटपुट आमतौर पर कम से कम कुछ मैनुअल के बिना पढ़ने योग्य नहीं था। और ये अपेक्षाकृत सरल पुस्तकालयों के साथ अपेक्षाकृत सरल भाषाएं हैं - जैसे सी ++ के लिए हास्केल या वीजा वर्सा के लिए अच्छा काम करना शायद असंभव होगा।

— स्टीव 314

एक सेवा के रूप में रोजलिन .net कंपाइलर की जांच करें जिसमें C # से VB अनुवाद करने की क्षमता है और इसके विपरीत।

— डैनियल लिटिल

सभी कंपाइलर एक पीएल का दूसरे में अनुवाद करते हैं, वे इस बात की गारंटी नहीं देते हैं कि लक्ष्य पीएल में कोड हालांकि पढ़ना आसान है

— jk।

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

— गणेश कामथ -

Answer 1

सबसे बड़ी समस्या प्रोग्राम कोड का वास्तविक अनुवाद नहीं है, बल्कि प्लेटफॉर्म एपीआई का पोर्टिंग है।

एक PHP पर जावा अनुवादक पर विचार करें। PHP बाइनरी के भाग को एम्बेड किए बिना ऐसा करने का एकमात्र संभव तरीका है कि जावा में सभी PHP के मॉड्यूल और API के पुन: उपयोग को लागू किया जाए। इसमें 10.000 से अधिक कार्य शामिल हैं। इसकी तुलना में वास्तव में वाक्य रचना का अनुवाद पाई के रूप में करना आसान है। और यह सब काम करने के बाद भी आपके पास जावा कोड नहीं होगा, आपके पास कुछ प्रकार की राक्षसी होगी जो जावा प्लेटफॉर्म पर चलती है, लेकिन यह अंदर की तरह PHP की तरह संरचित थी।

यही कारण है कि इस तरह के एकमात्र उपकरण जो दिमाग में आते हैं, वे सभी इसे लागू करने के लिए कोड का अनुवाद करने के बारे में हैं, बाद में इसे बनाए रखने के लिए नहीं। Google का GWT "जावा" को जावास्क्रिप्ट में संकलित करता है। फेसबुक का हिपहॉप PHP को C में संकलित करता है।

Comments

इसके अलावा, विकिपीडिया में स्वचालित प्रोग्रामिंग भाषा अनुवादकों की काफी व्यापक सूची है ।

— एंडरसन ग्रीन

ऐसा लगता है कि किसी ने जावा अनुवादक को php बनाया और वास्तव में PHP बाइनरी को एम्बेड किया। हालांकि यह अपनी बात नहीं बदलता है। runtimeconverter.com/single-post/2017/09/15/…

— user1122069

Answer 2

यदि आपके पास एक मध्यवर्ती प्रारूप है, तो आप कुछ ऐसा भी लागू कर सकते हैं जो भाषा X में एक कार्यक्रम को उस प्रारूप में अनुवाद करता है, और उस प्रारूप से भाषा Y तक भी । उन सभी भाषाओं के लिए उन रूपांतरणों को लागू करें जिन्हें आप रुचि रखते हैं और आप कर रहे हैं, है ना?

वैसे आप जानते हैं क्या? ऐसा प्रारूप पहले से मौजूद है: असेंबली। कंपाइलर पहले से ही "लैंग्वेज एक्स टू असेंबली" रूपांतरण, और असेंबलर्स को "असेंबली टू लैंग्वेज वाई" कन्वर्सेशन करता है।

अब, असेंबली रिवर्स रूपांतरण करने के लिए एक महान भाषा नहीं है, लेकिन MSIL वास्तव में उतना बुरा नहीं है। रिफ्लेक्टर डाउनलोड करें और आप देखेंगे कि इसे .NET असेंबली को अलग-अलग भाषाओं के एक समूह (और प्लगइन्स और भी अधिक प्रदान करता है) को अलग करने के विकल्प मिले हैं। इसलिए सी # में एक कार्यक्रम लेना संभव है, इसे एक डीएलएल (यानी एमएसआईएल) के लिए संकलित करें, फिर इसे वीबी, सी ++ / सीएलआई, एफ #, और एक पूरे गुच्छा दूसरों में इकट्ठा करने के लिए रिफ्लेक्टर का उपयोग करें। बेशक, अन्य सभी रूपांतरण कार्य भी। एक F # फ़ाइल लें, एक DLL के लिए संकलित करें, इसे C # में बदलने के लिए परावर्तक का उपयोग करें।

बेशक, दो बड़ी समस्याएं जो आपको मिलेंगी वे हैं:

1. कोड मूल रूप से अपठनीय है। MSIL (यहां तक ​​कि डिबगिंग सूचना के साथ) मूल स्रोत से बहुत सारी जानकारी निकालता है, इसलिए अनुवादित संस्करण में 100% निष्ठा नहीं है (सैद्धांतिक रूप से C # -> MSIL-> C # रूपांतरण आपको मूल कोड वापस दे देना चाहिए, लेकिन यह नहीं होगा)।
2. कई .NET भाषाओं की अपनी कस्टम लाइब्रेरी होती हैं (जैसे VB रनटाइम लाइब्रेरी, F # लाइब्रेरी और इसी तरह)। जब आप अपना रूपांतरण करते हैं तो इन्हें शामिल (या परिवर्तित) करना होगा।

# 2 के आसपास पाने के लिए वास्तव में कुछ भी नहीं है, लेकिन आप संभवतः MSIL में कुछ अतिरिक्त एनोटेशन (विशेषताओं के माध्यम से, शायद) के साथ # 1 के आसपास प्राप्त कर सकते हैं। यह अतिरिक्त काम होगा।

Comments

मूल स्रोत से बहुत से मेटाडेटा को MSIL (XML टिप्पणियों और मूल विधि, संपत्ति और सदस्य नामों सहित) में शामिल किया गया है, इसलिए मुझे नहीं लगता कि C # में रूपांतरण उतना ही अपठनीय है जितना आप कहते हैं। .NET फ्रेमवर्क के भागों को अलग करने का प्रयास करें; यह बहुत पठनीय है। बेशक, स्थिति F # से C # रूपांतरण के लिए अलग हो सकती है।

— रॉबर्ट हार्वे

@Robert: XML टिप्पणियाँ MSIL में शामिल नहीं हैं। यदि आप Microsoft.NET\Framework\v2.0.50727\enउदाहरण के लिए देखते हैं, तो आप सिस्टम लाइब्रेरी के लिए XML दस्तावेज़ के सभी देख सकते हैं। यह वह है जो टिप्पणी को प्रदर्शित करने के लिए रिफ्लेक्टर (एट अल) का उपयोग करता है। रूपांतरण अप्राप्य नहीं है, सभी मैं कह रहा था कि यह 100% निष्ठा नहीं है, जिसे आप स्रोत-स्तरीय अनुवाद से उम्मीद कर सकते हैं।

— डीन हार्डिंग

एक डिस्सेम्बलर मशीन के निष्पादन योग्य बाइनरी को उस विशेष प्रोसेसर प्रकार के लिए कोडांतरक में बदल देता है (दुनिया के सभी एक x86 नहीं है)। आप वास्तव में संकलित कोड को स्रोत पर वापस लेने के लिए एक डिकम्पॉइलर का मतलब है। यह प्रत्येक निर्माता से प्रत्येक कंपाइलर के रूप में एक भयानक रूप से कठिन कार्य है, प्रत्येक अनुकूलन स्तर पर स्रोत लाइनों को एक अलग आउटपुट बाइनरी फॉर्म में बदल देगा।

— u22

Answer 3

क्या यह संभव है, कम से कम सिद्धांत में, सभी भाषाओं के बीच 100% सही अनुवादक लिखने के लिए? व्यवहार में चुनौतियां क्या हैं?

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

Comments

तुमने सिर पर कील ठोक दी है। LLVM के C बैकएंड से निकलने वाले कोड को पढ़ने का प्रयास करें। यह तकनीकी रूप से कानूनी C कोड है, लेकिन यह बहुत सुंदर (TM) नहीं है।

— dsimcha

@dsimcha: एक तरफ पठनीयता कि सी बैकेंड आउटपुट को डिबगिंग या डिसएस्पेशन की तुलना में पढ़ने में बहुत आसान बनाता है। मुझे खुशी है कि वे उस बैकएंड को फिर से वापस ले आए, क्योंकि यह थोड़ी देर के लिए रखरखाव से बाहर चला गया।

— जेएम बेकर

Answer 4

आप एक कार्यक्रम क्यों बदलना चाहते हैं?

दोनों भाषाओं, स्रोत और लक्ष्य भाषा को (आभासी) machinecode वैसे भी संकलित किया जाता है *, इसलिए तकनीकी कारणों से किसी अन्य उच्च स्तरीय भाषा के लिए संकलक होने की आवश्यकता नहीं है।

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

उदाहरण के लिए, सी में एक विशिष्ट पुनरावृत्ति और एक लिस्प में तुलना करें। या मुहावरेदार माणिक के साथ अजगर 'एक सबसे अच्छा तरीका'।

यहाँ, वही समस्याएं आपको वास्तविक भाषाओं में दिखाई देने लगती हैं, जैसे आप 'इट्स रेनिंग कैट एंड डॉग्स' का अनुवाद किसी ऐसे शब्द से करते हैं जिसका अर्थ है 'अंग्रेजी में अंग्रेजी से जर्मन में अनुवाद करते समय यह बाल्टी की तरह होगा'। शब्द को अब शब्द से अनुवादित करें, लेकिन आपको अर्थ ढूंढना होगा।

और 'अर्थ' काम करने के लिए एक आसान अवधारणा नहीं है।

*) अच्छी तरह से, वहाँ coffeescript है ...

Comments

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

— सुपरकैट

Answer 5

यह सैद्धांतिक रूप से संभव है लेकिन ज्यादातर बेकार है। स्रोत और लक्षित भाषाओं का लगभग कोई भी संयोजन संभव है, लेकिन ज्यादातर मामलों में कोई भी कभी भी परिणाम को देखना या उपयोग नहीं करना चाहेगा।

कंपाइलरों की एक उचित संख्या सी को लक्षित करती है, बस इसलिए कि सी कंपाइलर अस्तित्व में लगभग हर प्लेटफॉर्म के लिए उपलब्ध हैं (और स्वचालित कंपाइलर जनरेटर हैं जो आपको एक प्रोसेसर डिज़ाइन करने देंगे, और स्वचालित रूप से एक सी कंपाइलर उत्पन्न करेंगे जो आपके नए प्रोसेसर को लक्षित करता है)। ज़ाहिर है, कार्यान्वयन की एक उचित संख्या, जो विभिन्न वर्चुअल मशीनों जैसे .NET, JVM, C-- और LLVM द्वारा उपयोग की जाने वाली भाषाओं को लक्षित करती है।

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

Answer 6

FWIW, Java से D. का एक अनुवादक है। इसे TioPort कहा जाता है और SWT को D. में पोर्ट करने के लिए काफी गंभीर प्रयास में इस्तेमाल किया गया था। मुख्य समस्या यह थी कि जावा मानक पुस्तकालय के बड़े हिस्से को पोर्ट करना आवश्यक था। ।

Answer 7

हालांकि यह प्रति अनुवाद कोड नहीं है, भाषा कार्यक्षेत्र की अवधारणा से पता चलता है कि सभी भाषाओं के बीच 100% सही अनुवादक के लिए कुछ कैसे लागू किया जा सकता है।

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

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

जहां तक ​​मुझे पता है, तकनीक अभी भी मुख्यधारा के विकास में उपयोग करने से दूर है, हालांकि कई समूह स्वतंत्र रूप से इस पर काम कर रहे हैं। यह बताना मुश्किल है कि उनमें से कोई भी अपने वादे पर खरा उतरेगा या नहीं, लेकिन यह देखना दिलचस्प होगा।

Comments

क्या आप इनमें से कुछ समूहों को नाम दे सकते हैं?

— क्वर्टी

Answer 8

वहाँ हैं कुछ स्वचालित अनुवादकों। यदि आपका लक्ष्य पठनीय कोड के बजाय संकलित कोड का उत्पादन करना है, तो यह बहुत संभव है और कभी-कभी उपयोगी होता है, बस बहुत बार नहीं। पारिवारिक रूप से, पहला C ++ कंपाइलर वास्तव में एक कंपाइलर नहीं था, लेकिन C ++ को (वास्तव में जटिल) C स्रोत में अनुवादित किया गया था, जो तब C कंपाइलर द्वारा संकलित किया गया था। कई कंपाइलर अनुरोध पर असेंबली कोड उत्पन्न कर सकते हैं - लेकिन असेंबली टेक्स्ट को थूकने और फिर इसे मशीन कोड में बदलने के बजाय, वे आम तौर पर सीधे मशीन कोड उत्पन्न कर सकते हैं।

भाषा ए की एक पूरी विनिर्देशन को देखते हुए, यह मुश्किल नहीं है कि किसी प्रोग्राम में ऐसा निर्देश लिखना जो किसी भाषा में अपने निर्देशों को व्यक्त करता है B. , या इन दिनों बाइटकोड: जाइथन अजगर का एक कार्यान्वयन है जो जावा बाइट कोड उत्पन्न करता है, जिसकी व्याख्या जावा वीएम द्वारा की जाती है। जावा वर्ग पदानुक्रम लिखने और संकलन करने से परेशान होने की आवश्यकता नहीं है!

Answer 9

यह हर समय किया जाता है।

प्रत्येक संकलक "प्राथमिक भाषा" का अनुवाद C ++ की तरह, मशीन की मूल असेंबली भाषा या आर्किटेक्चर-इंडिपेंडेंट बाइटेकोड में व्याख्या की गई भाषाओं के मामले में करता है।

मुझे लगता है कि आप के बारे में क्या बात कर रहे हैं, हालांकि नहीं है। आप शायद एक अनुवादक चाहते हैं जो C ++ को जावा या पायथन जैसी किसी चीज़ में परिवर्तित कर दे। हालांकि, इसका क्या मतलब है? सर्वोत्तम रूप से, अंतिम परिणाम में मूल स्रोत के समान सटीक दक्षता होगी। (व्यावहारिक रूप से, यह बहुत बुरा होगा।)

यदि आप चाहते हैं कि कोड का अनुवाद किया जाए तो आप इसे एक ऐसी भाषा के रूप में पढ़ सकते हैं जिसे आप समझते हैं, ऐसे अनुवादक के वांछित प्रभाव के विपरीत होगा। आपको गुप्त, अचिन्त्य और अपठनीय कोड के साथ छोड़ दिया जाएगा।

ऐसा इसलिए है क्योंकि केवल सबसे तुच्छ चीजें सीधे एक भाषा से दूसरी भाषा में अनुवाद करती हैं। अक्सर, एक भाषा में सरल क्या दूसरे के लिए बड़े पैमाने पर पुस्तकालयों की आवश्यकता होती है - या पूरी तरह से असंभव हो सकता है। इसलिए:

1. यदि कार्यक्रम तुच्छ है, तो आपको एक अच्छा परिणाम मिल सकता है। लेकिन, अगर यह इतना आसान है, तो अनुवादक के माध्यम से इसे चलाने का क्या मतलब है?
2. यदि कार्यक्रम nontrivial है, तो कोड निम्न गुणवत्ता का होगा।

अंत में, अच्छा कोड लिखने का एकमात्र तरीका वास्तव में इसे लिखना है। कंप्यूटर बस नहीं कर सकते हैं - कम से कम अभी तक नहीं - पठनीयता, सर्वोत्तम प्रथाओं और सुरुचिपूर्ण समाधान के मामलों पर मनुष्यों से मेल खाते हैं।

संक्षेप में, यह सिर्फ इसके लायक नहीं है।

Comments

आपकी सादृश्यता फिर सामान्य संकलन पर भी लागू होगी, और हम अनुभव करते हैं कि ऐसा नहीं है! कंप्यूटर अच्छी गुणवत्ता कोड 'जनरेट' (लिखते नहीं) करते हैं। वे अक्सर बुरी तरह से करते हैं पठनीयता / स्थिरता है। अगर किसी को इस तरह की प्रक्रिया की आवश्यकता होती है, जो मुझे विश्वास है कि लोग कभी-कभार करते हैं, न तो समस्याएँ स्टॉपर्स दिखाती हैं। यदि वे हैं, तो ठीक है, जाहिर है कि अनुवाद मूल रूप से महत्वपूर्ण नहीं था।

— जेएम बेकर

Answer 10

प्रोग्रामिंग भाषाओं के लिए कोई भाषा अनुवादक नहीं हैं क्योंकि प्रोग्रामिंग भाषा अविश्वसनीय रूप से जटिल हैं। जबकि यह काल्पनिक रूप से संभव है, कई चुनौतियां हैं।

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

एक बार जब आप वाक्यविन्यास अनुवाद को प्राप्त कर लेते हैं, तो आपको यह पता लगाना होगा कि पहली भाषा में एक निर्माण को दूसरी भाषा में एक निर्माण में कैसे परिवर्तित किया जाए। यह ठीक है अगर आप C ++ में किसी ऑब्जेक्ट को जावा में किसी ऑब्जेक्ट पर जा रहे हैं (तुलनात्मक रूप से आसान है), लेकिन आप अपने सी ++ स्ट्रक्चर के साथ क्या करते हैं? या C ++ कक्षाओं के बाहर के कार्य? तय करना कि इसे कैसे संभालना मुश्किल हो सकता है क्योंकि इससे एक और समस्या हो सकती है, जिसका नाम है एक बूँद वस्तु का निर्माण। बूँद एक एंटीपार्टर्न है जो काफी आम है।

यह समस्याओं की पूरी सूची नहीं है, लेकिन वे सिर्फ दो हैं और वे बड़े हैं। मेरे एक प्रोफेसर ने उल्लेख किया कि किसी ने अपने नियोक्ता को आश्वस्त किया कि वे 80 के दशक में मशीन कोड से सी तक एक बना सकते हैं, लेकिन यह तब काम नहीं करता था। मुझे संदेह है कि कभी भी ऐसा होगा जो पूरी तरह से काम करता है।

Comments

मुझे लगता है कि मौजूदा पुस्तकालयों को जानने की कोई आवश्यकता नहीं है, यह सिर्फ पुस्तकालयों का अनुवाद कर सकता है क्योंकि यह जाता है (यह मानते हुए कि उनके पास स्रोत उपलब्ध हैं)।

— सर्ग

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

— indyK1ng

Lib के बारे में +1 बिंदु पूरी तरह से मान्य है, और हमेशा के लिए lib हैं।

— डेन रोसेनस्टार्क

Answer 11

संकलन की बात यह है कि कंप्यूटर के लिए कुछ उपयोगी हो। यानी कुछ ऐसा जो चल सकता है। किसी ऐसी चीज़ को क्यों संकलित करें जो आपके द्वारा लिखे गए से भी उच्च स्तर की हो सकती है?

मुझे .NET की रणनीति बेहतर लगती है। एक सामान्य भाषा में सब कुछ संकलित करें। यह उन भाषाओं का लाभ देता है जो (N ^ 2) -N क्रॉस भाषा संकलक बनाने की आवश्यकता के बिना संवाद करने में सक्षम हैं।

उदाहरण के लिए यदि आपके पास 10 प्रोग्रामिंग भाषाएं थीं, तो आपको केवल .NET मॉडल के तहत 10 कंपाइलर लिखने की आवश्यकता होगी और वे सभी एक दूसरे के साथ संवाद कर सकते हैं। यदि आपने सभी संभव क्रॉस भाषा संकलक बनाए हैं तो आपको 90 संकलक लिखने होंगे। यह बहुत कम लाभ के लिए अतिरिक्त काम है।