अधिकांश आधुनिक प्रोग्रामिंग भाषाओं में मैक्रोज़ शामिल क्यों नहीं हैं?

31

मुझे पता है कि उन्हें C / C ++ में बेहद अनिश्चित रूप से लागू किया गया है। क्या उन्हें सुरक्षित तरीके से लागू नहीं किया जा सकता है? क्या मैक्रो के नुकसान वास्तव में काफी खराब हैं जो उन्हें प्रदान की जाने वाली भारी शक्ति को पछाड़ते हैं?

programming-languages macros

— Casebash
स्रोत

4

वास्तव में मैक्रो क्या शक्ति प्रदान करते हैं जो किसी अन्य तरीके से आसानी से प्राप्त नहीं कर सकते हैं?

— चिन्मय कांची

2

सी # में, एक साधारण संपत्ति बनाने और एक घोषणा में समर्थन क्षेत्र को लपेटने के लिए एक मुख्य भाषा विस्तार लिया गया। और यह लेक्सिकल मैक्रोज़ से अधिक है: आप विज़ुअल बेसिक के WithEventsसंशोधक के अनुरूप एक फीचर कैसे बना सकते हैं ? आपको सिमेंटिक मैक्रोज़ जैसा कुछ चाहिए।

— जेफरी हेंटिन

3

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

— dan_waterworth

2

@ चिनमय: मैक्रोज़ कोड उत्पन्न करते हैं। उस शक्ति के साथ जावा भाषा में कोई विशेषता नहीं है।

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

1

@ चिनमय कांची: मैक्रोज़ रन टाइम के बजाय संकलन समय पर (मूल्यांकन) कोड को निष्पादित करने की अनुमति देते हैं।

— जियोर्जियो

57

मुझे लगता है कि मुख्य कारण यह है कि मैक्रोज़ लेक्सिकल हैं । इसके कई परिणाम हैं:

