118

अगर कुछ उत्पन्न किया जा सकता है, तो वह चीज डेटा है, कोड नहीं।

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

यदि यह प्रदर्शन कारणों से किया जा रहा है, तो यह संकलक की कमी की तरह लगता है।

यदि इसे दो भाषाओं को जोड़ने के लिए किया जा रहा है, तो यह इंटरफ़ेस लाइब्रेरी की कमी की तरह लगता है।

क्या मुझसे कोई चूक हो रही है?

मुझे पता है कि कोड डेटा भी है। जो मुझे समझ नहीं आ रहा है, वह स्रोत कोड क्यों है ? क्यों इसे एक समारोह में नहीं बनाया जाए जो मापदंडों को स्वीकार कर सके और उन पर कार्रवाई कर सके?

anti-patterns code-generation

— Utku
स्रोत

11

कोड की पीढ़ी के साथ जुड़े एक शब्द है metaprogramming

— UselesssCat

4

en.wikipedia.org/wiki/Code_as_data , लिस्प, एफपी, पटकथा, metaprogramming, वॉन Neumann / संशोधित हार्वर्ड वास्तुकला आदि यह कवर किया गया है बारंबार । tl; dr; डिस्टिंक्शन "सोर्स कोड" बनाम "आउटपुट कोड", "कोड" बनाम "डेटा" आदि चीजों को सरल बनाने के लिए हैं। उन्हें कभी भी हठधर्मिता नहीं करनी चाहिए ।

— vaxquis

9

@Utku, कोड जनरेशन करने के बेहतर कारण अक्सर आपकी वर्तमान भाषा द्वारा व्यक्त किए जा सकने वाले उच्च-स्तरीय विवरण प्रदान करने की इच्छा से संबंधित होते हैं । कंपाइलर सक्षम कोड बना सकता है या नहीं, इससे वास्तव में कोई लेना-देना नहीं है। पार्सर जनरेटर्स पर विचार करें - एक लेक्सर द्वारा उत्पन्न flexया एक पार्सर द्वारा उत्पन्न bisonलगभग निश्चित रूप से अधिक अनुमानित, अधिक सही होगा, और अक्सर सी में लिखे गए हाथों की तुलना में निष्पादित करने के लिए तेज़ होगा; और बहुत कम कोड से निर्मित (इस प्रकार बनाए रखने के लिए भी कम काम किया जा रहा है)।

— चार्ल्स डफी

1

हो सकता है कि आप एक ऐसी भाषा से आते हैं जिसमें कई कार्यात्मक तत्व नहीं हैं, लेकिन कई भाषाओं में फ़ंक्शंस प्रथम श्रेणी में हैं - आप उन्हें पास कर सकते हैं, इसलिए उन प्रकार की भाषाओं में कोड डेटा है, और आप इसे उसी तरह से मान सकते हैं।

— रेस्टिओसन

1

एक कार्यात्मक भाषा कोड में @Restioson डेटा नहीं है। प्रथम श्रेणी के कार्यों का ठीक यही अर्थ है कि: कार्य डेटा हैं। और जरूरी नहीं कि विशेष रूप से अच्छा डेटा: आप जरूरी नहीं कि उन्हें केवल थोड़ा सा बदल सकते हैं (जैसे कि कार्यों में सभी अतिरिक्त जोड़-घटाव, कहिए)। कोड होम्योनिक भाषाओं में डेटा है। (अधिकांश होमोसेक्सुअल भाषाओं में प्रथम श्रेणी के कार्य होते हैं। लेकिन रिवर्स सच नहीं है।)

— लिंडन व्हाइट

149

क्या सोर्स कोड जनरेशन एक एंटी पैटर्न है?

तकनीकी रूप से, यदि हम कोड उत्पन्न करते हैं, तो यह स्रोत नहीं है भले ही यह पाठ है जो मनुष्यों द्वारा पठनीय है। सोर्स कोड मूल कोड है, जो मानव या अन्य सच्ची बुद्धिमत्ता से उत्पन्न होता है, यंत्रवत् रूप से अनुवादित नहीं (सच्चा) स्रोत (प्रत्यक्ष या अप्रत्यक्ष रूप से) से प्रतिलिपि प्रस्तुत करने योग्य नहीं।

यदि कुछ उत्पन्न किया जा सकता है, तो वह चीज डेटा है, न कि कोड।

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

प्रोसेसर मेमोरी से निर्देशों को निष्पादित करता है। वही मेमोरी जो डेटा के लिए उपयोग की जाती है। इससे पहले कि प्रोसेसर निर्देशों को निष्पादित करता है, प्रोग्राम को डेटा के रूप में मेमोरी में लोड किया जाता है ।

तो, सब कुछ डेटा है , यहां तक कि कोड भी ।

यह देखते हुए कि [जनरेट किया गया कोड डेटा है], क्या यह कोड जनरेशन की पूरी समझ नहीं है?

संकलन में कई चरणों का होना पूरी तरह से ठीक है, जिनमें से एक पाठ के रूप में मध्यवर्ती कोड पीढ़ी हो सकता है।

यही है, अगर किसी चीज़ के लिए एक कोड जनरेटर है, तो क्यों नहीं उस चीज़ को एक उचित फ़ंक्शन बनाते हैं जो आवश्यक पैरामीटर प्राप्त कर सकता है और सही क्रिया करता है जो "उत्पन्न" कोड होगा?

यह एक तरीका है, लेकिन अन्य हैं।

कोड जनरेशन का आउटपुट टेक्स्ट होता है, जिसे मानव द्वारा उपयोग की जाने वाली डिज़ाइन के अनुसार बनाया जाता है।

सभी पाठ रूप मानव उपभोग के लिए नहीं हैं। विशेष रूप से, उत्पन्न कोड (पाठ के रूप में) आमतौर पर संकलक उपभोग के लिए होता है न कि मानव उपभोग के लिए।

स्रोत कोड को मूल माना जाता है: मास्टर - जिसे हम संपादित करते हैं और विकसित करते हैं; स्रोत कोड नियंत्रण का उपयोग करके हम क्या संग्रह करते हैं। जेनरेट किया गया कोड, यहां तक कि जब मानव-पठनीय पाठ, आमतौर पर मूल स्रोत कोड से पुनर्जीवित होता है । उत्पन्न कोड, आम तौर पर बोल रहा है, स्रोत नियंत्रण में नहीं होना चाहिए क्योंकि यह निर्माण के दौरान पुनर्जीवित होता है।

— एरिक Eidt
स्रोत

1

टिप्पणियाँ विस्तारित चर्चा के लिए नहीं हैं; इस वार्तालाप को बातचीत में स्थानांतरित कर दिया गया है ।

— maple_shaft

65

व्यावहारिक तर्क

ठीक है, मुझे पता है कि कोड डेटा भी है। जो मुझे समझ नहीं आ रहा है, वह स्रोत कोड क्यों है?

इस संपादन से, मुझे लगता है कि आप सैद्धांतिक कंप्यूटर विज्ञान नहीं बल्कि व्यावहारिक स्तर पर पूछ रहे हैं।

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

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

(हां, आप मक्खी पर बायटेकोड उत्पन्न कर सकते हैं, लेकिन जावा में इस तरह की प्रोग्रामिंग कुछ ऐसा नहीं होगा जो एक यादृच्छिक प्रोग्रामर सिर्फ डोमेन कोड की कुछ पंक्तियों को लिखने के लिए इनबेटिवन करेगा।)

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

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

— AnoE
स्रोत

1

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

— पैंजरक्रिसिस

इन दिनों, क्या जावा में डीबी से डायनेमिक टेबल बनाना संभव है? या केवल एक ORM का उपयोग करके?

— नौमेनन

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

— चरण

1

"एक चार सरणी आवंटित करें, इसे मशीन कोड से भरें और फिर एक पॉइंटर को पहले पॉइंटर से एक फ़ंक्शन पॉइंटर में डालें और फिर इसे डालें?" अपरिभाषित व्यवहार होने के अलावा, यह C ++ "फ्लाई पर बायटेकोड उत्पन्न" के बराबर है। यह "साधारण प्रोग्रामर द्वारा विचार नहीं किया गया" की एक ही श्रेणी में आता है

— कैलथ

1

