C++ दुभाषिए इतने कम क्यों हैं?

कृपया प्रश्न पर ब्लिंग (सी++/सीएलआई के बारे में अच्छा विचार) और मेरी टिप्पणियाँ देखें।

तथ्य यह है: CINT एक C++ दुभाषिया नहीं है। CINT एक C++ दुभाषिया नहीं है. यह यहाँ स्पष्ट रूप से कहा गया है:

CINT - Wikipedia

en.wikipedia.org

यह भाषा C और C++ पर आधारित कुछ सरलीकृत भाषा है।

यह सभी देखें: http://root.cern.ch/drupal/content/cling[^].

ऊपर संदर्भित विकिपीडिया लेख में उल्लिखित एक विकल्प, “च” के बारे में क्या ख्याल है? यह बिल्कुल C++ दुभाषिया नहीं है, यह कुछ विशेष भाषा का दुभाषिया है:
http://en.wikipedia.org/wiki/Ch_%28computer_programming%29[^],

Ch -- an embeddable C/C++ interpreter, C and C++ scripting language

www.softintegration.com

और कुछ? “पाइक”, भी केवल C और C++ पर आधारित है (विकिपीडिया यहां तक ​​कि “प्रभावित” भी कहता है):
http://en.wikipedia.org/wiki/Pike_%28programming_langage%29[^],

Home

pike.lysator.liu.se

जहाँ तक “वास्तविक” C++ भाषा का सवाल है, मेरा कुछ लोगों का मानना ​​है कि यह दुभाषिया के लिए उपयुक्त नहीं है; मेरे विचारों पर चर्चा करने के लिए विषय बहुत जटिल है जल्दी प्रश्न और उत्तर। मैं इसे यहीं साबित नहीं कर सकता और 100% निश्चित नहीं हूं, मुझे लगता है कि इसे साबित करना संभव है। अगर कोई मुझे ग़लत साबित कर दे तो मुझे बहुत आश्चर्य होगा।

उद्धरण:

मैं व्यक्तिगत रूप से केवल 1 C++ दुभाषिया के बारे में जानता हूं, जिसका उपयोग रूट (CINT, CERN में विकसित) द्वारा किया जाता है। इससे मुझे आश्चर्य हुआ कि इतने कम क्यों हैं, और स्पष्ट उत्तर यह है कि C++ पार्स करने के लिए एक बहुत ही जटिल भाषा है। सही दिमाग वाला कोई भी व्यक्ति शुरू से ही C++ पार्सर लिखने की जहमत नहीं उठाएगा…

यहां कुछ महत्वपूर्ण प्रश्न हैं: आपका लक्ष्य क्या है और C/C++ दुभाषिया उस समस्या का सबसे अच्छा (या कम से कम एक उचित रूप से अच्छा) समाधान क्यों होगा? “आपका लक्ष्य क्या है?” और “एक्स एक अच्छा समाधान क्यों है?” किसी समाधान को लागू करने में बहुमूल्य समय बर्बाद करने से पहले पूछने के लिए आम तौर पर बहुत अच्छे पहले प्रश्न होते हैं।

C/C++ कई कारणों से कंसोल आधारित व्याख्या की गई भाषा के रूप में अव्यावहारिक है और लोग आमतौर पर उन उपकरणों को लागू करने में समय बर्बाद करना पसंद नहीं करते हैं जो व्यावहारिक नहीं हैं (ठीक है, हो सकता है कि जिनके पास मौज-मस्ती करने और सीखने के लिए बहुत समय हो और/या उन लोगों के लिए) जो अव्यावहारिक पहलुओं का पूर्वाभास नहीं कर सकते)।

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