कंपाइलर के पास यह जांचने का कोई तरीका नहीं है कि एक मैक्रो शब्दार्थिक रूप से बंद है, अर्थात यह एक फ़ंक्शन की तरह "अर्थ की इकाई" का प्रतिनिधित्व करता है। (विचार करें #define TWO 1+1- क्या TWO*TWOबराबर है? 3.)
मैक्रों टाइप नहीं हैं जैसे फ़ंक्शन हैं। कंपाइलर यह जांच नहीं कर सकता है कि पैरामीटर और रिटर्न प्रकार समझ में आता है। यह केवल विस्तारित अभिव्यक्ति की जांच कर सकता है जो मैक्रो का उपयोग करता है।
यदि कोड संकलित नहीं करता है, तो संकलक को यह जानने का कोई तरीका नहीं है कि त्रुटि मैक्रो में ही है या उस स्थान पर जहां मैक्रो का उपयोग किया जाता है। कंपाइलर या तो गलत जगह आधे समय की रिपोर्ट करेगा, या उसे दोनों को रिपोर्ट करना होगा, हालांकि उनमें से एक शायद ठीक है। (पर विचार करें #define min(x,y) (((x)<(y))?(x):(y)): यदि का प्रकार क्या संकलक क्या करना चाहिए xऔर yमेल नहीं खाते या लागू नहीं करते operator<?)
स्वचालित उपकरण उनके साथ शब्दार्थ रूप से उपयोगी नहीं हो सकते। विशेष रूप से, आपके पास मैक्रोज़ के लिए IntelliSense जैसी चीज़ें नहीं हो सकती हैं जो फ़ंक्शंस की तरह काम करती हैं लेकिन एक अभिव्यक्ति तक विस्तारित होती हैं। (फिर से, minउदाहरण।)
किसी मैक्रो के साइड-इफेक्ट्स उतने स्पष्ट नहीं होते हैं जितने वे फ़ंक्शंस के साथ होते हैं, जिससे प्रोग्रामर के लिए संभावित भ्रम पैदा होता है। (फिर से minउदाहरण पर विचार करें : एक फ़ंक्शन कॉल में, आप जानते हैं कि इसके लिए अभिव्यक्ति xका मूल्यांकन केवल एक बार किया जाता है, लेकिन यहां आप मैक्रो को देखे बिना नहीं जान सकते।)

जैसा कि मैंने कहा, ये सभी इस तथ्य के परिणाम हैं कि मैक्रोज़ शाब्दिक हैं। जब आप उन्हें कुछ अधिक उचित में बदलने की कोशिश करते हैं, तो आप कार्यों और स्थिरांक के साथ समाप्त होते हैं।

— Timwi
स्रोत

32

सभी मैक्रो भाषा शाब्दिक नहीं हैं। उदाहरण के लिए, स्कीम मैक्रोज़ सिंटैक्टिक हैं, और C ++ टेम्प्लेट सिमेंटिक हैं। लेक्सिकल मैक्रो सिस्टम में यह भेद है कि वे किसी भी भाषा पर इसके सिंटैक्स के बारे में पता किए बिना उससे निपट सकते हैं।

— जेफरी हेंटिन

8

@ जेफ़्री: मुझे लगता है कि मेरे "मैक्रोज़ लेक्सिकल हैं" वास्तव में "जब लोग प्रोग्रामिंग भाषा में मैक्रोज़ का जिक्र करते हैं, तो वे आमतौर पर लेक्सिकल मैक्रोज़ के बारे में सोचते हैं"। यह दुर्भाग्यपूर्ण है कि स्कीम इस लोड किए गए शब्द का उपयोग उस चीज़ के लिए करेगी जो मौलिक रूप से अलग है। C ++ टेम्प्लेट, हालांकि, व्यापक रूप से मैक्रोज़ के रूप में संदर्भित नहीं होते हैं, संभवतः सटीक रूप से क्योंकि वे पूरी तरह से शाब्दिक नहीं हैं।

— टिमवी

25

मुझे लगता है कि स्कीम के मैक्रो शब्द का उपयोग लिस्प में वापस होता है, जिसका अर्थ है कि यह अधिकांश अन्य उपयोगों से पहले का है। IIRC C / C ++ सिस्टम को मूल रूप से प्रीप्रोसेसर कहा जाता था ।

— बेवन

16

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

— लॉरेंस गोंसाल्वेस

13

लेकिन हाँ, मैक्रोज़ को C / C ++ से बेहतर तरीके से डिज़ाइन और कार्यान्वित किया जा सकता है।

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

C / C ++ मामले में, कोई मौलिक विवेक जाँच नहीं है। यदि आप सावधान हैं, तो चीजें ठीक हैं। यदि आप एक गलती करते हैं, या यदि आप मैक्रोज़ का उपयोग करते हैं तो आप बड़ी समस्याओं में पड़ सकते हैं।

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

संक्षिप्त ऐतिहासिक संदर्भ

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

मूल LISP में मैक्रोज़ नहीं थे, लेकिन उन्हें पहली बार 1960 के मध्य में MacLisp में पेश किया गया था: https://stackoverflow.com/questions/3065606/when-did-the-idea-of-macros-user-defined-code -परचना-प्रकट होना । http://www.csee.umbc.edu/courses/331/resources/papers/Evolution-of-Lisp.pdf । इससे पहले, "fexprs" ने मैक्रो जैसी कार्यक्षमता प्रदान की थी।

सी के शुरुआती संस्करणों में मैक्रोज़ नहीं थे ( http://cm.bell-labs.com/cm/cs/who/dmr/chit.html ) । इन्हें एक प्रीप्रोसेसर के माध्यम से 1972-73 में जोड़ा गया था। इससे पहले, सी केवल समर्थित #includeऔर #define।

M4 मैक्रो-प्रीप्रोसेसर की उत्पत्ति लगभग 1977 में हुई थी।

अधिक हाल की भाषाएं स्पष्ट रूप से मैक्रोज़ को लागू करती हैं जहां ऑपरेशन का मॉडल पाठ के बजाय वाक्यविन्यास है।

इसलिए जब कोई "मैक्रो" शब्द की विशेष परिभाषा की प्रधानता के बारे में बात करता है, तो यह ध्यान रखना महत्वपूर्ण है कि अर्थ समय के साथ विकसित हुआ है।

— स्टीफन सी
स्रोत

9

C ++ धन्य है (?) TWO मैक्रो सिस्टम के साथ: प्रीप्रोसेसर और टेम्पलेट विस्तार।

— जेफरी हेंटिन

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

— डंक

@ डंक, लिस्प के रूप में एक मैक्रो की परिभाषा "आधुनिक" गूंगा समझ को दयनीय सी प्रीप्रोसेसर के रूप में दर्शाती है।

— एसके-लॉजिक

@ एसके: क्या "तकनीकी रूप से" सही होना बेहतर है और बातचीत को बाधित करना या समझा जाना बेहतर है?

— डंक

1

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

— एसके-लॉजिक

12

मैक्रोज़, स्कॉट नोट्स के रूप में , आपको तर्क छिपाने की अनुमति दे सकते हैं। बेशक, इसलिए फ़ंक्शंस, कक्षाएं, पुस्तकालय और कई अन्य सामान्य उपकरण हैं।

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

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

तो प्रोग्रामिंग को सरल बनाने के उद्देश्य से (जैसे जावा या पायथन), ऐसी प्रणाली एक रचना है।

— शोग ९
स्रोत

3

और फिर जावा ने फ़ॉरेस्ट, एनोटेशन, अभिकथन, जेनरिक-बाय-इरेज़र को जोड़कर रेल को बंद कर दिया ...

— जेफरी हेंटिन

2

@ जेफ़्री: और चलो मत भूलना, 3-पार्टी कोड जनरेटर के बहुत सारे । दूसरे विचार पर, चलो उन लोगों को भूल जाते हैं।

— Shog9

4

कैसे सरल के बजाय जावा सरल था, इसका एक और उदाहरण।

— जेफरी हेंटिन

3

@ जेफ्रीहैंटिन: फॉरआर्क में क्या गलत है?

— केसबश

1

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

— जेफरी हेन्टिन

6

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

मैक्रो कितना आसान हो सकता है इसका एक उदाहरण यह क्लोजर उदाहरण है जो अपवाद के मामले में उपयोग किए जाने के लिए डिफ़ॉल्ट मान निर्दिष्ट करता है:

(defmacro on-error [default-value code]
  `(try ~code (catch Exception ~'e ~default-value)))

(on-error 0 (+ nil nil))               ;; would normally throw NullPointerException
=> 0                                   ;l; but we get the default value

हालांकि लिसप में भी, सामान्य सलाह "मैक्रोज़ का उपयोग न करें जब तक कि आपके पास न हो"।

यदि आप एक होमोसेक्सुअल भाषा का उपयोग नहीं कर रहे हैं, तो मैक्रोज़ बहुत पेचीदा हो जाते हैं और अन्य विभिन्न विकल्पों में कुछ नुकसान होते हैं:

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

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

— mikera
स्रोत

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

— मेसन व्हीलर

10

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

— मिकेरा

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

— zstewart

ओह। अधिक सुरक्षा कचरा नहीं। अन्यथा, वॉन न्यूमैन आर्किटेक्चर के साथ हर सिस्टम को दोष दें, जैसे कि प्रत्येक IA-32 प्रोसेसर स्व-संशोधित कोड की क्षमता के साथ। मुझे संदेह है कि क्या आप शारीरिक रूप से छेद भर सकते हैं ... वैसे भी, आपको सामान्य रूप से इस तथ्य का सामना करना होगा: कोड और डेटा के बीच isomorphism कई मायनों में दुनिया की प्रकृति है । और यह (शायद) आप, प्रोग्रामर, सुरक्षा requirments के invariance रखने के लिए कर्तव्य है, जो कृत्रिम रूप से कहीं भी समय से पहले अलगाव लागू करने के लिए समान नहीं है।

— फ्रैंकहब

4

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

मैक्रों प्रतीकात्मक स्थिरांक को परिभाषित करते थे #define X 100

इसे आसानी से बदला जा सकता है: const int X = 100;

मैक्रोज़ (अनिवार्य रूप से) इनलाइन प्रकार-अज्ञेय कार्यों को परिभाषित करने के लिए उपयोग किया जाता है #define max(X,Y) (X>Y?X:Y)

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

मैक्रोज़ अक्सर उपयोग किए जाने वाले तत्वों के लिए शॉर्टकट निर्दिष्ट करते थे। #define p printf

यह आसानी से एक फ़ंक्शन द्वारा प्रतिस्थापित किया जाता p()है जो समान कार्य करता है। यह सी ( va_arg()कार्यों के परिवार का उपयोग करने की आवश्यकता) में काफी शामिल है, लेकिन कई अन्य भाषाओं में जो फ़ंक्शन तर्कों की चर संख्या का समर्थन करते हैं, यह बहुत सरल है।

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

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

— चिन्मय कांची
स्रोत

1

यदि आपको # अधिकतम मीटर लगाना है, तो कृपया मापदंडों के चारों ओर कोष्ठक लगाएं, ताकि ऑपरेटर पूर्वता से कोई अप्रत्याशित प्रभाव न हो ... जैसे #define max (X, Y) ((X)> (Y)? (X) :( य))

— फू

आप महसूस करते हैं कि यह केवल एक उदाहरण था ... आशय स्पष्ट करना था।

— चिन्मय कांची

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

— ingo

7

In fact, I can't think of a single use-case for macros that can't easily be duplicated in another way: C कम से कम, आप मैक्रोज़ का उपयोग किए बिना टोकन कॉन्क्वेनेशन का उपयोग करके पहचानकर्ता (चर नाम) नहीं बना सकते हैं।

— चार्ल्स साल्विया

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

— सुपरकैट

2

मैक्रोज़ के साथ मैंने जो सबसे बड़ी समस्या देखी है वह यह है कि जब भारी इस्तेमाल किया जाता है तो वे कोड को पढ़ना और बनाए रखना बहुत मुश्किल बना सकते हैं क्योंकि वे आपको मैक्रो में तर्क को छिपाने की अनुमति देते हैं जो खोजने में आसान हो सकता है या नहीं (और हो सकता है या तुच्छ नहीं हो सकता है )।

— स्कॉट डोरमैन
स्रोत

क्या मैक्रो को प्रलेखित नहीं किया जाना चाहिए?

— केसबश

@ कैसबैश: बेशक, मैक्रो को किसी अन्य स्रोत कोड की तरह ही प्रलेखित किया जाना चाहिए ... लेकिन व्यवहार में मैंने इसे शायद ही कभी देखा है।

— स्कॉट डोरमैन

3

कभी डिबग प्रलेखन? खराब लिखित कोड से निपटने के दौरान यह पर्याप्त नहीं है।

— जेएफओ

OOP की कुछ समस्याएं हैं, हालांकि ...

— aoeu256

2

यह देखते हुए कि C / C ++ में MACROs बहुत सीमित हैं, त्रुटि प्रवण और वास्तव में उपयोगी नहीं हैं।

MACROs जैसा कि LISP, या z / OS असेम्बलर भाषा में कार्यान्वित किया जाता है, विश्वसनीय और अविश्वसनीय रूप से उपयोगी हो सकता है।

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

— जेम्स एंडरसन
स्रोत