@ चरण, "निश्चित रूप से यह C ++ में दो दशकों से अधिक संभव है" ... मुझे थोड़ा चकनाचूर करना पड़ा; यह लगभग 2ish दशक का है क्योंकि मैंने C ++ को अंतिम बार कोड किया था। :) लेकिन C ++ के बारे में मेरा वाक्य बुरी तरह से तैयार किया गया था। मैंने इसे थोड़ा बदल दिया है, यह स्पष्ट होना चाहिए कि मेरा क्या मतलब था, अब।

— AnoE

44

कोड क्यों जनरेट करें?

क्योंकि पंच कार्ड (या नोटपैड में अल्ट कोड ) के साथ प्रोग्रामिंग एक दर्द है।

यदि यह प्रदर्शन कारणों से किया जा रहा है, तो यह संकलक की कमी की तरह लगता है।

सच। जब तक मुझे मजबूर नहीं किया जाता मुझे प्रदर्शन की परवाह नहीं है।

यदि इसे दो भाषाओं को जोड़ने के लिए किया जा रहा है, तो यह इंटरफ़ेस लाइब्रेरी की कमी की तरह लगता है।

हम्म, कोई बात नहीं तुम किस बारे में बात कर रहे हो।

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

जो तब तक ठीक है जब तक मुझे इसे बनाए रखना है। किस बिंदु पर आप सभी मर सकते हैं।

क्या यह एक विरोधी पैटर्न है? आह, नहीं। यदि हम पिछली भाषाओं की कमियों को अलविदा कहने को तैयार नहीं थे और पुरानी भाषाओं का कोड जनरेट करना चाहते हैं तो कई भाषाएँ मौजूद नहीं होंगी।

यह एक कोड आधार है जिसे आधे परिवर्तित फ्रेंकस्टीन राक्षस पैचवर्क में छोड़ दिया जाता है जिसे मैं खड़ा नहीं कर सकता। उत्पन्न कोड अछूत कोड है। मुझे अछूत कोड को देखने से नफरत है। फिर भी लोग इसे जाँचते रहते हैं। क्यों? आप निष्पादन योग्य में जाँच कर सकते हैं।

खैर अब मैं रेंटिंग कर रहा हूं। मेरा कहना है कि हम सभी "जनरेटिंग कोड" हैं। जब आप स्रोत कोड की तरह उत्पन्न कोड का इलाज करते हैं, तो आप मुझे पागल बना रहे हैं। कारण यह है कि ऐसा लगता है कि स्रोत कोड इसे स्रोत कोड नहीं बनाता है।

— candied_orange
स्रोत

41

यदि आप इसे जनरेट करते हैं, तो यह SOURCE कोड नहीं है। यह मध्यवर्ती कोड है। मैं अब रोने जा रहा हूं।

— कैंडिड_ओरेंज 5

65

ARG !!! इससे कोई फर्क नहीं पड़ता कि यह कैसा दिखता है !!! पाठ, बाइनरी, डीएनए, अगर यह SOURCE नहीं है तो यह वह नहीं है जिसे आपको बदलाव करते समय छूना चाहिए। यदि मेरी संकलन प्रक्रिया में 42 मध्यवर्ती भाषाएँ हैं, जिनसे यह गुजरता है, तो यह कोई व्यवसाय नहीं है। उन्हें छूना बंद करो। उन्हें चेक करना बंद करें। स्रोत पर अपने परिवर्तन करें।

— कैंडिड_ऑरेंज 5

24

XML पाठ है और यह स्पष्ट रूप से मानव उपभोग के लिए नहीं है। :-)

— निक कीघले

38

@utku: "यदि किसी चीज का मानव द्वारा उपभोग नहीं किया जाता है, तो उसे पाठ नहीं होना चाहिए": मैं पूरी तरह से असहमत हूं। मेरे सिर के शीर्ष पर कुछ काउंटर-उदाहरण: HTTP प्रोटोकॉल, MIME एनकोडिंग, PEM फाइलें - बहुत अधिक कुछ भी जो कहीं भी 6464 का उपयोग करता है। 7-बिट सुरक्षित स्ट्रीम में डेटा को एन्कोड करने के बहुत सारे कारण हैं, भले ही किसी भी मानव को इसे कभी नहीं देखना चाहिए। उन चीजों का ज्यादा बड़ा स्थान नहीं बताया गया है, जो आम तौर पर मनुष्य को कभी भी बातचीत नहीं करनी चाहिए, लेकिन वे कभी-कभार चाहते हैं: लॉग फाइल, /etc/यूनिक्स पर फाइलें, आदि

— डैनियल प्राइडेन

12

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

— सोलोमन स्लो

41

क्यों स्रोत कोड उत्पन्न करते हैं

कोड जनरेटर के लिए मुझे सबसे अधिक उपयोग के मामले में अपने कैरियर के साथ काम करना था जो जनरेटर थे

इनपुट के रूप में कुछ प्रकार के डेटा मॉडल या डेटाबेस स्कीमा के लिए कुछ उच्च स्तरीय मेटा-विवरण लिया (शायद एक संबंधपरक स्कीमा, या किसी प्रकार का XML स्कीमा)
और आउटपुट के रूप में डेटा एक्सेस कक्षाओं के लिए बॉयलर-प्लेट सीआरयूडी कोड का उत्पादन किया, और शायद इसी एसक्यूएल या प्रलेखन जैसी अतिरिक्त चीजें।

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

मुझे आपके प्रारंभिक प्रश्न का उत्तर भी दें

क्या सोर्स कोड जेनरेशन एक एंटी पैटर्न है

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

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

— डॉक्टर ब्राउन
स्रोत

मैं इस जवाब से सहमत हूं। जावा के लिए टॉर्क जैसी किसी चीज का उपयोग करते हुए, मैं java सोर्स फाइल्स का ऑटोमैटिक जेनरेशन कर सकता हूं, जिसमें sql डेटाबेस से मेल खाते हुए फील्ड हैं। यह क्रूड ऑपरेशन को और अधिक आसान बनाता है। प्रमुख लाभ प्रकार की सुरक्षा है, जिसमें केवल उन संदर्भ क्षेत्रों को सक्षम करना शामिल है जो डेटाबेस में मौजूद हैं (धन्यवाद आप स्वतः पूर्ण)।

— एमटी

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

— पाओलो एबरमन

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

— मातरिनस

13

क्यों स्रोत कोड उत्पन्न?

मैंने जनरेट के लिए दो उपयोग के मामलों का सामना किया है (निर्माण समय पर, और कभी भी जाँच नहीं की गई) कोड:

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

— Maybe_Factor
स्रोत

15

अनुभवहीन भाषाओं में अत्यधिक दोहराव वाला कोड। उदाहरण के लिए मुझे कोड लिखना था जो आवश्यक समान कई समान लेकिन समान डेटा संरचनाओं पर नहीं था। यह शायद एक C ++ टेम्पलेट की तरह कुछ के साथ किया जा सकता है ( वह कोड पीढ़ी नहीं है ?)। लेकिन मैं सी का उपयोग कर रहा था। कोड पीढ़ी ने मुझे समान कोड के बहुत सारे लिखने से बचाया।

— निक कीघले

1

@NickKeighley शायद आपका टूलकिन आपको एक और अधिक उपयुक्त भाषा का उपयोग करने की अनुमति नहीं दे रहा था?

— विल्सन

7

आपको आमतौर पर अपनी कार्यान्वयन भाषा चुनने और चुनने की ज़रूरत नहीं है। परियोजना सी में थी, यह एक विकल्प नहीं था।

— निक कीघले

1

@Wilson अधिक अभिव्यंजक भाषाएँ अक्सर कोड जनरेशन (जैसे लिस्प मैक्रो, रेल पर रूबी) का उपयोग करती हैं, उन्हें इस बीच पाठ के रूप में सहेजने की आवश्यकता नहीं होती है।

— पीट किर्कम

4

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

— शॉन बर्टन

13

सुस्मैन ने अपने क्लासिक "कंप्यूटर प्रोग्राम की संरचना और व्याख्या" में ऐसी चीजों के बारे में कहना बहुत दिलचस्प था, मुख्य रूप से कोड-डेटा द्वंद्व के बारे में।