C/C++ को अग्रेषित घोषणाओं की आवश्यकता होती है। व्यावहारिक रूप से व्याख्या की गई भाषा में कोई आगे की घोषणा नहीं होती है और कोई अलग घोषणा/परिभाषाएं नहीं होती हैं। लेकिन यह एक अधिक गंभीर समस्या का एक छोटा सा हिस्सा है: C/C++ एक व्याख्यात्मक भाषा के रूप में उपयोग करने के लिए अव्यावहारिक रूप से क्रियात्मक है। यह समस्याओं का एक समूह है जिसमें भाषा डिज़ाइन समस्याएं और व्याख्या की गई भाषा के रूप में व्यावहारिक प्रयोज्य समस्याएं दोनों शामिल हैं। पायथन में मैं आसानी से एक एक्स फ़ंक्शन को परिभाषित कर सकता हूं जो अस्तित्वहीन वाई फ़ंक्शन को कॉल करता है और मुझे बाद में इस वाई फ़ंक्शन को परिभाषित करने की अनुमति है। फिर मैं एक्स निष्पादित कर सकता हूं। बाद में अगर मैं चाहूं तो मैं वाई की परिभाषा को पूरी तरह से बदल सकता हूं (शायद पिछली परिभाषा के साथ पिछड़े संगत होने के लिए कुछ नए डिफ़ॉल्ट-प्रारंभिक पैरामीटर के साथ) और एक्स का एक और निष्पादन तुरंत नई वाई परिभाषा का उपयोग करता है। मैं एक्स को निष्पादित कर सकता हूं भले ही यह एक जेड फ़ंक्शन को कॉल करता हो जिसे अभी तक परिभाषित नहीं किया गया है और यह कोई समस्या नहीं है यदि वास्तविक इनपुट पैरामीटर के साथ एक्स का निष्पादन वास्तव में उस शाखा में नहीं चलता है जो जेड को कॉल करेगा। C++ दुभाषिया क्या होता है यदि मैं एक बहुत ही बुनियादी टेम्पलेट (उदाहरण: गतिशील सरणी) की परिभाषा बदल देता हूं जिसका उपयोग पहले से परिभाषित कई कार्यों (उदाहरण के लिए इनलाइन फ़ंक्शन के रूप में) द्वारा किया जाता है? आप कैसे पता लगाएंगे कि नए इनलाइन फ़ंक्शंस का उपयोग करने के लिए आपके दुभाषिया के अंदर कौन से कोडब्लॉक को पुन: संकलन की आवश्यकता है? यदि नई परिभाषा के साथ इनमें से कुछ कार्यों का पुनर्संकलन विफल हो जाए तो क्या होगा? आपको पाइथॉन जैसी गतिशील भाषाओं के साथ इस तरह की गंभीर समस्याएं नहीं होती हैं। एक गैर-गतिशील दुभाषिया में ऐसे परिदृश्यों से निपटना एक बड़ी समस्या होगी, और ये केवल दो “सरल/बुनियादी” समस्याएं थीं, यह केवल हिमशैल का टिप है। मैं एक दशक से अधिक समय से C/C++ प्रोग्रामिंग कर रहा हूं और मुझे कभी भी C/C++ दुभाषिया की आवश्यकता महसूस नहीं हुई।

उद्धरण:

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

मैंने उत्तर लिखना शुरू किया लेकिन यह बहुत लंबा और जटिल हो गया क्योंकि इसमें कई अलग-अलग अनुभागों में आपकी समस्या का विश्लेषण किया गया था। इसके बजाय मैं यहां अपने कुछ निष्कर्ष लिख रहा हूं।

आपको उन प्रश्नों का उत्तर देना चाहिए जो मैंने पिछले पैराग्राफ में पोस्ट किए हैं। आपके प्रश्न से मुझे लगता है कि शायद आपका लक्ष्य केवल सृजन करना है ए कम से कम काम के निवेश के साथ C++ दुभाषिया – मैं इसे इसलिए मानता हूं क्योंकि आप मौजूदा कंपाइलरों से सामग्री (संकलन इकाइयां, ऑब्जेक्ट फ़ाइलें) का पुन: उपयोग करना चाहते हैं। इसके साथ मेरी समस्या यह है कि लोग “कम से कम मेहनत” के साथ कुछ करते हैं जब उन्हें कुछ ऐसा करना पड़ता है जो उन्हें पसंद नहीं है। दूसरी ओर अगर वे शौक के तौर पर या किसी खास मकसद से सिर्फ मनोरंजन के लिए कुछ करते हैं तो उन्हें आमतौर पर बहुत सारा काम करने में कोई आपत्ति नहीं होती। सी/सी++ दुभाषिया के मामले में सभी समाधानों में बहुत सारा काम शामिल लगता है।

कंपाइलर और कंपाइलर सेटिंग्स के आधार पर ऑब्जेक्ट फ़ाइलों में आपकी आवश्यकता के अलावा कुछ और हो सकता है। वे मानकीकृत नहीं हैं और यहां तक ​​कि एक ही कंपाइलर कुछ सेटिंग्स (जैसे एलटीसीजी) के साथ उनमें पूरी तरह से बेकार कचरा डाल सकता है। IMO ऑब्जेक्ट फ़ाइलों से इसे पार्स करने का प्रयास करने के बजाय आपको जो चाहिए उसे उत्सर्जित करने के लिए बैकएंड लिखना अधिक व्यावहारिक होगा।

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

C से C++ में अंतर C++ मानक में बताया गया है:

C द्वारा प्रदान की गई सुविधाओं के अलावा, C++ अतिरिक्त डेटा प्रकार, कक्षाएं, टेम्पलेट, अपवाद, नेमस्पेस, ऑपरेटर ओवरलोडिंग, फ़ंक्शन नाम ओवरलोडिंग, संदर्भ, मुफ्त स्टोर प्रबंधन ऑपरेटर और अतिरिक्त लाइब्रेरी सुविधाएं प्रदान करता है।