मेरे लिए एडहॉक कोड जेनरेशन का प्रमुख उपयोग कुछ छोटे डोमेन विशिष्ट भाषा को कुछ ऐसे में बदलने के लिए उपलब्ध कंपाइलर का उपयोग कर रहा है जिसे मैं अपने कार्यक्रमों में लिंक कर सकता हूं। बीएनएफ सोचो, एएसएन 1 सोचो (वास्तव में, ऐसा नहीं है, यह बदसूरत है), डेटा डिक्शनरी स्प्रेडशीट सोचो।

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

पाठ को आउटपुट करने के बाद जो कि कुछ सिस्टम कंपाइलर को खिलाया जाता है, मुझे लगता है कि इसके बिना कम्पाइलर ऑप्टिमाइज़ेशन और सिस्टम स्पेसिफिक कॉन्फिगरेशन के सभी मिल जाते हैं।

मैं केवल एक अन्य मध्यवर्ती प्रतिनिधित्व के रूप में संकलक इनपुट भाषा का प्रभावी ढंग से उपयोग कर रहा हूं, समस्या क्या है? पाठ फ़ाइलें स्वाभाविक रूप से स्रोत कोड नहीं हैं, वे एक संकलक के लिए एक आईआर हो सकते हैं , और यदि वे सी या सी ++ या जावा या जो कुछ भी हो, की तरह दिखने के लिए होता है?

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

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

सिमुलिंक में मॉडल बनाने और फिर आरटीडब्ल्यू के साथ सी उत्पन्न करने के साथ एक ही बात फिर जो भी उपकरण समझ में आता है उसके साथ लक्षित करना, मध्यवर्ती सी अपठनीय है, तो क्या? उच्च स्तरीय Matlab RTW सामान को केवल C का सबसेट पता होना चाहिए, और C संकलक प्लेटफ़ॉर्म विवरण का ध्यान रखता है। उत्पन्न C के माध्यम से मानव को केवल एक बार ऐसा करना पड़ता है जब RTW स्क्रिप्ट में बग होता है, और उस प्रकार की चीज़ों को नाममात्र मानव पठनीय IR के साथ डीबग करना आसान होता है और फिर केवल बाइनरी पार्स ट्री के साथ।

आप निश्चित रूप से ऐसी चीजों को आउटपुट बायटेकोड या यहां तक कि निष्पादन योग्य कोड में लिख सकते हैं, लेकिन आप ऐसा क्यों करेंगे? हमें उन चीजों के लिए एक आईआर परिवर्तित करने के लिए उपकरण मिले।

— दान मिल्स
स्रोत

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

— डैनियल प्रीडेन

2

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

— दान मिल्स

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

— डैनियल प्राइडेन

2

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

— डैन मिल्स

1

"वे आम तौर पर विपणन में काम करके अधिक खुश होते हैं" कैट्टी, लेकिन मजाकिया।

— dmckee

13

व्यावहारिक जवाब: कोड पीढ़ी आवश्यक और उपयोगी है? क्या यह कुछ ऐसा प्रदान करता है जो वास्तव में बहुत उपयोगी है और मालिकाना कोडबेस के लिए आवश्यक है, या क्या यह सिर्फ चीजों को करने का एक और तरीका है जिससे उप-इष्टतम परिणामों के लिए अधिक बौद्धिक ओवरहेड का योगदान होता है?

ठीक है, मुझे पता है कि कोड डेटा भी है। मुझे समझ में नहीं आता है, क्यों कोड उत्पन्न करते हैं? क्यों इसे एक समारोह में नहीं बनाया जाए जो मापदंडों को स्वीकार कर सके और उन पर कार्रवाई कर सके?

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

इस बीच अगर आप OpenShadingLanguage जैसी कोई चीज़ लेते हैं: https://github.com/imageworks/OpenShadingLanguage

... तो ऐसे प्रश्नों को उठाने की जरूरत नहीं है क्योंकि वे प्रभावशाली परिणामों द्वारा तुरंत उत्तर दिए जाते हैं।

OSL मक्खी पर मशीन कोड में शेडर नेटवर्क (बस समय में, या "JIT") में अनुवाद करने के लिए LLVM कंपाइलर फ्रेमवर्क का उपयोग करता है, और इस प्रक्रिया में शेडर नेटवर्क और शेडर मापदंडों और अन्य रनटाइम के पूर्ण ज्ञान के साथ नेटवर्क का अनुकूलन करता है जो नहीं कर सकता था पता चला है कि जब स्रोत कोड से छायांकन संकलित किया गया था। नतीजतन, हम अपने OSL छायांकन नेटवर्क को C में समतुल्य हाथ से तैयार किए गए समतुल्य की तुलना में 25% तेजी से निष्पादित करते हैं! (यही कि हमारे पुराने शेडर्स हमारे रेंडर में काम करते हैं।)

ऐसे मामले में आपको कोड जनरेटर के अस्तित्व पर सवाल उठाने की जरूरत नहीं है। यदि आप इस प्रकार के वीएफएक्स डोमेन में काम करते हैं, तो आपकी तत्काल प्रतिक्रिया आमतौर पर "मेरे पैसे बंद करो और ले लो" की तर्ज पर अधिक है! या, "वाह, हमें भी कुछ ऐसा बनाने की जरूरत है।"

— marstato
स्रोत

मशीन कोड में shader नेटवर्क का अनुवाद करें । यह एक कोड जनरेटर के बजाय एक संकलक की तरह लगता है, नहीं?

— उत्कर्ष

2

यह मूल रूप से उपयोगकर्ता को एक नोडल नेटवर्क लेता है और मध्यस्थ कोड बनाता है जो LLVM द्वारा JIT संकलित किया जाता है। कंपाइलर और कोड जनरेटर के बीच का अंतर एक प्रकार का फजी है। क्या आप C ++ या C प्रीप्रोसेसर में टेम्प्लेट जैसी भाषाओं में कोड जनरेशन फीचर्स की तर्ज पर अधिक सोच रहे थे?

मैं किसी भी जनरेटर के बारे में सोच रहा था जो स्रोत कोड का उत्पादन करेगा।

— उत्कर्ष

मैं देखता हूं, जहां मानव उपभोग के लिए आउटपुट अभी भी है। OpenSL भी मध्यस्थ स्रोत कोड उत्पन्न करता है, लेकिन यह निम्न स्तर का कोड है जो LLVM खपत के लिए विधानसभा के करीब है। यह आमतौर पर कोड नहीं है जिसे बनाए रखा जाना चाहिए (इसके बजाय प्रोग्रामर कोड उत्पन्न करने के लिए उपयोग किए जाने वाले नोड्स को बनाए रखते हैं)। अधिकांश समय मुझे लगता है कि कोड जनरेटर के उन प्रकारों को उनके मूल्य को सही ठहराने के लिए उपयोगी से अधिक दुरुपयोग होने की संभावना है, खासकर यदि आपको लगातार अपनी निर्माण प्रक्रिया के हिस्से के रूप में कोड को पुन: उत्पन्न करना है। कभी-कभी उनके पास कमियों को दूर करने के लिए अभी भी एक वास्तविक स्थान होता है ...

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

8

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

मध्यवर्ती मानव-पठनीय कोड कभी न होने का ऐतिहासिक प्रभाव

आइए C और C ++ को उदाहरण के रूप में लेते हैं क्योंकि वे सबसे प्रसिद्ध भाषाओं में से हैं।

आपको ध्यान रखना चाहिए कि C कोड के संकलन का तार्किक जुलूस मशीन कोड नहीं बल्कि मानव-पढ़ने योग्य विधानसभा कोड को आउटपुट करता है। इसी तरह, पुराने C ++ कंपाइलर C कोड में C ++ कोड का भौतिक रूप से संकलन करते थे। घटनाओं की उस श्रृंखला में, आप मानव पठनीय कोड 1 से मानव पठनीय कोड 2 से मानव पठनीय कोड 3 से मशीन कोड तक संकलित कर सकते हैं। "क्यों?" क्यों नहीं?

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

मध्यवर्ती मानव-पठनीय कोड का उपयोग क्यों करें?

कभी-कभी मध्यवर्ती कोड वांछित होता है ताकि आप भवन में अगले चरण से पहले इसे संशोधित कर सकें। मैं स्वीकार करूंगा कि यह बिंदु सबसे कमजोर है।
कभी-कभी ऐसा इसलिए होता है क्योंकि मूल काम किसी भी मानव-पठनीय भाषा में नहीं किया गया था, बल्कि इसके बजाय जीयूआई मॉडलिंग टूल में किया गया था।
कभी-कभी आपको कुछ बहुत दोहराव करने की आवश्यकता होती है, और भाषा को उस चीज़ को पूरा नहीं करना चाहिए जो आप कर रहे हैं क्योंकि यह एक ऐसी आला चीज है या ऐसी जटिल चीज है कि इसका कोई व्यवसाय नहीं है जिससे जटिलता या प्रोग्रामिंग भाषा का व्याकरण सिर्फ समायोजित हो सके आप।
कभी-कभी आपको कुछ बहुत दोहराव करने की आवश्यकता होती है, और जो आप चाहते हैं उसे सामान्य तरीके से भाषा में प्राप्त करने का कोई संभव तरीका नहीं है ; या तो इसका प्रतिनिधित्व नहीं किया जा सकता है या भाषा के व्याकरण के साथ टकराव होता है।
कंप्यूटर के लक्ष्यों में से एक मानव प्रयास को कम करना है, और कभी-कभी कोड को कभी भी फिर से छूने की संभावना नहीं है (रखरखाव की कम संभावना) मेटा-कोड को दसवें समय में आपके लंबे कोड को बनाने के लिए लिखा जा सकता है; मैं 1 दिन के बजाय 2 सप्ताह में यह कर सकते हैं और यह अब तक बनाए रखा होने की संभावना नहीं है, तो मैं बेहतर यह उत्पन्न करता है, तो - और बंद मौका पर है कि किसी को अब से 5 साल नाराज है क्योंकि वे वास्तव में करते हैं तो इसे बनाए रखने की जरूरत है, वे 2 सप्ताह इसे पूरी तरह से लिखने में बिता सकते हैं यदि वे चाहते हैं, या अजीब कोड बनाए रखने के 1 सप्ताह तक नाराज हो सकते हैं (लेकिन हम अभी भी उस बिंदु पर 1 सप्ताह आगे हैं), और यह है कि अगर रखरखाव की आवश्यकता है ।
मुझे यकीन है कि अधिक कारण हैं जिनकी मैं अनदेखी कर रहा हूं।

उदाहरण

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

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

इसके अलावा, एक स्प्रेडशीट में सभी डेटा एक तरह से अच्छा था: इसने हमें उन तरीकों से डेटा का प्रतिनिधित्व करने की अनुमति दी जो हमारे पास नहीं हो सकते थे यदि यह सभी स्रोत कोड फ़ाइलों में थे।

उदाहरण 2

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

और कैसे होना चाहिए था? शायद आप दूसरे तरीके से आ सकते हैं; शायद अन्य तरीके हैं। लेकिन उस काम के लिए, अन्य तरीके उत्पन्न लैक्स / पार्स कोड से बेहतर नहीं होंगे जो मेरे पास थे।

— हारून
स्रोत

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

— पूजा

7

जो आप मिस कर रहे हैं उसका पुनः उपयोग है ।

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

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

पाठ केवल कुछ ऐसा नहीं है जिसे मनुष्य पढ़े और लिखे। कंप्यूटर पूरी तरह से पाठ के साथ घर पर भी हैं। वास्तव में XML (और अन्य संबंधित प्रारूप) जैसे प्रारूप सफल होते हैं क्योंकि वे सादे पाठ का उपयोग करते हैं। बाइनरी फ़ाइल प्रारूप अक्सर अस्पष्ट और खराब-दस्तावेज होते हैं, और एक पाठक आसानी से पता नहीं लगा सकता है कि वे कैसे काम करते हैं। XML अपेक्षाकृत स्व-दस्तावेजीकरण है, जिससे लोगों के लिए कोड लिखना आसान हो जाता है जो XML- स्वरूपित फ़ाइलों का उपयोग करता है। और सभी प्रोग्रामिंग भाषाओं को पाठ फ़ाइलों को पढ़ने और लिखने के लिए सेट किया गया है।

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

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

— ग्राहम
स्रोत

फिर भी XML की पाठ-आधारितता का लाभ सिर्फ इतना है कि यदि आवश्यक हो , तो इसे मनुष्यों द्वारा पढ़ा और लिखा जा सकता है (वे आम तौर पर एक बार काम करने पर परेशान नहीं करते हैं, लेकिन निश्चित रूप से विकास के दौरान करते हैं)। प्रदर्शन और अंतरिक्ष-दक्षता के संदर्भ में, द्विआधारी प्रारूप आमतौर पर बहुत बेहतर होते हैं (जो बहुत बार हालांकि कोई फर्क नहीं पड़ता, क्योंकि अड़चन कहीं और है)।

— लेफ्टरनैबाउट

@leftaroundabout यदि आपको उस प्रदर्शन और स्थान-दक्षता की आवश्यकता है, तो सुनिश्चित करें। इन दिनों XML-आधारित प्रारूपों में कई एप्लिकेशन चले गए हैं, इसलिए यह है कि प्रदर्शन और अंतरिक्ष-दक्षता शीर्ष मानदंड नहीं हैं जो वे एक बार थे, और इतिहास ने दिखाया है कि खराब बाइनरी फ़ाइल प्रारूप को कैसे बनाए रखा जाता है। (पुराने एमएस वर्ड दस्तावेज़ एक क्लासिक उदाहरण के लिए!) हालांकि यह बात बनी हुई है - पाठ केवल कंप्यूटर के रूप में मनुष्यों के रूप में पढ़ने के लिए अनुकूल है।

— ग्राहम

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

— लेफ्टरनैबाउट

7

एक और अधिक व्यावहारिक जवाब का एक सा, क्यों और क्या स्रोत कोड नहीं है पर ध्यान केंद्रित कर रहा है। ध्यान दें कि स्रोत कोड उत्पन्न करना इस सभी मामलों में निर्माण प्रक्रिया का एक हिस्सा है - इसलिए उत्पन्न फ़ाइलों को स्रोत नियंत्रण में अपना रास्ता नहीं खोजना चाहिए।

Interoprability / सादगी

Google के प्रोटोकॉल बफ़र्स को लें, एक प्रमुख उदाहरण: आप एक एकल उच्च स्तरीय प्रोटोकॉल विवरण लिखते हैं जिसका उपयोग तब कई भाषाओं में कार्यान्वयन उत्पन्न करने के लिए किया जा सकता है - अक्सर सिस्टम के विभिन्न भागों को विभिन्न भाषाओं में लिखा जाता है।

कार्यान्वयन / तकनीकी कारण

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

उपयोग में आसानी

सी में लिखे गए एम्बेडेड प्रोजेक्ट्स (लगता है कि IoT) के लिए और केवल एक बाइनरी (RTOS या कोई OS) का उपयोग करके, यह डेटा को आसानी से संकलित किए जाने के साथ सी सरणी उत्पन्न करने में काफी आसान है, जैसा कि उन्हें सीधे लिंक करने के लिए चुना गया है। संसाधनों के रूप में।

संपादित करें

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

— जन दोर्नायक
स्रोत

पहले कारण से, मुझे लगता है कि ओपी का विचार प्रत्येक भाषा में एक सामान्य कार्यान्वयन होगा (जो प्रोटोकॉल बफ़र्स विवरण लेता है और फिर ऑन-द-वायर प्रारूप का उपयोग करता है)। यह कोड बनाने से भी बदतर क्यों होगा?

— पाओलो एबरमन

@ Pa @loEbermann सामान्य परिश्रम तर्क के अलावा इस तरह की एक सामान्य व्याख्या उन संकलित (और संभवतः व्याख्या की गई) भाषाओं में उन गड़बड़ियों का उपयोग करना असंभव बना देगा - सी ++ में उदाहरण के लिए इस तरह के एक दुभाषिया आवश्यकता-मूल्य संरचना को वापस कर देगा। । बेशक आप तब अपनी कक्षाओं में kv प्राप्त कर सकते हैं लेकिन यह बहुत सारे बॉयलरप्लेट कोड में बदल सकता है। और कोड पूरा भी है। और संकलन समय की जाँच करें - यदि आपके शाब्दिक में टाइपोस नहीं है तो आपका संकलक जाँच नहीं करेगा।

— Jan Dorniak

मैं सहमत हूं ... क्या आप इसे उत्तर में जोड़ सकते हैं?

— पाओलो एबरमन

@ Pa @loEbermann ने किया

— Jan Dorniak

6

क्या सोर्स कोड जनरेशन एक एंटी पैटर्न है?