यदि C++11 पर जा रहे हैं, तो आप लैम्ब्डा अभिव्यक्ति और कई अन्य भागों को जोड़ सकते हैं, सभी मुख्य रूप से वाक्यात्मक चीनी इस अर्थ में कि वे कुछ ऐसा अमूर्त करते हैं जो मुख्य रूप से पार्सर से संबंधित है और अन्य तरीकों से भी किया जा सकता है (यदि थकाऊ नहीं है)।

उपरोक्त सुविधाओं को पार्स करने से रनटाइम आइटम के रूप में क्या परिणाम मिलते हैं
– अतिरिक्त डेटा प्रकार: कुछ और अंतर्निहित चार/संख्यात्मक प्रकार
– क्लास: विस्तारित इंस्टेंस फ़ंक्शंस के साथ this पैरामीटर
– वर्ग: व्युत्पन्न वर्ग के उप-वस्तु के रूप में आधार वर्ग के साथ विरासत
– वर्ग: विशेष अंतर्निहित फ़ंक्शन कॉल (सीटीआर, डीटीओआर, आदि)
– वर्ग: वर्चुअल फ़ंक्शन कॉल के लिए vtable
– वर्ग: परिभाषाओं का क्रम (ज्यादातर) कक्षाओं में मायने नहीं रखता – केवल नाम लुकअप प्रभावित होता है
– टेम्प्लेट: प्रकार या स्थिर अभिन्न मानों के आधार पर उत्पन्न कक्षाएं या फ़ंक्शन
– अपवाद: अतिरिक्त नियंत्रण प्रवाह और विशेष रूप से सफाई-बहीखाता कोड
– नामस्थान: “वाक्यविन्यास शर्करा” (अद्वितीय प्रकार, वस्तुएं, फ़ंक्शन परिभाषित और बुलाए जाते हैं)
– ओवरलोडिंग: “सिंटैक्टिक शुगर” (पार्सर सही कार्यों के लिए कॉल बनाता है)
– संदर्भ: “सिंटैक्टिक शुगर”, जिसके परिणामस्वरूप पॉइंटर्स या कोई रनटाइम कोड नहीं होता है
– नया/डिलीट: निम्न स्तर की मेमोरी मॉलोक/फ्री प्लस सीटीओआर/डीटीओआर कॉल
– पुस्तकालय: भाषा सुविधाओं पर आधारित वस्तुओं का संग्रह
– लैम्ब्डा अभिव्यक्ति: “सिंटेक्टिक शुगर” (अंतर्निहित फ़ंक्टर वर्ग)
– …

इसमें विस्तृत विवरण संबंधी कठिन समस्याएं हैं जिन्हें दूर करना है, लेकिन तकनीकी रूप से इसे बहुत विस्तारित सी के रूप में माना जा सकता है।

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

लेकिन फिर, प्रयास को उचित ठहराना काफी हद तक संभावित “लाभ” पर निर्भर करता है।

प्रोत्साहित करना
और मैं

क्योंकि C++ एक विशाल प्रोग्रामिंग भाषा है। यह बहुत जटिल है. पायथन, जावास्क्रिप्ट जैसी भाषाओं के लिए दुभाषिए बनाए जाते हैं, न केवल वे सरल होते हैं, बल्कि वे व्याख्या के लिए होते हैं, वे गतिशील होते हैं। पहला पायथन कार्यान्वयन एक दुभाषिया था; संकलक नहीं. सिर्फ यही वजह नहीं है. यह पहले से ही ज्ञात है कि C++ “संकलित” होने पर व्याख्या की गई भाषाओं की तुलना में तेज़ है। लेकिन आप C++ दुभाषिया से हमेशा ऐसी ही उम्मीद नहीं कर सकते। C++ संदर्भ संवेदनशील है; C++ बहुत बड़ा है; C++ में जेनरिक शामिल हैं। इस प्रकार, भाषा की जटिलता स्रोत कोड की धीमी प्रोसेसिंग में योगदान करती है। उदाहरण के लिए, C++ की संकलन गति देखें। यदि आप स्रोत की व्याख्या करेंगे तो क्या होगा? ऐसा कहा जा रहा है कि, एक क्लासिक “हैलो वर्ल्ड” कार्यक्रम में कुछ समय नहीं लग सकता है। लेकिन सामान्य तकनीकों के भारी उपयोग वाले कार्यक्रम के बारे में सोचें?

लेकिन फिर भी CINT, Ch जैसे कुछ दुभाषिए मौजूद हैं। निम्नलिखित पृष्ठ देखें:

Attention Required! | Cloudflare

stackoverflow.com

इस प्रश्न को वास्तव में “हल” करना कठिन है – हो सकता है कि किसी फ़ोरम में यह बेहतर होता, लेकिन यहाँ मेरा 2सी है।

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

संक्षेप में, यह बहुत सारा काम होगा, और कुत्ते की तरह दौड़ेगा।