यह एक अपर्याप्त रूप से अभिव्यंजक प्रोग्रामिंग भाषा के लिए एक काम है। ऐसी भाषा में कोड उत्पन्न करने की कोई आवश्यकता नहीं है जिसमें पर्याप्त अंतर्निहित अंतर्निहित प्रोग्रामिंग हो।

— केविन क्लाइन
स्रोत

3

अधिक-अभिव्यंजक भाषा के लिए पूर्ण, डाउन-टू-देशी-ऑब्जेक्ट-कोड कंपाइलर लिखने के लिए यह एक वैकल्पिक हल है। सी उत्पन्न करें, एक अच्छा आशावादी के साथ एक कंपाइलर को बाकी का ख्याल रखें।

— ब्लरफ्लू

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

— कोडमोंकी

@CodeMonkey: रूबीज ऑन एक्टिव 'रेकॉर्ड कार्यान्वयन' जैसी कुछ बातें दिमाग में आती हैं। कोड में डेटाबेस टेबल स्कीमा की नकल करने की कोई आवश्यकता नहीं है। गुणों के रूप में कॉलम नामों का उपयोग करते हुए एक कक्षा को एक तालिका में मैप करें और व्यावसायिक तर्क लिखें। मैं किसी भी प्रकार के पैटर्न की कल्पना नहीं कर सकता हूं जो एक कोड जनरेटर द्वारा उत्पादित किया जा सकता है जिसे रूबी मेटा-प्रोग्रामिंग द्वारा प्रबंधित नहीं किया जा सकता है। C ++ टेम्प्लेट भी बहुत शक्तिशाली होते हैं, फिर भी थोड़ा सा आर्कन होते हैं। लिस्प मैक्रोज़ एक और शक्तिशाली इन-लैंग्वेज मेटा-प्रोग्रामिंग सिस्टम हैं।

— केविन क्लाइन

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

— कोडमोंकी

6

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

यदि कोई जेनेरिक जैसी सुविधाओं को बदलने के लिए स्रोत कोड पीढ़ी का उपयोग कर रहा है, तो यह पैटर्न-विरोधी है।

— हिरितो विरिगाज़ोव
स्रोत

आप निश्चित रूप से ईसीएमएस्क्रिप्ट में एक बार अपना कोड लिख सकते हैं और जेवीएम पर नैशॉर्न या राइनो में चला सकते हैं। या, आप ECMAScript में JVM लिख सकते हैं (या एम्सस्क्रिप्ट का उपयोग करके एवियन को WebAssembly को संकलित करने की कोशिश कर सकते हैं) और ब्राउज़र में अपना जावा कोड चला सकते हैं। मैं यह नहीं कह रहा हूं कि वे महान विचार हैं (ठीक है, वे शायद भयानक विचार हैं :-D), लेकिन कम से कम संभव है यदि संभव नहीं है।

— जोर्ग डब्ल्यू मित्तग

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

— हिस्ट्रो व्रिगाज़ोव

6

क्या मुझसे कोई चूक हो रही है?

शायद एक अच्छा उदाहरण है जहां मध्यस्थ कोड सफलता का कारण बन गया? मैं आपको HTML की पेशकश कर सकता हूं।

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

हालाँकि, HTML कहीं नहीं होगा जहाँ यह अब है अगर यह कंप्यूटर उत्पन्न नहीं था। मेरा उत्तर इस पृष्ठ पर तब तक दिखाई नहीं देगा, जब तक कि कोई व्यक्ति मैन्युअल रूप से इसे HTML फ़ाइल में डेटाबेस से वापस न लिख ले। सौभाग्य से आप लगभग किसी भी प्रोग्रामिंग भाषा में प्रयोग करने योग्य HTML बना सकते हैं :)

यही है, अगर किसी चीज़ के लिए एक कोड जनरेटर है, तो क्यों नहीं उस चीज़ को एक उचित फ़ंक्शन बनाते हैं जो आवश्यक पैरामीटर प्राप्त कर सकता है और सही क्रिया करता है जो "उत्पन्न" कोड होगा?

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

— Džuris
स्रोत

हां, मैं एक बेहतर तरीके की कल्पना कर सकता हूं। HTML केवल टेक्स्ट-ओनली वेब ब्राउज़र के त्वरित निर्माण की अनुमति देने के लिए टिम बर्नर्स-ली द्वारा एक निर्णय की विरासत है। यह उस समय पूरी तरह से ठीक था, लेकिन हम एक ही तरह के लाभ के साथ ऐसा नहीं करेंगे। CSS ने सभी विभिन्न प्रस्तुति तत्व प्रकार (DIV, SPAN, TABLE, UL, आदि) को अनावश्यक बना दिया है।

— केविन क्लाइन

@kevincline मैं यह नहीं कह रहा हूँ कि HTML इस तरह की खामियों के बिना है, मैं इशारा कर रहा था कि मार्कअप लैंग्वेज (जो एक प्रोग्राम द्वारा उत्पन्न की जा सकती है) को पेश करना इस मामले में बहुत अच्छा काम करता है।

— Džuris

तो HTML + CSS सिर्फ HTML से बेहतर है। मैंने कुछ परियोजनाओं के लिए आंतरिक प्रलेखन भी लिखा है जो मैंने सीधे HTML + CSS + MathJax में काम किया है। लेकिन मुझे लगता है कि ज्यादातर वेब पेज कोड जनरेटर द्वारा उत्पादित किए गए हैं।

— डेविड के

3

क्यों स्रोत कोड उत्पन्न?

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

सामान्य उपयोग के मामले:

रोज़ या विज़ुअल प्रतिमान जैसे मॉडलिंग उपकरण;
उच्च एर एंबेडेड एसक्यूएल या एक इंटरफ़ेस परिभाषा भाषा है कि कुछ compilable में preprocessed किया जाना चाहिए जैसे स्तरीय भाषाओं;
फ्लेक्स / बाइसन जैसे लेक्सर और पार्सर जनरेटर;

अपने "क्यों न केवल इसे एक फ़ंक्शन बनाएं और इसे सीधे मापदंडों को पास करें" के लिए, ध्यान दें कि उपरोक्त में से कोई भी निष्पादन वातावरण नहीं है। उनके खिलाफ अपना कोड लिंक करने का कोई तरीका नहीं है।

— जॉन बोडे
स्रोत

2

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

मुझे इसके बारे में कैसे पता है? क्योंकि यह एक समाधान है जो मैंने कई बार विभिन्न विभिन्न प्रणालियों के साथ काम करते हुए, सबसे हाल ही में SourcePawn के लिए काम किया है। एक साधारण पायथन लिपि, जो स्रोत कोड की एक सरल रेखा को पार्स करती है और उत्पन्न कोड की दो या तीन पंक्तियों का निर्माण करती है, उत्पन्न कोड को मैन्युअल रूप से तैयार करने की तुलना में कहीं बेहतर है, जब आप दो दर्जन ऐसी पंक्तियों के साथ समाप्त होते हैं (मेरे सभी cvars बनाते हैं)।

यदि लोग इसे चाहते हैं तो प्रदर्शनकारी / उदाहरण स्रोत कोड उपलब्ध है।

— rosuav
स्रोत

1

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

और जब आप कोड जनरेट करते हैं, तो कोड जनरेशन प्रक्रिया को अक्सर मनुष्यों द्वारा डिबग करने की आवश्यकता होती है। यह बहुत उपयोगी है, यदि उत्पन्न कोड मानव पठनीय है तो मानव कोड जनरेशन प्रक्रिया में समस्याओं का पता लगा सकता है। किसी को कोड बनाने के लिए कोड लिखना होगा, आखिरकार। यह पतली हवा से बाहर नहीं होता है।

— gnasher729
स्रोत

1

कोड बनाना, बस एक बार

सभी स्रोत कोड पीढ़ी कुछ कोड उत्पन्न करने का मामला नहीं है, और फिर इसे कभी नहीं छूना; फिर इसे अद्यतन करने की आवश्यकता होने पर मूल स्रोत से पुन: प्राप्त करना।

कभी-कभी आप सिर्फ एक बार कोड उत्पन्न करते हैं, और फिर मूल स्रोत को छोड़ देते हैं, और आगे बढ़ते हुए नए स्रोत को बनाए रखते हैं।

यह कभी-कभी एक भाषा से दूसरी भाषा में कोड पोर्ट करते समय होता है। विशेष रूप से अगर कोई बाद में मूल में नए परिवर्तनों पर पोर्ट करने की उम्मीद नहीं करता है (जैसे पुरानी भाषा कोड बनाए रखा नहीं जा रहा है, या यह वास्तव में पूर्ण है (उदाहरण के लिए कुछ गणित कार्यक्षमता के मामले में)।

एक सामान्य मामला यह है कि ऐसा करने के लिए एक कोड जनरेटर लिखना, वास्तव में केवल 90% कोड का सही अनुवाद कर सकता है। और फिर उस अंतिम 10% को हाथ से तय करना होगा। जो हाथ से 100% अनुवाद करने की तुलना में बहुत तेज है।

इस तरह के कोड जनरेटर अक्सर कोड जनरेटर के पूर्ण भाषा अनुवादकों (जैसे साइथॉन या f2c) के उत्पादन के लिए बहुत भिन्न होते हैं। चूंकि लक्ष्य एक बार रखरखाव कोड बनाना है। उन्हें अक्सर 1 बंद के रूप में बनाया जाता है, जो उन्हें करना है। कई मायनों में यह पोर्ट कोड के लिए regex / find-प्रतिस्थापित का उपयोग करने का अगला स्तर संस्करण है। "टूल असिस्टेड पोर्टिंग" आप कह सकते हैं।

कोड बनाना, बस एक बार, उदाहरण के लिए एक वेबसाइट परिमार्जन से।

यदि आप किसी ऐसे स्रोत से कोड जेनरेट करते हैं, जिसे आप फिर से एक्सेस नहीं करना चाहते हैं, तो यह संबंधित है। उदाहरण के लिए, यदि कोड उत्पन्न करने के लिए आवश्यक क्रियाएं दोहराए जाने योग्य या सुसंगत नहीं हैं, या उन्हें निष्पादित करना महंगा है। मैं अभी परियोजनाओं की एक जोड़ी पर काम कर रहा हूं: DataDeps.jl और DataDepsGenerators.jl ।

DataDeps.jl उपयोगकर्ताओं को डेटा डाउनलोड करने में मदद करता है (जैसे मानक ML डेटासेट)। ऐसा करने के लिए यह आवश्यक है जिसे हम एक RegistrationBlock कहते हैं। यह कुछ मेटाडेटा निर्दिष्ट करने वाला कुछ कोड है, जैसे कि फ़ाइलों को कहां से डाउनलोड करना है, और एक चेकसम और उपयोगकर्ता को किसी भी नियम / कोड / डेटा पर लाइसेंसिंग की स्थिति के बारे में बताने वाला संदेश है।

उन ब्लॉकों को लिखना कष्टप्रद हो सकता है। और यह जानकारी अक्सर उन वेबसाइटों पर उपलब्ध (संरचित या असंरचित) होती है, जहां डेटा होस्ट किया जाता है। तो DataDepsGenerators.jl, कुछ साइटों को होस्ट करने के लिए एक Webscraper का उपयोग करता है, जो कुछ डेटा की मेजबानी करता है।

यह उन्हें सही ढंग से उत्पन्न नहीं कर सकता है। इसलिए उत्पन्न कोड का उपयोग करने वाले देवता को इसकी जाँच करनी चाहिए और इसे ठीक करना चाहिए। बाधाओं को वे सुनिश्चित करना चाहते हैं कि यह मिसिंग-लाइसेंसिंग जानकारी को मिस-स्क्रैप नहीं किया है।

महत्वपूर्ण रूप से, DataDeps.jl के साथ काम करने वाले उपयोगकर्ताओं / devs को RegistrationBlock कोड का उपयोग करने के लिए webscraper को स्थापित करने या उपयोग करने की आवश्यकता नहीं है। (और वेब-स्क्रैपर को डाउनलोड करने और इंस्टॉल करने की आवश्यकता नहीं है, यह बहुत ही कम समय बचाता है। विशेषकर CI रन के लिए)

स्रोत कोड जनरेट करना एक बार एंटीपैटर्न नहीं है। और इसे आम तौर पर मेटाप्रोग्रामिंग से बदला नहीं जा सकता है।

— लिंडन व्हाइट
स्रोत

"रिपोर्ट" एक अंग्रेजी शब्द है जिसका अर्थ है "पोर्ट फिर से" के अलावा कुछ और। उस वाक्य को स्पष्ट करने के लिए "पुनः-पोर्ट" का प्रयास करें। (किसी सुझाए गए संपादन के लिए बहुत छोटा होने के कारण टिप्पणी करना।)

— पीटर कॉर्डेस

अच्छा कैच @PeterCordes मैंने रीफ़्रेश किया है।

— लंडन व्हाइट

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

— पीटर कॉर्डेस

1

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

— लिंडन व्हाइट

1

बड़ी तालिका सबसे सरल सबसे कम तर्क था। इसी तरह के लिए कहा जा सकता है कि लूप्स या शर्तों को परिवर्तित करना। वास्तव में sedएक लंबा रास्ता तय करता है, लेकिन कभी-कभी व्यक्ति को थोड़ी अधिक अभिव्यंजक शक्ति की आवश्यकता होती है। प्रोग्राम लॉजिक और डेटा के बीच की रेखा अक्सर ठीक होती है। कभी-कभी भेद उपयोगी नहीं होता है। JSON (/ था) सिर्फ जावास्क्रिप्ट ऑब्जेक्ट कंस्ट्रक्टर कोड है। मेरे उदाहरण में मैं ऑब्जेक्ट कंस्ट्रक्टर कोड भी उत्पन्न कर रहा हूं (क्या यह डेटा है? शायद (शायद कभी-कभी यह फ़ंक्शन कॉल नहीं होता है)। क्या इसे कोड के रूप में बेहतर माना जाता है? हां।

— Lyndon White

1

"स्रोत" कोड का सृजन, उत्पन्न होने वाली भाषा की कमी का संकेत है। क्या यह एक विरोधी पैटर्न को दूर करने के लिए उपकरणों का उपयोग कर रहा है? बिल्कुल नहीं - मुझे समझाने दो।

आमतौर पर कोड पीढ़ी का उपयोग किया जाता है क्योंकि उच्च-स्तरीय परिभाषा मौजूद होती है जो परिणामस्वरूप कोड को निम्न स्तर की भाषा की तुलना में बहुत कम क्रिया का वर्णन कर सकती है। तो कोड पीढ़ी दक्षता और मरोड़ की सुविधा देती है।

जब मैं c ++ लिखता हूं, तो मैं ऐसा करता हूं क्योंकि यह मुझे कोडांतरक या मशीन कोड का उपयोग करने की तुलना में अधिक कुशल कोड लिखने की अनुमति देता है। अभी भी मशीन कोड कंपाइलर द्वारा जनरेट किया जाता है। शुरुआत में, c ++ केवल एक प्रीप्रोसेसर था जो C कोड जनरेट करता था। सामान्य प्रयोजन व्यवहार उत्पन्न करने के लिए सामान्य प्रयोजन की भाषाएँ महान हैं।

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

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

दूसरी ओर, यदि उत्पन्न कोड का स्रोत कोड बनाए रखने या उत्पन्न करने के लिए कठिन है जो कि पर्याप्त रूप से कुशल नहीं है, तो उपयोगकर्ता गलत साधनों का उपयोग करने के जाल में गिर रहा है (कभी-कभी उसी सुनहरे हथौड़ा के कारण )।

— daramarak
स्रोत

0

सोर्स कोड जेनरेशन का बिल्कुल मतलब है कि जेनरेट किया गया कोड डेटा है। लेकिन यह प्रथम श्रेणी का डेटा है, डेटा जिसे बाकी प्रोग्राम में हेरफेर कर सकते हैं।

दो सबसे सामान्य प्रकार के डेटा जिनके बारे में मुझे पता है कि वे स्रोत कोड में एकीकृत हैं, विंडोज़ (विभिन्न नियंत्रणों की संख्या और प्लेसमेंट) और ओआरएम के बारे में चित्रमय जानकारी है। दोनों मामलों में कोड जनरेशन के माध्यम से एकीकरण डेटा को हेरफेर करना आसान बनाता है, क्योंकि आपको उनका उपयोग करने के लिए अतिरिक्त "विशेष" चरणों से गुजरना नहीं पड़ता है।

मूल (1984) एमएसीएस के साथ काम करते समय, एक resouce संपादक का उपयोग करके संवाद और खिड़की की परिभाषाएं बनाई गई थीं जो डेटा को एक द्विआधारी प्रारूप में रखते थे। आपके आवेदन में इन संसाधनों का उपयोग करना कठिन था क्योंकि यह "बाइनरी प्रारूप" पास्कल था।

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

— jmoreno
स्रोत

0

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

उन भाषाओं में कोड जनरेशन के खिलाफ व्यापार अधिक निषेधात्मक है, जिनमें बाहरी टेक्स्ट प्रोसेसिंग के मंचन के माध्यम से मेटाप्रोग्रामिंग की जटिलताओं और अपर्याप्तताओं के कारण मेटा-प्रोग्रामिंग सुविधाएं (स्ट्रक्चरल मैक्रोज़) नहीं हैं।

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

मूल रूप से, यदि हम कोड पीढ़ी के लिए प्रतिबद्ध हैं, तो हमें संभवतः "बड़ा जाना चाहिए या घर जाना चाहिए": यह सुनिश्चित करें कि इसमें पर्याप्त शब्दार्थ हैं, और इसका उपयोग बहुत करें, या परेशान न करें।

— Kaz
स्रोत

आपने "जब बजरने स्ट्रॉस्ट्रुप को पहली बार C ++ ..." पैराग्राफ लागू किया, तो आपने उसे क्यों हटा दिया? मुझे लगता है कि यह दिलचस्प था।

— उत्कर्ष

@ यूटकु अन्य उत्तर इसे संपूर्ण, परिष्कृत भाषा को संकलित करने के दृष्टिकोण से कवर करते हैं, जिसमें एक परियोजना के बाकी हिस्सों को पूरी तरह से लिखा जाता है। मुझे नहीं लगता कि इसे "कोड जनरेशन" कहा जाता है।

— कज़

0

मैंने इसे स्पष्ट रूप से नहीं देखा था (मैंने देखा कि यह एक या दो उत्तरों द्वारा छुआ गया था, लेकिन यह बहुत स्पष्ट नहीं था)

जनरेटिंग कोड (जैसा कि आपने कहा, जैसे कि यह डेटा था) कोई समस्या नहीं है - यह एक माध्यमिक उद्देश्य के लिए संकलक का पुन: उपयोग करने का एक तरीका है।

उत्पन्न कोड संपादन सबसे कपटी, दुष्ट, भयावह विरोधी प्रतिमानों में से एक है जो आप कभी भी भर आएंगे। यह मत करो।

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

मुझे लगता है कि एक तीसरी श्रेणी कोड है जिसे आप एक बार (गुई जनरेटर?) का उपयोग करते हैं, फिर आपको आरंभ / सीखने में मदद करने के लिए संपादित करें। यह प्रत्येक का एक छोटा सा हिस्सा है - यह शुरू करने का एक अच्छा तरीका हो सकता है लेकिन आपके जीयूआई जनरेटर को "जेनरेटेबल" कोड का उपयोग करके लक्षित किया जाएगा जो एक प्रोग्रामर के रूप में आपके लिए एक शानदार शुरुआत नहीं होगी - इसके अलावा, आप हो सकते हैं दूसरे GUI के लिए फिर से इसका उपयोग करने का प्रलोभन जिसका मतलब है कि आपके सिस्टम में निरर्थक स्रोत कोड को खींचना।

यदि आपका टूलिंग किसी भी संपादन को उत्पन्न करने के लिए पर्याप्त स्मार्ट है, तो उत्पन्न कोड के लिए, इसके लिए जाएं। यदि नहीं, तो मैं इसे सबसे खराब प्रतिमानों में से एक कहूंगा।

— बिल के
स्रोत

0

कोड और डेटा दोनों हैं: सूचना।

डेटा आपके द्वारा आवश्यक रूप (और मूल्य) के रूप में जानकारी है। कोड भी जानकारी है, लेकिन एक अप्रत्यक्ष या मध्यवर्ती रूप में। संक्षेप में, कोड भी डेटा का एक रूप है।

अधिक विशेष रूप से, कोड मशीनों के लिए सूचना है जो मनुष्यों को सभी सूचनाओं को संसाधित करने से रोकती है।

मानव को सूचना प्रसंस्करण से दूर करना सबसे महत्वपूर्ण मकसद है। जब तक वे जीवन को आसान नहीं बनाते तब तक मध्यवर्ती चरण स्वीकार्य हैं। यही कारण है कि मध्यवर्ती सूचना मानचित्रण उपकरण मौजूद हैं। जैसे कोड जनरेटर, कंपाइलर, ट्रांसपॉयलर इत्यादि।

क्यों स्रोत कोड उत्पन्न? क्यों इसे एक समारोह में नहीं बनाया जाए जो मापदंडों को स्वीकार कर सके और उन पर कार्रवाई कर सके?

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

— एसडी
स्रोत

0

अगर कुछ उत्पन्न किया जा सकता है, तो वह चीज डेटा है, कोड नहीं।

जब आप उस कोड पर बाद में डेटा डालते हैं, तो आपका प्रस्ताव "यदि कुछ उत्पन्न हो सकता है, तो वह कोड नहीं है।" क्या आप कहेंगे कि, सी कंपाइलर द्वारा उत्पन्न असेंबली कोड कोड नहीं है? क्या होगा अगर यह विधानसभा कोड के साथ मेल खाता है जो मैं हाथ से लिखता हूं? यदि आप चाहें तो वहां जाने के लिए आपका स्वागत है, लेकिन मैं आपके साथ नहीं आऊंगा।

इसके बजाय "कोड" की परिभाषा के साथ शुरू करें। बहुत तकनीकी होने के बिना, इस चर्चा के प्रयोजनों के लिए एक बहुत अच्छी परिभाषा "अभिकलन प्रदर्शन के लिए मशीन-कार्रवाई योग्य निर्देश" होगी।

यह देखते हुए कि, स्रोत कोड पीढ़ी का यह पूरा विचार गलतफहमी नहीं है?

ठीक है, आपका प्रारंभिक प्रस्ताव यह है कि कोड उत्पन्न नहीं किया जा सकता है, लेकिन मैं उस प्रस्ताव को अस्वीकार करता हूं। यदि आप "कोड" की मेरी परिभाषा को स्वीकार करते हैं, तो सामान्य रूप से कोड पीढ़ी के साथ कोई वैचारिक समस्या नहीं होनी चाहिए।

यही है, अगर किसी चीज़ के लिए एक कोड जनरेटर है, तो क्यों नहीं उस चीज़ को एक उचित फ़ंक्शन बनाते हैं जो आवश्यक पैरामीटर प्राप्त कर सकता है और सही क्रिया करता है जो "उत्पन्न" कोड होगा?

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

फिर, आप जावा या सी या लिस्प में लिखना पसंद करते हैं या जो भी हो? यहां तक कि कोडांतरक? मैं दावा करता हूं कि यह कम से कम भाग में है क्योंकि वे भाषाएं डेटा और संचालन के लिए सार प्रदान करती हैं जो आपके द्वारा किए जाने वाले संगणना के विवरण को व्यक्त करना आसान बनाती हैं।

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

आपको यह भी विचार करना चाहिए कि "कोड जनरेटर" से आपका वास्तव में क्या मतलब है। मैं सी प्रीप्रोसेसिंग और कोड पीढ़ी में अभ्यास करने के लिए सी ++ टेम्पलेट्स की तात्कालिकता पर विचार करूंगा; क्या आपको इन पर आपत्ति है? यदि नहीं, तो मुझे लगता है कि आपको कुछ मानसिक जिम्नास्टिक प्रदर्शन करने की आवश्यकता होगी ताकि उन्हें स्वीकार किया जा सके लेकिन कोड पीढ़ी के अन्य स्वादों को खारिज कर दिया।

यदि यह प्रदर्शन कारणों से किया जा रहा है, तो यह संकलक की कमी की तरह लगता है।

क्यों? आप मूल रूप से यह स्वीकार कर रहे हैं कि किसी के पास एक सार्वभौमिक कार्यक्रम होना चाहिए जिसमें उपयोगकर्ता डेटा फ़ीड करता है, कुछ को "निर्देश" और अन्य को "इनपुट" के रूप में वर्गीकृत किया जाता है, और जो गणना करने के लिए आगे बढ़ता है और अधिक डेटा उत्सर्जित करता है जिसे हम "आउटपुट" कहते हैं। (एक निश्चित दृष्टिकोण से, कोई भी इस तरह के एक सार्वभौमिक कार्यक्रम को "ऑपरेटिंग सिस्टम" कह सकता है।) लेकिन आप यह क्यों मानते हैं कि इस तरह के सामान्य प्रयोजन कार्यक्रम को अनुकूलित करने में एक कंपाइलर उतना ही प्रभावी होना चाहिए जितना कि यह एक अधिक विशिष्ट को अनुकूलित करने में है। कार्यक्रम? दोनों कार्यक्रमों की अलग-अलग विशेषताएं और अलग-अलग क्षमताएं हैं।

यदि इसे दो भाषाओं को जोड़ने के लिए किया जा रहा है, तो यह इंटरफ़ेस लाइब्रेरी की कमी की तरह लगता है।

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

क्या मुझसे कोई चूक हो रही है?

कई बातें, मुझे लगता है।

मुझे पता है कि कोड डेटा भी है। जो मुझे समझ नहीं आ रहा है, वह स्रोत कोड क्यों है? क्यों इसे एक समारोह में नहीं बनाया जाए जो मापदंडों को स्वीकार कर सके और उन पर कार्रवाई कर सके?

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

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

— जॉन बोलिंगर
स्रोत

0

अपनी टिप्पणी के संदर्भ में प्रश्न का उत्तर देना:

संकलक का कर्तव्य मानव-पठनीय रूप में लिखे गए कोड को लेना और उसे मशीन-पठनीय रूप में परिवर्तित करना है। इसलिए, यदि कंपाइलर एक ऐसा कोड नहीं बना सकता है जो कुशल हो, तो कंपाइलर अपना काम ठीक से नहीं कर रहा है। क्या वह गलत है?

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

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

मैंने ठीक इसके विपरीत भी किया है। मेरे पास एक और काम है जो मैंने किया है जिसमें एक जनादेश था "कोई कोड पीढ़ी नहीं।" हम अभी भी सॉफ्टवेयर का उपयोग करने वालों पर जीवन को आसान बनाना चाहते थे, इसलिए हमने कंपाइलर के बड़े पैमाने पर उपयोग किया ताकि कंपाइलर मक्खी पर कोड उत्पन्न कर सके। इस प्रकार, मुझे केवल अपना काम करने के लिए सामान्य उद्देश्य C ++ भाषा की आवश्यकता थी।

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

अगर हमने कोड जनरेशन का उपयोग किया होता, तो हमारे पास मानव पठनीय त्रुटियों के साथ अधिक शक्तिशाली त्रुटि से निपटने की क्षमता हो सकती थी। C'est la vie।

— Cort Ammon
स्रोत

0

कोड पीढ़ी का उपयोग करने के कुछ अलग तरीके हैं। उन्हें तीन प्रमुख समूहों में विभाजित किया जा सकता है:

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

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

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

यही है, अगर किसी चीज़ के लिए एक कोड जनरेटर है, तो क्यों नहीं उस चीज़ को एक उचित फ़ंक्शन बनाते हैं जो आवश्यक पैरामीटर प्राप्त कर सकता है और सही क्रिया करता है जो "उत्पन्न" कोड होगा?

क्योंकि प्रकार की सुरक्षा और कोड पूरा होने की विशेषताएं हैं जो आप संकलन समय पर चाहते हैं (और आईडीई में कोड लिखते समय), लेकिन नियमित कार्यों को केवल रनटाइम पर निष्पादित किया जाता है।

हालांकि एक मध्यम जमीन हो सकती है: F # उन प्रदाताओं की अवधारणा का समर्थन करता है जो मूल रूप से संकलित समय पर प्रोग्रामेटिक रूप से उत्पन्न इंटरफेस को दृढ़ता से टाइप करते हैं। यह अवधारणा शायद कोड पीढ़ी के कई उपयोगों को बदल सकती है, और चिंताओं को अलग करने का एक क्लीनर प्रदान करती है।

— JacquesB
स्रोत

0

प्रोसेसर निर्देश सेट मूल रूप से अनिवार्य हैं , लेकिन प्रोग्रामिंग भाषाएं घोषणात्मक हो सकती हैं । एक घोषित भाषा में लिखे गए प्रोग्राम को चलाने के लिए अनिवार्य रूप से कुछ प्रकार की कोड पीढ़ी की आवश्यकता होती है। जैसा कि इस उत्तर और अन्य में उल्लेख किया गया है, मानव-पठनीय भाषा में स्रोत कोड उत्पन्न करने का एक प्रमुख कारण संकलक द्वारा निष्पादित परिष्कृत अनुकूलन का लाभ उठाना है।

— केविन क्रुमविडे
स्रोत

-3

अगर कुछ उत्पन्न किया जा सकता है, तो वह चीज डेटा है, कोड नहीं।

आपने इसे गलत तरीके से गोल कर दिया। इसे पढ़ना चाहिए

यदि किसी चीज़ को व्याख्याताओं के लिए एक जनरेटर में खिलाया जा सकता है , तो वह चीज़ कोड है, डेटा नहीं।

यह उस संकलन चरण के लिए स्रोत प्रारूप है, और सिंक प्रारूप अभी भी कोड है।

— Bergi
स्रोत

1

स्रोत कोड की गलत परिभाषा । स्रोत कोड ज्यादातर इस पर काम करने वाले मनुष्यों के लिए है (और यह मात्र तथ्य इसे परिभाषित करता है, यह भी देखें कि एफएसएफ द्वारा मुफ्त सॉफ्टवेयर क्या है )। असेंबलर कोड के साथ उत्पन्न gcc -fverbose-asm -O -Sस्रोत कोड नहीं है (और केवल या ज्यादातर डेटा नहीं है), भले ही यह कुछ पाठ रूप हमेशा जीएनयू को खिलाया जाता है asऔर कभी-कभी मनुष्यों द्वारा पढ़ा जाता है।

— बेसिल स्टारीनेवविच

साथ ही, कई भाषाएं कार्यान्वयन सी कोड के लिए संकलित करती हैं , लेकिन यह कि सी वास्तविक स्रोत कोड नहीं है (जैसे मानव द्वारा आसानी से काम नहीं किया जा सकता है)।

— बेसिल स्टारीनेवविच

अंत में, आपका हार्डवेयर (जैसे आपका एएमडी या इंटेल चिप, या आपका कंप्यूटर मदरबोर्ड) मशीन कोड की व्याख्या कर रहा है (जो स्पष्ट रूप से कोड नहीं है)। BTW IBM1620 में कीबोर्ड टाइप करने योग्य (BCD) मशीन कोड था, लेकिन इस तथ्य ने इसे "स्रोत कोड" नहीं बनाया। सभी कोड स्रोत नहीं है।

— बेसिल स्टारीनेवविच

@BasileStarynkevitch आह, तुम मुझे वहाँ मिल गया। मुझे अपने मजाकिया बयान को बहुत कम करने की कोशिश नहीं करनी चाहिए, या वे अपना अर्थ बदल देते हैं। सही, स्रोत कोड सबसे मूल कोड होना चाहिए जो पहले संकलन चरण में खिलाया जाता है।

— बर्गी

कोई भी स्रोत कोड मनुष्यों के लिए कोड नहीं है। यह संगीत के रूप में परिभाषित करने के लिए उतना ही कठिन और व्यक्तिपरक है (बनाम ध्वनि)। इसका उपभोग करने वाले सॉफ़्टवेयर को खोजने की कोशिश करने की बात नहीं है।

— बेसाइल स्टारीनेवविच

क्या स्रोत कोड पीढ़ी एक प्रतिमान है?

व्यावहारिक तर्क

मध्यवर्ती मानव-पठनीय कोड कभी न होने का ऐतिहासिक प्रभाव

मध्यवर्ती मानव-पठनीय कोड का उपयोग क्यों करें?

उदाहरण

उदाहरण 2

Interoprability / सादगी

कार्यान्वयन / तकनीकी कारण

उपयोग में आसानी

संपादित करें

कोड बनाना, बस एक बार

कोड बनाना, बस एक बार, उदाहरण के लिए एक वेबसाइट परिमार्जन से।