इनलाइन फ़ंक्शन: Difference between revisions

Latest revision as of 10:35, 15 July 2023

सी (प्रोग्रामिंग भाषा ) और सी ++ प्रोग्रामिंग भाषाओं में, एक इनलाइन फ़ंक्शन कीवर्ड (कंप्यूटर प्रोग्रामिंग) इनलाइन के साथ योग्य है; यह दो उद्देश्यों को पूरा करता है:

यह एक कंपाइलर निर्देश के रूप में कार्य करता है जो हमे सुझाव प्रदान करता है (लेकिन इसकी आवश्यकता नहीं है) कि कंपाइलर इनलाइन विस्तार करके फ़ंक्शन के बॉडी को इनलाइन प्रतिस्थापित करता है, अर्थात प्रत्येक फ़ंक्शन कॉल के एड्रेस पर फ़ंक्शन कोड डालकर, जिससे फ़ंक्शन कॉल के ओवरहेड को बचाया जा सकता है। इस संबंध में यह registerस्टोरेज क्लास निर्दिष्टकर्ता के अनुरूप है, जो इसी प्रकार एक अनुकूलन संकेत प्रदान करता है।^[1]
इनलाइन का दूसरा उद्देश्य लिंकेज व्यवहार को परिवर्तित करना है, इसका विवरण काम्प्लेक्स है। यह सी/सी++ भिन्न संकलन + लिंकेज मॉडल के कारण आवश्यक है, विशेष रूप से क्योंकि फ़ंक्शन की परिभाषा (बॉडी) को उन सभी अनुवाद इकाई (प्रोग्रामिंग) में डुप्लिकेट किया जाना चाहिए जहां इसका उपयोग किया जाता है, जिससे की संकलन के समय इनलाइनिंग की अनुमति मिल सके, यदि फ़ंक्शन में बाहरी लिंकेज (सॉफ़्टवेयर) है, लिंकिंग के समय टकराव का कारण बनता है (यह बाहरी प्रतीकों की विशिष्टता का उल्लंघन करता है)। सी और सी ++ (और जीएनयू सी और विजुअल सी ++ जैसी बोलियां) इसे भिन्न-भिन्न विधियों से समाधान करती हैं।^[1]

उदाहरण

एक इनलाइन फ़ंक्शन को सी या सी ++ में इस प्रकार लिखा जा सकता है:

inline void swap(int *m, int *n)
{
    int tmp = *m;
    *m = *n;
    *n = tmp;
}

फिर, निम्नलिखित जैसा एक कथन:

swap(&x, &y);

इसका अनुवाद किया जा सकता है, यदि कंपाइलर इनलाइनिंग करने का निर्णय लेता है, जिसके लिए सामान्यतः अनुकूलन को सक्षम करने की आवश्यकता होती है:

int tmp = x;
x = y;
y = tmp;

बहुत सारे स्वैप करते हुए तथा सॉर्टिंग कलन विधि लागू करते समय, यह निष्पादन गति को बढ़ा सकता है।

मानक समर्थन

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

नॉनस्टैंडर्ड एक्सटेंशन

जीएनयू सी, डिएलेक्ट जीएनयू89 के भाग के रूप में, जो यह प्रदान करता है, सी89 के विस्तार के रूप में इनलाइन के लिए समर्थन है। चूंकि, शब्दार्थ सी ++ और सी99 दोनों से भिन्न है। सी90 मोड में आर्मसीसी एक नॉनस्टैंडर्ड एक्सटेंशन के रूप में इनलाइन भी प्रदान करता है, जिसका शब्दार्थ जीएनयू89 और सी99 से भिन्न है।

कुछ इम्प्लीमेंटेशन एक साधन प्रदान करते हैं जिसके द्वारा संकलक को किसी फ़ंक्शन को इनलाइन करने के लिए मजबूर किया जाता है, सामान्यतः पर इम्प्लीमेंटेशन-विशिष्ट घोषणा विनिर्देशकों के माध्यम से:

माइक्रोसॉफ्ट विज़ुअल सी ++: __forceinline
जीसीसी या क्लैंग: __attribute__((always_inline)) or __attribute__((__always_inline__)), जिनमें से पश्चात वाला always_inline नामक उपयोगकर्ता-परिभाषित मैक्रो के साथ टकराव से बचने के लिए उपयोगी है।

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

इनलाइनिंग को मजबूर करना उपयोगी है |

कंपाइलर द्वारा इनलाइन का सम्मान नहीं किया जाता है (कंपाइलर लागत/लाभ विश्लेषक द्वारा अनदेखा किया जाता है), और
इनलाइनिंग के परिणामस्वरूप आवश्यक प्रदर्शन में वृद्धि होती है

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

#ifdef _MSC_VER
    #define forceinline __forceinline
#elif defined(__GNUC__)
    #define forceinline inline __attribute__((__always_inline__))
#elif defined(__CLANG__)
    #if __has_attribute(__always_inline__)
        #define forceinline inline __attribute__((__always_inline__))
    #else
        #define forceinline inline
    #endif
#else
    #define forceinline inline
#endif

इनलाइन फ़ंक्शंस का संग्रहण वर्ग

स्टैटिक इनलाइन का सभी सी डिएलेक्ट्स और सी ++ में समान प्रभाव होता है। यदि आवश्यक हो तो यह स्थानीय रूप से दृश्यमान (आउट-ऑफ़-लाइन कॉपी) फ़ंक्शन का उत्सर्जन करता है।

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

इनलाइन फ़ंक्शंस पर लागू या लागू नहीं होने पर स्टोरेज क्लास एक्सटर्न का प्रभाव सी डिएलेक्ट्स^[2] और सी++ के बीच भिन्न होता है।^[3]

सी 99

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

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

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

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

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

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

जीएनयू89

इनलाइन और एक्सटर्न इनलाइन के जीएनयू89 शब्दार्थ अनिवार्य रूप से सी99 के पूर्णतया विपरीत हैं,^[4] इस अपवाद के साथ कि जीएनयू89 एक बाहरी इनलाइन फ़ंक्शन को एक अयोग्य फ़ंक्शन के रूप में फिर से परिभाषित करने की अनुमति देता है, जबकि सी99 इनलाइन ऐसा नहीं करता है।^[5] इस प्रकार, पुनर्परिभाषा के बिना जीएनयू89 एक्सटर्न इनलाइन सी99 इनलाइन की तरह है, और जीएनयू89 इनलाइन सी99 एक्सटर्न इनलाइन की तरह है; दूसरे शब्दों में, जीएनयू89 में, एक फ़ंक्शन परिभाषित इनलाइन निरंतर होगा और एक फ़ंक्शन परिभाषित बाहरी इनलाइन कभी भी बाहरी रूप से दृश्यमान फ़ंक्शन उत्सर्जित नहीं करेगा, इसके लिए तर्क यह है कि यह वेरिएबल्स से मेल खाता है, जिसके लिए भंडारण कभी भी आरक्षित नहीं होगा यदि इसे बाहरी के रूप में परिभाषित किया गया है और निरंतर यदि इसके बिना परिभाषित किया गया है। इसके विपरीत, सी99 के लिए तर्क यह है कि यह आश्चर्यजनक होगा यदि इनलाइन का उपयोग करने का एक साइड-इफ़ेक्ट होगा - निरंतर फ़ंक्शन के एक गैर-इनलाइन संस्करण को उत्सर्जित करने के लिए - जो कि इसके नाम से पता चलता है, उसके विपरीत है।

इनलाइन फ़ंक्शंस के लिए पूर्णतया एक बाहरी रूप से दृश्यमान फ़ंक्शन उदाहरण प्रदान करने की आवश्यकता के बारे में और पहुंच योग्य कोड के साथ परिणामी समस्या के बारे में सी99 की टिप्पणियाँ यथोचित परिवर्तनों के साथ जीएनयू89 पर भी लागू होती हैं।

संस्करण 4.2 तक और इसमें सम्मलित जीसीसी ने जीएनयू89 इनलाइन शब्दार्थ का उपयोग किया, तब भी जब -एसटीडी =सी99 स्पष्ट रूप से निर्दिष्ट किया गया था।^[6] संस्करण 5 के साथ,^[5] जीसीसी ने जीएनयू89 से जीएनयू11 डिएलेक्ट में स्विच किया, जिससे डिफ़ॉल्ट रूप से सी99 इनलाइन शब्दार्थ को प्रभावी ढंग से सक्षम किया गया, इसके अतिरिक्त जीएनयू89 शब्दार्थ का उपयोग करने के लिए, उन्हें स्पष्ट रूप से सक्षम करना होगा, या तो -एसटीडी =जीएनयू89 के साथ या, मात्र इनलाइनिंग को प्रभावित करने के लिए, -एफजीएनयू89-इनलाइन, या सभी इनलाइन घोषणाओं में जीएनयू_इनलाइन विशेषता जोड़कर, सी99 शब्दार्थ सुनिश्चित करने के लिए, या तो -एसटीडी =सी99, -एसटीडी =सी11, -एसटीडी =जीएनयू99 या -एसटीडी =जीएनयू11 (-एफजीएनयू89-इनलाइन के बिना) का उपयोग किया जा सकता है।^[3]

सी ++

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

आर्मसीसी

सी90 मोड में आर्मसीसी बाहरी इनलाइन और इनलाइन शब्दार्थ प्रदान करता है जो सी ++ के समान हैं: ऐसी परिभाषाएँ यदि आवश्यक हो तो अनुवाद इकाइयों के बीच साझा किए गए फ़ंक्शन का उत्सर्जन करेंगी। सी99 मोड में, एक्सटर्नल इनलाइन निरंतर एक फ़ंक्शन उत्सर्जित करता है, लेकिन सी ++ की तरह, इसे अनुवाद इकाइयों के बीच साझा किया जाएगा। इस प्रकार, एक ही फ़ंक्शन को विभिन्न अनुवाद इकाइयों में एक्सटर्नल इनलाइन परिभाषित किया जा सकता है।^[7] यह अप्रारंभीकृत वैश्विक चर की कई गैर-बाहरी परिभाषाओं के लिए यूनिक्स सी कंपाइलर्स^[8] के पारंपरिक व्यवहार से मेल खाता है।

प्रतिबंध

किसी इनलाइन फ़ंक्शन का पता लेने के लिए किसी भी स्थिति में उस फ़ंक्शन की गैर-इनलाइन प्रतिलिपि के लिए कोड की आवश्यकता होती है।

सी99 में, एक इनलाइन या बाहरी इनलाइन फ़ंक्शन को स्थिर वैश्विक चर तक नहीं पहुंचना चाहिए या गैर-कॉन्स्ट स्थिर स्थानीय चर को परिभाषित नहीं करना चाहिए, स्थिर स्थिर स्थानीय चर भिन्न-भिन्न अनुवाद इकाइयों में भिन्न-भिन्न ऑब्जेक्ट हो भी सकते हैं और नहीं भी, यह इस बात पर निर्भर करता है कि फ़ंक्शन इनलाइन किया गया था या कॉल किया गया था। मात्र स्थिर इनलाइन परिभाषाएँ बिना किसी प्रतिबंध के आंतरिक लिंकेज वाले पहचानकर्ताओं को संदर्भित कर सकती हैं; वे प्रत्येक अनुवाद इकाई में भिन्न-भिन्न वस्तुएँ होती है। सी++ में, कॉन्स्ट और नॉन-कॉन्स्ट दोनों स्थिर स्थानीय की अनुमति है और वे सभी अनुवाद इकाइयों में एक ही ऑब्जेक्ट को संदर्भित करते हैं।

जीसीसी इनलाइन फ़ंक्शंस नहीं कर सकता है यदि^[3]

वे विविध हैं,
कंप्यूटेड गोटो का उपयोग करें
गैर-स्थानीय गोटो का उपयोग करें
नेस्टेड फंक्शन का उपयोग करें
सेटजेएमपी का उपयोग करें
__बिल्टिन_लॉन्गजम्प का उपयोग करें
__बिल्टिन_रिटर्न का उपयोग करें, या
__बिल्टिन_अप्लाई_आर्ग्स का उपयोग करें

एमएसडीएन पर माइक्रोसॉफ्ट विनिर्देशों के आधार पर, एमएस विज़ुअल सी ++ इनलाइन नहीं कर सकता (__forceinline के साथ भी नहीं), यदि

फ़ंक्शन या उसके कॉलर को /Ob0 (डीबग बिल्ड के लिए डिफ़ॉल्ट विकल्प) के साथ संकलित किया गया है।
फ़ंक्शन और कॉलर विभिन्न प्रकार के अपवाद हैंडलिंग (एक में सी ++ अपवाद हैंडलिंग, दूसरे में संरचित अपवाद हैंडलिंग) का उपयोग करते हैं।
फ़ंक्शन में एक परिवर्तनीय तर्क सूची है।
फ़ंक्शन इनलाइन असेंबली का उपयोग करता है, जब तक कि इसे /Og, /Ox, /O1, या /O2 के साथ संकलित नहीं किया जाता है।
फ़ंक्शन रिकर्सन (कंप्यूटर विज्ञान) है और #pragma inline_recursion(on) के साथ नहीं है। प्राग्मा के साथ, पुनरावर्ती फ़ंक्शन 16 कॉल की डिफ़ॉल्ट गहराई पर इनलाइन होते हैं। इनलाइनिंग गहराई को कम करने के लिए, इनलाइन_डेप्थ प्राग्मा का उपयोग किया जाता है।
यह फ़ंक्शन आभासी फंक्शन है और इसे वर्चुअली कहा जाता है। वर्चुअल फ़ंक्शंस पर सीधी कॉल को इनलाइन किया जा सकता है।
प्रोग्राम फ़ंक्शन का पता लेता है और पॉइंटर के माध्यम से फ़ंक्शन पर कॉल किया जाता है। जिन कार्यों का पता लिया गया है, उनके लिए सीधी कॉल को इनलाइन किया जा सकता है।
फ़ंक्शन को नेक्ड __देकलस्पेस संशोधक के साथ भी चिह्नित किया गया है।

समस्याएं

यह भी देखें: इनलाइन विस्तार § प्रदर्शन पर प्रभाव

सामान्यतः इनलाइन विस्तार की समस्याओं के अतिरिक्त (देखें इनलाइन विस्तार § प्रदर्शन पर प्रभाव), भाषा सुविधा के रूप में इनलाइन फ़ंक्शन कई कारणों से उतने मूल्यवान नहीं हो सकते जितने वे दिखाई देते हैं:

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

उद्धरण

"एक फ़ंक्शन घोषणा [...] एक इनलाइन विनिर्देशक के साथ एक इनलाइन फ़ंक्शन घोषित करता है। इनलाइन विनिर्देशक इम्प्लीमेंटेशन को इंगित करता है कि कॉल के बिंदु पर फ़ंक्शन बॉडी के इनलाइन प्रतिस्थापन को सामान्य फ़ंक्शन कॉल तंत्र के लिए प्राथमिकता दी जानी है। एक इम्प्लीमेंटेशन कॉल के बिंदु पर इस इनलाइन प्रतिस्थापन को निष्पादित करने की आवश्यकता नहीं है; चूंकि, यदि इस इनलाइन प्रतिस्थापन को छोड़ दिया गया हो, 7.1.2 द्वारा परिभाषित इनलाइन फ़ंक्शन के अन्य नियमों का अभी भी सम्मान किया जा सकता है।

— आईएसओ/आईईसी 14882:2011, वर्तमान सी++ मानक, खंड 7.1.2

"इनलाइन फ़ंक्शन विनिर्देशक के साथ घोषित एक फ़ंक्शन एक इनलाइन फ़ंक्शन है। [...] एक फ़ंक्शन को इनलाइन फ़ंक्शन बनाने से पता चलता है कि फ़ंक्शन पर कॉल जितनी तेज़ हो सके, ऐसे सुझाव किस सीमा तक प्रभावी हैं यह इम्प्लीमेंटेशन-परिभाषित है ( फ़ुटनोट: उदाहरण के लिए, एक इम्प्लीमेंटेशन कभी भी इनलाइन प्रतिस्थापन नहीं कर सकता है, या मात्र इनलाइन घोषणा के दायरे में कॉल के लिए इनलाइन प्रतिस्थापन कर सकता है।)

"[...] एक इनलाइन परिभाषा फ़ंक्शन के लिए बाहरी परिभाषा प्रदान नहीं करती है, और किसी अन्य अनुवाद इकाई में बाहरी परिभाषा को प्रतिबंधित नहीं करती है। एक इनलाइन परिभाषा बाहरी परिभाषा का एक विकल्प प्रदान करती है, जिसका उपयोग एक अनुवादक उसी अनुवाद इकाई में फ़ंक्शन में किसी भी कॉल को लागू करने के लिए कर सकता है। यह निर्दिष्ट नहीं है कि फ़ंक्शन पर कॉल इनलाइन परिभाषा या बाहरी परिभाषा का उपयोग करती है या नहीं।"

— आईएसओ 9899:1999(ई), सी99 मानक, खंड 6.7.4

यह भी देखें

मैक्रो (कंप्यूटर विज्ञान)

संदर्भ

↑ ^1.0 ^1.1 Meyers, Randy (July 1, 2002). "The New C: Inline Functions". {{cite journal}}: Cite journal requires |journal= (help)
↑ ^2.0 ^2.1 "Inline Functions in C".
↑ ^3.0 ^3.1 ^3.2 ^3.3 "Using the GNU Compiler Collection (GCC): Inline".
↑ "Josef "Jeff" Sipek » GNU inline vs. C99 inline".
↑ ^5.0 ^5.1 "Porting to GCC 5 - GNU Project".
↑ "Ian Lance Taylor - Clean up extern inline".
↑ "Documentation – Arm Developer".
↑ gcc manual page, description of -fno-common

JANA, DEBASISH (1 January 2005). C++ AND OBJECT-ORIENTED PROGRAMMING PARADIGM. PHI Learning Pvt. Ltd. ISBN 978-81-203-2871-6.
Sengupta, Probal (1 August 2004). Object-Oriented Programming: Fundamentals And Applications. PHI Learning Pvt. Ltd. ISBN 978-81-203-1258-6.
Svenk, Goran (2003). Object-oriented Programming: Using C++ for Engineering and Technology. Cengage Learning. ISBN 0-7668-3894-3.
Balagurusamy (2013). Object Oriented Programming with C++. Tata McGraw-Hill Education. ISBN 978-1-259-02993-6.
Kirch-Prinz, Ulla; Prinz, Peter (2002). A Complete Guide to Programming in C++. Jones & Bartlett Learning. ISBN 978-0-7637-1817-6.
Conger, David (2006). Creating Games in C++: A Step-by-step Guide. New Riders. ISBN 978-0-7357-1434-2.
Skinner, M. T. (1992). The Advanced C++ Book. Silicon Press. ISBN 978-0-929306-10-0.
Love (1 September 2005). Linux Kernel Development. Pearson Education. ISBN 978-81-7758-910-8.
DEHURI, SATCHIDANANDA; JAGADEV, ALOK KUMAR; RATH, AMIYA KUMAR (8 May 2007). OBJECT-ORIENTED PROGRAMMING USING C++. PHI Learning Pvt. Ltd. ISBN 978-81-203-3085-6.

बाहरी संबंध

Inline functions with the जीएनयू Compiler Collection (GCC)
Summary of "inline" semantics in C and C++, by LLVM contributor David Chisnall

[meyers2002-1] 1.0 ^1.1 Meyers, Randy (July 1, 2002). "The New C: Inline Functions". {{cite journal}}: Cite journal requires |journal= (help)

[inline-c99-vs-gnu-2] 2.0 ^2.1 "Inline Functions in C".

[gcc-inline-3] 3.0 ^3.1 ^3.2 ^3.3 "Using the GNU Compiler Collection (GCC): Inline".

[4] "Josef "Jeff" Sipek » GNU inline vs. C99 inline".

[gcc-5-porting-5] 5.0 ^5.1 "Porting to GCC 5 - GNU Project".

[6] "Ian Lance Taylor - Clean up extern inline".

[7] "Documentation – Arm Developer".

[8] ual page, description of -fno-common

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

@@ Line 1: / Line 1: @@
 {{short description|Function in the C and C++ programming languages}}
-{{About|inline functions in C and C++|inline expansion more generally|Inline expansion}}
+{{About|C और C++ में इनलाइन फ़ंक्शन|इनलाइन एक्सपेंशन अधिक सामान्यतः|इनलाइन एक्सपेंशन }}
-सी ([[ प्रोग्रामिंग भाषा ]]) और [[सी ++]] प्रोग्रामिंग भाषाओं में, एक इनलाइन फ़ंक्शन [[कीवर्ड]] [[कीवर्ड (कंप्यूटर प्रोग्रामिंग)|(कंप्यूटर प्रोग्रामिंग)]] <code>inline</code> के साथ योग्य है;  यह दो उद्देश्यों को पूरा करता है:
-# यह एक [[कंपाइलर]] निर्देश के रूप में कार्य करता है जो सुझाव देता है (लेकिन इसकी आवश्यकता नहीं है) कि कंपाइलर [[इनलाइन विस्तार]] करके फ़ंक्शन के बॉडी को इनलाइन प्रतिस्थापित करता है, अर्थात प्रत्येक फ़ंक्शन कॉल के पते पर फ़ंक्शन कोड डालकर, जिससे फ़ंक्शन कॉल के ओवरहेड को बचाया जा सकता है। इस संबंध में यह रजिस्टर <code>register</code>[[स्टोरेज क्लास निर्दिष्टकर्ता]] के अनुरूप है, जो इसी प्रकार एक अनुकूलन संकेत प्रदान करता है।<ref name="meyers2002">{{cite journal |title=The New C: Inline Functions |url=http://www.drdobbs.com/the-new-c-inline-functions/184401540 |first=Randy |last=Meyers |date=July 1, 2002}}</ref>
-# इनलाइन का दूसरा उद्देश्य लिंकेज व्यवहार को बदलना है; इसका विवरण जटिल है। यह सी/सी++ भिन्न संकलन + लिंकेज मॉडल के कारण आवश्यक है, विशेष रूप से क्योंकि फ़ंक्शन की परिभाषा (बॉडी) को उन सभी [[अनुवाद इकाई (प्रोग्रामिंग)]] में डुप्लिकेट किया जाना चाहिए जहां इसका उपयोग किया जाता है, ताकि संकलन के दौरान इनलाइनिंग की अनुमति मिल सके, यदि फ़ंक्शन में बाहरी लिंकेज (सॉफ़्टवेयर) है, लिंकिंग के दौरान टकराव का कारण बनता है (यह बाहरी प्रतीकों की विशिष्टता का उल्लंघन करता है)। सी और सी ++ (और जीएनयू सी और विजुअल सी ++ जैसी बोलियां) इसे भिन्न-भिन्न विधियों से हल करती हैं।<ref name="meyers2002"/>
+सी ([[ प्रोग्रामिंग भाषा ]]) और [[सी ++]] प्रोग्रामिंग भाषाओं में, एक इनलाइन फ़ंक्शन [[कीवर्ड]] [[कीवर्ड (कंप्यूटर प्रोग्रामिंग)|(कंप्यूटर प्रोग्रामिंग)]] [[इनलाइन विस्तार|<code>इनलाइन</code>]] के साथ योग्य है; यह दो उद्देश्यों को पूरा करता है:
+# यह एक [[कंपाइलर]] निर्देश के रूप में कार्य करता है जो हमे सुझाव प्रदान करता है (लेकिन इसकी आवश्यकता नहीं है) कि कंपाइलर [[इनलाइन विस्तार]] करके फ़ंक्शन के बॉडी को इनलाइन प्रतिस्थापित करता है, अर्थात प्रत्येक फ़ंक्शन कॉल के एड्रेस पर फ़ंक्शन कोड डालकर, जिससे फ़ंक्शन कॉल के ओवरहेड को बचाया जा सकता है। इस संबंध में यह <code>register</code>[[स्टोरेज क्लास निर्दिष्टकर्ता]] के अनुरूप है, जो इसी प्रकार एक अनुकूलन संकेत प्रदान करता है।<ref name="meyers2002">{{cite journal |title=The New C: Inline Functions |url=http://www.drdobbs.com/the-new-c-inline-functions/184401540 |first=Randy |last=Meyers |date=July 1, 2002}}</ref>
+# इनलाइन का दूसरा उद्देश्य लिंकेज व्यवहार को परिवर्तित करना है, इसका विवरण काम्प्लेक्स है। यह सी/सी++ भिन्न संकलन + लिंकेज मॉडल के कारण आवश्यक है, विशेष रूप से क्योंकि फ़ंक्शन की परिभाषा (बॉडी) को उन सभी [[अनुवाद इकाई (प्रोग्रामिंग)]] में डुप्लिकेट किया जाना चाहिए जहां इसका उपयोग किया जाता है, जिससे की संकलन के समय इनलाइनिंग की अनुमति मिल सके, यदि फ़ंक्शन में बाहरी लिंकेज (सॉफ़्टवेयर) है, लिंकिंग के समय टकराव का कारण बनता है (यह बाहरी प्रतीकों की विशिष्टता का उल्लंघन करता है)। सी और सी ++ (और जीएनयू सी और विजुअल सी ++ जैसी बोलियां) इसे भिन्न-भिन्न विधियों से समाधान करती हैं।<ref name="meyers2002"/> <br />
 == उदाहरण ==
-एक <code>inline</code> function को C या C++ में इस प्रकार लिखा जा सकता है:
+एक इनलाइन फ़ंक्शन को सी या सी ++ में इस प्रकार लिखा जा सकता है:
 <syntaxhighlight lang="c">
 inline void swap(int *m, int *n)
@@ Line 17: / Line 15: @@
 }
 </syntaxhighlight>
-फिर, एक बयान जैसे कि निम्नलिखित:
+फिर, निम्नलिखित जैसा एक कथन:
 <syntaxhighlight lang="c">
 swap(&x, &y);
 </syntaxhighlight>
-में अनुवाद किया जा सकता है (यदि संकलक इनलाइनिंग करने का निर्णय लेता है, जिसे सामान्यतः सक्षम करने के लिए अनुकूलन की आवश्यकता होती है):
+इसका अनुवाद किया जा सकता है, यदि कंपाइलर इनलाइनिंग करने का निर्णय लेता है, जिसके लिए सामान्यतः अनुकूलन को सक्षम करने की आवश्यकता होती है:
 <syntaxhighlight lang="c">
 int tmp = x;
@@ Line 27: / Line 25: @@
 y = tmp;
 </syntaxhighlight>
-बहुत सारे स्वैप करते हुए सॉर्टिंग एल्गोरिदम लागू करते समय, यह निष्पादन की गति को बढ़ा सकता है।
+बहुत सारे स्वैप करते हुए तथा सॉर्टिंग कलन विधि लागू करते समय, यह निष्पादन गति को बढ़ा सकता है।
 == मानक समर्थन ==
-C++ और [[C99]], लेकिन इसके पूर्ववर्ती K&R C और C89 (C संस्करण) के लिए समर्थन नहीं है <code>inline</code> कार्य, चूंकि विभिन्न शब्दार्थों के साथ। दोनों ही स्थितियों में, <code>inline</code> इनलाइनिंग को मजबूर नहीं करता है; संकलक फ़ंक्शन को इनलाइन नहीं करने का चयन करने के लिए स्वतंत्र है, या मात्र कुछ स्थितियों में। भिन्न-भिन्न कंपाइलर इस बात में भिन्न होते हैं कि इनलाइन में वे कितने जटिल कार्य कर सकते हैं। [[विजुअल सी प्लस प्लस]] | माइक्रोसॉफ्ट विज़ुअल सी++ और [[जीएनयू संकलक संग्रह]] जैसे मेनस्ट्रीम सी++ कंपाइलर्स एक ऐसे विकल्प का समर्थन करते हैं जो कंपाइलर्स को स्वचालित रूप से किसी भी उपयुक्त फ़ंक्शन को इनलाइन करने देता है, यहां तक कि उन लोगों के रूप में चिह्नित नहीं किया गया है। <code>inline</code> कार्य करता है। चूंकि, मात्र छोड़ना <code>inline</code> कीवर्ड को संकलक को सभी इनलाइनिंग निर्णय लेने देना संभव नहीं है, क्योंकि लिंकर तब विभिन्न अनुवाद इकाइयों में डुप्लिकेट परिभाषाओं के बारे में शिकायत करेगा। यह है क्योंकि <code>inline</code> न मात्र संकलक को संकेत देता है कि फ़ंक्शन को रेखांकित किया जाना चाहिए, इसका प्रभाव यह भी है कि संकलक फ़ंक्शन की कॉल करने योग्य आउट-ऑफ-लाइन प्रति उत्पन्न करेगा (इनलाइन फ़ंक्शंस के #Storage वर्ग देखें)।
+सी ++ और [[C99|सी99]], लेकिन इसके पूर्ववर्ती के एंड आर सी और सी89 के पास इनलाइन फ़ंक्शंस के लिए समर्थन नहीं है, चूंकि भिन्न-भिन्न शब्दार्थ के साथ, दोनों ही स्थितियों में, इनलाइन इनलाइनिंग को बाध्य नहीं करता है; संकलक यह चुनने के लिए स्वतंत्र है कि वह फ़ंक्शन को पूर्णतया भी इनलाइन न करे, या मात्र कुछ स्थितियों में, भिन्न-भिन्न संकलक इस बात में भिन्न होते हैं कि वे कितने काम्प्लेक्स फ़ंक्शन को इनलाइन में प्रबंधित कर सकते हैं। [[विजुअल सी प्लस प्लस|विजुअल सी++]], माइक्रोसॉफ्ट विज़ुअल सी++ और जीसीसी जैसे मुख्यधारा सी++ संकलक एक विकल्प का समर्थन करते हैं जो कंपाइलरों को किसी भी उपयुक्त फ़ंक्शन को स्वचालित रूप से इनलाइन करने देता है, यहां तक कि उन लोगों को भी इनलाइन फ़ंक्शन के रूप में चिह्नित नहीं किया जाता है। चूंकि, कंपाइलर को सभी इनलाइनिंग निर्णय लेने देने के लिए इनलाइन कीवर्ड को छोड़ना संभव नहीं है, क्योंकि लिंकर तब विभिन्न अनुवाद इकाइयों में डुप्लिकेट परिभाषाओं के बारे में शिकायत करता है। ऐसा इसलिए है क्योंकि इनलाइन न मात्र कंपाइलर को संकेत देता है कि फ़ंक्शन को इनलाइन किया जाना चाहिए, अपितु इसका इस पर भी प्रभाव पड़ता है कि कंपाइलर फ़ंक्शन की कॉल करने योग्य आउट-ऑफ़-लाइन प्रतिलिपि उत्पन्न करेगा या नहीं (इनलाइन फ़ंक्शंस की स्टोरेज क्लास है)।
-== अमानक एक्सटेंशन ==
+== नॉनस्टैंडर्ड एक्सटेंशन ==
-[[GNU C]], बोली gnu89 के हिस्से के रूप में जो इसे प्रदान करता है, के लिए समर्थन है <code>inline</code> C89 के विस्तार के रूप में। चूंकि, शब्दार्थ C++ और C99 दोनों से भिन्न है। C90 मोड में armcc भी प्रदान करता है <code>inline</code> एक गैर-मानक विस्तार के रूप में, शब्दार्थ के साथ gnu89 और C99 से भिन्न।
+[[GNU C,|जीएनयू सी,]] डिएलेक्ट जीएनयू89 के भाग के रूप में, जो यह प्रदान करता है, सी89 के विस्तार के रूप में इनलाइन के लिए समर्थन है। चूंकि, शब्दार्थ सी ++ और सी99 दोनों से भिन्न है। सी90 मोड में आर्मसीसी एक नॉनस्टैंडर्ड एक्सटेंशन के रूप में इनलाइन भी प्रदान करता है, जिसका शब्दार्थ जीएनयू89 और सी99 से भिन्न है।
-कुछ कार्यान्वयन एक साधन प्रदान करते हैं जिसके द्वारा संकलक को एक फ़ंक्शन को इनलाइन करने के लिए मजबूर किया जाता है, सामान्यतः कार्यान्वयन-विशिष्ट घोषणा विनिर्देशकों के माध्यम से:
+कुछ इम्प्लीमेंटेशन एक साधन प्रदान करते हैं जिसके द्वारा संकलक को किसी फ़ंक्शन को इनलाइन करने के लिए मजबूर किया जाता है, सामान्यतः पर इम्प्लीमेंटेशन-विशिष्ट घोषणा विनिर्देशकों के माध्यम से:
 * माइक्रोसॉफ्ट विज़ुअल सी ++: <code>__forceinline</code>
-* जीसीसी या क्लैंग: <code>__attribute__((always_inline))</code> या <code>__attribute__((__always_inline__))</code>, जिसका पश्चात वाला उपयोगकर्ता-परिभाषित मैक्रो नाम के साथ विरोध से बचने के लिए उपयोगी है <code>always_inline</code>.
+* जीसीसी या क्लैंग: <code>__attribute__((always_inline))</code> or <code>__attribute__((__always_inline__))</code>, जिनमें से पश्चात वाला always_inline नामक उपयोगकर्ता-परिभाषित मैक्रो के साथ टकराव से बचने के लिए उपयोगी है।
-इसके अंधाधुंध उपयोग के परिणामस्वरूप बड़ा कोड (फूला हुआ निष्पादन योग्य फ़ाइल), न्यूनतम या कोई प्रदर्शन लाभ नहीं हो सकता है, और कुछ स्थितियों में प्रदर्शन में कमी भी हो सकती है। इसके अतिरिक्त, कंपाइलर सभी परिस्थितियों में फ़ंक्शन को इनलाइन नहीं कर सकता है, यदि इनलाइनिंग मजबूर हो; इस स्थितियाँ में जीसीसी और विजुअल सी ++ दोनों चेतावनियां उत्पन्न करते हैं।
+इसके इंडिस्क्रिमीनेट उपयोग के परिणामस्वरूप बड़ा कोड (ब्लोटेड एक्सेक्यूटेबल फ़ाइल), न्यूनतम या कोई प्रदर्शन लाभ नहीं हो सकता है, और कुछ स्थितियों में प्रदर्शन में हानि भी हो सकती है। इसके अतिरिक्त, कंपाइलर सभी परिस्थितियों में फ़ंक्शन को इनलाइन नहीं कर सकता, यदि इनलाइनिंग को मजबूर किया गया हो; इस स्थितियाँ में जीसीसी और विजुअल सी ++ दोनों चेतावनियाँ उत्पन्न करते हैं।
-इनलाइनिंग को मजबूर करना उपयोगी है यदि
+इनलाइनिंग को मजबूर करना उपयोगी है |
-* <code>inline</code> संकलक द्वारा सम्मानित नहीं किया जाता है (संकलक लागत/लाभ विश्लेषक द्वारा अनदेखा किया जाता है), और
+* कंपाइलर द्वारा इनलाइन का सम्मान नहीं किया जाता है (कंपाइलर लागत/लाभ विश्लेषक द्वारा अनदेखा किया जाता है), और
-* इनलाइनिंग से आवश्यक प्रदर्शन में वृद्धि होती है
+* इनलाइनिंग के परिणामस्वरूप आवश्यक प्रदर्शन में वृद्धि होती है
 कोड पोर्टेबिलिटी के लिए, निम्नलिखित प्रीप्रोसेसर निर्देशों का उपयोग किया जा सकता है:
@@ Line 63: / Line 61: @@
 == इनलाइन फ़ंक्शंस का संग्रहण वर्ग ==
-<code>static inline</code> सभी C बोलियों और C++ में समान प्रभाव है। यदि आवश्यक हो तो यह स्थानीय रूप से दृश्यमान (आउट-ऑफ-लाइन प्रति) फ़ंक्शन का उत्सर्जन करेगा।
+स्टैटिक इनलाइन का सभी सी डिएलेक्ट्स और सी ++ में समान प्रभाव होता है। यदि आवश्यक हो तो यह स्थानीय रूप से दृश्यमान (आउट-ऑफ़-लाइन कॉपी) फ़ंक्शन का उत्सर्जन करता है।
-स्टोरेज क्लास के अतिरिक्त, कंपाइलर अनदेखा कर सकता है <code>inline</code> क्वालीफायर और सभी सी बोलियों और सी ++ में फ़ंक्शन कॉल उत्पन्न करें।
-भंडारण वर्ग का प्रभाव <code>extern</code> जब लागू किया जाता है या लागू नहीं किया जाता है <code>inline</code> कार्य सी बोलियों के बीच भिन्न होते हैं<ref name="inline-c99-vs-gnu">{{Cite web|url=http://www.greenend.org.uk/rjk/tech/inline.html|title = Inline Functions in C}}</ref> और सी ++।<ref name="gcc-inline">{{Cite web|url=https://gcc.gnu.org/onlinedocs/gcc-7.1.0/gcc/Inline.html|title = Using the GNU Compiler Collection (GCC): Inline}}</ref>
+स्टोरेज क्लास के अतिरिक्त, कंपाइलर इनलाइन क्वालीफायर को अनदेखा कर सकता है और सभी सी डिएलेक्ट भाषाओं और सी++ में फ़ंक्शन कॉल उत्पन्न कर सकता है।
+इनलाइन फ़ंक्शंस पर लागू या लागू नहीं होने पर स्टोरेज क्लास एक्सटर्न का प्रभाव सी डिएलेक्ट्स<ref name="inline-c99-vs-gnu">{{Cite web|url=http://www.greenend.org.uk/rjk/tech/inline.html|title = Inline Functions in C}}</ref> और सी++ के बीच भिन्न होता है।<ref name="gcc-inline">{{Cite web|url=https://gcc.gnu.org/onlinedocs/gcc-7.1.0/gcc/Inline.html|title = Using the GNU Compiler Collection (GCC): Inline}}</ref>
 === सी 99 ===
-C99 में, एक फ़ंक्शन परिभाषित किया गया <code>inline</code> कभी नहीं होगा, और एक फ़ंक्शन परिभाषित किया गया है <code>extern inline</code> निरंतर बाहरी रूप से दिखाई देने वाले फ़ंक्शन का उत्सर्जन करेगा। सी ++ के विपरीत, अनुवाद इकाइयों के बीच साझा किए गए बाहरी रूप से दृश्यमान फ़ंक्शन को मात्र आवश्यक होने पर उत्सर्जित करने का कोई विधि नहीं है।
+सी99 में, एक फ़ंक्शन परिभाषित इनलाइन कभी नहीं होगा, और एक फ़ंक्शन परिभाषित बाहरी इनलाइन निरंतर एक बाहरी रूप से दृश्यमान फ़ंक्शन उत्सर्जित करेगा। सी++ के विपरीत, अनुवाद इकाइयों के बीच साझा किए गए बाहरी रूप से दृश्यमान फ़ंक्शन को मात्र आवश्यकता पड़ने पर उत्सर्जित करने के लिए कहने का कोई विधि नहीं है।
-यदि <code>inline</code> घोषणाओं को मिलाया गया है <code>extern inline</code> घोषणाएं या अयोग्य घोषणाओं के साथ (अर्थात।, बिना <code>inline</code> क्वालीफायर या स्टोरेज क्लास), अनुवाद इकाई में एक परिभाषा होनी चाहिए (कोई फर्क नहीं पड़ता कि अयोग्य है, <code>inline</code>, या <code>extern inline</code>) और इसके लिए बाहरी रूप से दृश्यमान फ़ंक्शन उत्सर्जित किया जाएगा।
-एक फंक्शन परिभाषित <code>inline</code> प्रोग्राम में कहीं और उस नाम के साथ पूर्णतया एक फ़ंक्शन की आवश्यकता होती है जिसे या तो परिभाषित किया जाता है <code>extern inline</code> या क्वालीफायर के बिना। यदि पूरे कार्यक्रम में ऐसी एक से अधिक परिभाषाएँ प्रदान की जाती हैं, तो लिंकर डुप्लिकेट प्रतीकों के बारे में शिकायत करेगा। यदि, चूंकि, इसकी कमी है, तो लिंकर जरूरी शिकायत नहीं करता है, क्योंकि यदि सभी उपयोगों को रेखांकित किया जा सकता है, तो इसकी आवश्यकता नहीं है। लेकिन यह शिकायत कर सकता है, क्योंकि कंपाइलर निरंतर इसे अनदेखा कर सकता है <code>inline</code> क्वालीफायर और इसके अतिरिक्त फ़ंक्शन को कॉल उत्पन्न करें, जैसा कि सामान्यतः तब होता है जब कोड को अनुकूलन के बिना संकलित किया जाता है। (यह वांछित व्यवहार हो सकता है, यदि फ़ंक्शन को हर प्रकार से हर जगह रेखांकित किया जाना चाहिए, और यदि ऐसा नहीं है तो एक त्रुटि उत्पन्न होनी चाहिए।) एक सुविधाजनक विधि परिभाषित करना है <code>inline</code> शीर्ष लेख फ़ाइलों में कार्य करता है और प्रति फ़ंक्शन एक .c फ़ाइल बनाता है, जिसमें a <code>extern inline</code> इसके लिए घोषणा और परिभाषा के साथ संबंधित शीर्षलेख फ़ाइल सम्मलित है। इससे कोई फर्क नहीं पड़ता कि घोषणा सम्मलित होने से पहले या पश्चात में है।
-अगम्य कोड को अंतिम निष्पादन योग्य में जोड़े जाने से रोकने के लिए यदि किसी फ़ंक्शन के सभी उपयोग इनलाइन किए गए थे, तो यह सलाह दी जाती है<ref name="gcc-inline"/>ऐसी सभी .c फ़ाइलों की ऑब्जेक्ट फ़ाइलों को एक सिंगल के साथ रखने के लिए <code>extern inline</code> सामान्यतः एक [[स्थिर पुस्तकालय]] फ़ाइल में कार्य करता है <code>ar rcs</code>, फिर भिन्न-भिन्न ऑब्जेक्ट फ़ाइलों के अतिरिक्त उस लाइब्रेरी से लिंक करें। यह मात्र उन ऑब्जेक्ट फ़ाइलों को लिंक करने का कारण बनता है जिनकी वास्तव में आवश्यकता होती है, ऑब्जेक्ट फ़ाइलों को सीधे लिंक करने के विपरीत, जिसके कारण उन्हें निरंतर निष्पादन योग्य में सम्मलित किया जाता है। चूंकि, लाइब्रेरी फ़ाइल को लिंकर कमांड लाइन पर अन्य सभी ऑब्जेक्ट फ़ाइलों के पश्चात निर्दिष्ट किया जाना चाहिए, क्योंकि लाइब्रेरी फ़ाइल के पश्चात कार्यों के लिए निर्दिष्ट ऑब्जेक्ट फ़ाइलों से कॉल को लिंकर द्वारा नहीं माना जाएगा। से कॉल करता है <code>inline</code> दूसरे के लिए कार्य करता है <code>inline</code> कार्यों को लिंकर द्वारा स्वचालित रूप से हल किया जाएगा ( <code>s</code> में विकल्प <code>ar rcs</code> यह सुनिश्चित करता है)।
+यदि इनलाइन घोषणाओं को बाहरी इनलाइन घोषणाओं या अयोग्य घोषणाओं (सम्मलित, इनलाइन क्वालिफायर या स्टोरेज क्लास के बिना) के साथ मिश्रित किया जाता है, तो अनुवाद इकाई में एक परिभाषा होनी चाहिए (चाहे अयोग्य, इनलाइन या बाहरी इनलाइन हो) और एक बाहरी रूप से दृश्यमान फ़ंक्शन होगा इसके लिए उत्सर्जित किया जाता है।
-एक वैकल्पिक समाधान लाइब्रेरी के अतिरिक्त लिंक टाइम ऑप्टिमाइज़ेशन का उपयोग करना है। जीसीसी ध्वज प्रदान करता है <code>-Wl,--gc-sections</code> उन अनुभागों को छोड़ने के लिए जिनमें सभी फ़ंक्शन का उपयोग नहीं किया गया है। यह ऑब्जेक्ट फ़ाइलों के स्थितियाँ में होगा जिसमें एक अप्रयुक्त का कोड होगा <code>extern inline</code> फंक्शन। चूंकि, यह अन्य सभी ऑब्जेक्ट फ़ाइलों से किसी भी और सभी अप्रयुक्त अनुभागों को भी हटा देता है, न कि मात्र अप्रयुक्त से संबंधित <code>extern inline</code> कार्य करता है। (फ़ंक्शंस को निष्पादन योग्य में लिंक करना वांछित हो सकता है जिसे प्रोग्रामर द्वारा प्रोग्राम के अतिरिक्त डीबगर से कॉल किया जाना है, उदाहरण के लिए, प्रोग्राम की आंतरिक स्थिति की जांच के लिए।) इस दृष्टिकोण के साथ, यह भी संभव है सभी के साथ एक .c फ़ाइल का उपयोग करने के लिए <code>extern inline</code> प्रति फ़ंक्शन एक .c फ़ाइल के अतिरिक्त कार्य करता है। फिर फाइल को कंपाइल करना होगा <code>-fdata-sections -ffunction-sections</code>. चूंकि, जीसीसी मैनुअल पेज इसके बारे में चेतावनी देता है, कहता है कि ऐसा करने से महत्वपूर्ण लाभ होने पर मात्र इन विकल्पों का उपयोग करें।
+इनलाइन परिभाषित फ़ंक्शन के लिए प्रोग्राम में कहीं और उस नाम के साथ पूर्णतया एक फ़ंक्शन की आवश्यकता होती है जो या तो बाहरी इनलाइन या बिना क्वालीफायर के परिभाषित होता है। यदि पूरे प्रोग्राम में ऐसी एक से अधिक परिभाषाएँ प्रदान की गई हैं, तो लिंकर डुप्लिकेट प्रतीकों के बारे में शिकायत करता है। यदि, चूंकि, इसकी कमी है, तो लिंकर आवश्यक रूप से शिकायत नहीं करता है, क्योंकि, यदि सभी उपयोगों को इनलाइन किया जा सकता है, तो इसकी आवश्यकता नहीं है। लेकिन यह शिकायत कर सकता है, क्योंकि कंपाइलर निरंतर इनलाइन क्वालीफायर को अनदेखा कर सकता है और इसके अतिरिक्त फ़ंक्शन पर कॉल उत्पन्न कर सकता है, जैसा कि सामान्यतः तब होता है जब कोड अनुकूलन के बिना संकलित किया जाता है। (यह वांछित व्यवहार हो सकता है, यदि फ़ंक्शन को सभी विधियों से हर जगह इनलाइन किया जाना चाहिए, और यदि ऐसा नहीं है तो एक त्रुटि उत्पन्न होती है।) एक सुविधाजनक विधि हेडर फ़ाइलों में इनलाइन फ़ंक्शंस को परिभाषित करना और प्रति फ़ंक्शन एक .सी फ़ाइल बनाना है, जिसमें इसके लिए एक बाहरी इनलाइन घोषणा सम्मलित है और परिभाषा के साथ संबंधित हेडर फ़ाइल भी सम्मलित है। इससे कोई फर्क नहीं पड़ता कि डेक्लेरेशन सम्मलित करने से पहले है या पश्चात में हो सकती है।
-कुछ पूरी प्रकार से भिन्न दृष्टिकोण की सलाह देते हैं, जो कि कार्यों को परिभाषित करना है <code>static inline</code> के अतिरिक्त <code>inline</code> हेडर फाइलों में।<ref name="inline-c99-vs-gnu"/>फिर, कोई अगम्य कोड उत्पन्न नहीं होगा। चूंकि, विपरीत स्थितियाँ में इस दृष्टिकोण में एक खामी है: यदि फ़ंक्शन को एक से अधिक अनुवाद इकाई में इनलाइन नहीं किया जा सकता है तो डुप्लिकेट कोड उत्पन्न होगा। उत्सर्जित फ़ंक्शन कोड को अनुवाद इकाइयों के बीच साझा नहीं किया जा सकता क्योंकि इसके भिन्न-भिन्न पते होने चाहिए। यह एक और कमी है; इस प्रकार के एक फंक्शन का पता लेने के रूप में परिभाषित किया गया है <code>static inline</code> हेडर फ़ाइल में भिन्न-भिन्न अनुवाद इकाइयों में भिन्न-भिन्न मान मिलेंगे। इसलिए, <code>static inline</code> कार्यों का उपयोग मात्र तभी किया जाना चाहिए जब वे मात्र एक अनुवाद इकाई में उपयोग किए जाते हैं, जिसका अर्थ है कि उन्हें मात्र संबंधित .c फ़ाइल में जाना चाहिए, हेडर फ़ाइल में नहीं।
+यदि किसी फ़ंक्शन के सभी उपयोग इनलाइन थे, तो पहुंच योग्य कोड को अंतिम निष्पादन योग्य में जोड़े जाने से रोकने के लिए, यह सलाह दी जाती है<ref name="gcc-inline"/> कि ऐसी सभी .सी फ़ाइलों की ऑब्जेक्ट फ़ाइलों को एक एकल बाहरी इनलाइन फ़ंक्शन के साथ एक [[स्थिर लाइब्रेरी]] फ़ाइल में रखा जाए, सामान्यतः एआर आरसीएस के साथ, फिर भिन्न-भिन्न ऑब्जेक्ट फ़ाइलों के अतिरिक्त उस लाइब्रेरी से लिंक करें, इससे मात्र उन्हीं ऑब्जेक्ट फ़ाइलों को लिंक किया जा सकता है जिनकी वास्तव में आवश्यकता होती है, ऑब्जेक्ट फ़ाइलों को सीधे लिंक करने के विपरीत, जिसके कारण उन्हें निरंतर निष्पादन योग्य में सम्मलित किया जाता है। चूंकि, लाइब्रेरी फ़ाइल को लिंकर कमांड लाइन पर अन्य सभी ऑब्जेक्ट फ़ाइलों के पश्चात निर्दिष्ट किया जाना चाहिए, क्योंकि लाइब्रेरी फ़ाइल के पश्चात निर्दिष्ट ऑब्जेक्ट फ़ाइलों से फ़ंक्शंस की कॉल पर लिंकर द्वारा विचार नहीं किया जा सकता है। इनलाइन फ़ंक्शंस से अन्य इनलाइन फ़ंक्शंस पर कॉल को लिंकर द्वारा स्वचालित रूप से समाधान किया जाएगा (एआर आरसीएस में एस विकल्प यह सुनिश्चित करता है)।
-=== gnu89 ===
+एक वैकल्पिक समाधान लाइब्रेरी के अतिरिक्त लिंक टाइम ऑप्टिमाइज़ेशन का उपयोग करना है। जीसीसी उन अनुभागों को हटाने के लिए ध्वज -डब्ल्यूएल,--जीसी-सेक्शन प्रदान करता है जिनमें सभी फ़ंक्शन अप्रयुक्त हैं। एकल अप्रयुक्त बाहरी इनलाइन फ़ंक्शन के कोड वाली ऑब्जेक्ट फ़ाइलों के लिए यही स्थिति होता है। चूंकि, यह अन्य सभी ऑब्जेक्ट फ़ाइलों से सभी अप्रयुक्त अनुभागों को भी हटा देता है, न कि मात्र अप्रयुक्त बाहरी इनलाइन फ़ंक्शंस से संबंधित अनुभागों को। (फ़ंक्शंस को निष्पादन योग्य में लिंक करना वांछित हो सकता है जिन्हें प्रोग्रामर द्वारा प्रोग्राम के अतिरिक्त डिबगर से बुलाया जाना है, उदाहरण के लिए, प्रोग्राम की आंतरिक स्थिति की जांच करने के लिए।) इस दृष्टिकोण के साथ, यह भी संभव है प्रति फ़ंक्शन एक .सी फ़ाइल के अतिरिक्त सभी बाहरी इनलाइन फ़ंक्शंस के साथ एक .सी फ़ाइल का उपयोग करना। फिर फ़ाइल को -एफडेटा-सेक्शन -एफफंक्शन-सेक्शन के साथ संकलित करना होता है। चूंकि, जीसीसी मैनुअल पेज इसके बारे में चेतावनी देते हुए कहता है, "इन विकल्पों का उपयोग मात्र तभी करें जब ऐसा करने से महत्वपूर्ण लाभ होता है।"
-gnu89 का शब्दार्थ <code>inline</code> और <code>extern inline</code> अनिवार्य रूप से C99 के पूर्णतया विपरीत हैं,<ref>{{Cite web|url=http://blahg.josefsipek.net/?p=529|title = Josef "Jeff" Sipek » GNU inline vs. C99 inline}}</ref> इस अपवाद के साथ कि gnu89 a की पुनर्परिभाषा की अनुमति देता है <code>extern inline</code> एक अयोग्य कार्य के रूप में कार्य करता है, जबकि C99 <code>inline</code> नहीं करता।<ref name="gcc-5-porting">{{Cite web|url=https://gcc.gnu.org/gcc-5/porting_to.html|title = Porting to GCC 5 - GNU Project}}</ref> इस प्रकार, gnu89 <code>extern inline</code> पुनर्परिभाषा के बिना C99 की प्रकार है <code>inline</code>, और ग्नू89 <code>inline</code> C99 की प्रकार है <code>extern inline</code>; दूसरे शब्दों में, gnu89 में, एक फ़ंक्शन परिभाषित किया गया है <code>inline</code> निरंतर होगा और एक फ़ंक्शन परिभाषित किया गया है <code>extern inline</code> बाहरी रूप से दिखाई देने वाले कार्य को कभी भी उत्सर्जित नहीं करेगा। इसके लिए तर्क यह है कि यह वेरिएबल्स से मेल खाता है, जिसके लिए भंडारण को कभी भी आरक्षित नहीं किया जाएगा यदि परिभाषित किया गया हो <code>extern</code> और निरंतर यदि बिना परिभाषित किया गया है। इसके विपरीत, C99 का तर्क यह है कि यदि इसका उपयोग किया जाता है तो यह [[कम से कम विस्मय का सिद्धांत]] होगा <code>inline</code> एक साइड-इफ़ेक्ट होगा - निरंतर फ़ंक्शन के एक गैर-इनलाइन संस्करण को उत्सर्जित करने के लिए - जो इसके नाम के विपरीत है।
-C99 के लिए इनलाइन फ़ंक्शंस के लिए एक बाहरी रूप से दिखाई देने वाला फ़ंक्शन उदाहरण प्रदान करने की आवश्यकता के बारे में और अगम्य कोड के साथ परिणामी समस्या के बारे में टिप्पणी, यथोचित परिवर्तनों के साथ-साथ gnu89 पर भी लागू होती है।
+कुछ लोग पूरी तरह से भिन्न दृष्टिकोण की अनुशंसा करते हैं, जो हेडर फ़ाइलों में इनलाइन के अतिरिक्त फ़ंक्शंस को स्थिर इनलाइन के रूप में परिभाषित करना है।<ref name="inline-c99-vs-gnu"/> फिर, कोई पहुंच योग्य कोड उत्पन्न नहीं होता है। चूंकि, विपरीत स्थिति में इस दृष्टिकोण में एक खामी है: यदि फ़ंक्शन को एक से अधिक अनुवाद इकाइयों में इनलाइन नहीं किया जा सका तो डुप्लिकेट कोड उत्पन्न किया जाएगा, उत्सर्जित फ़ंक्शन कोड को अनुवाद इकाइयों के बीच साझा नहीं किया जा सकता क्योंकि इसमें भिन्न-भिन्न एड्रेस होने चाहिए, यह एक और कमी है; हेडर फ़ाइल में स्टैटिक इनलाइन के रूप में परिभाषित ऐसे फ़ंक्शन का पता लेने से विभिन्न अनुवाद इकाइयों में भिन्न-भिन्न मान प्राप्त होंगे इसलिए, स्थिर इनलाइन फ़ंक्शंस का उपयोग मात्र तभी किया जाना चाहिए जब उनका उपयोग मात्र एक अनुवाद इकाई में किया जाता है, जिसका अर्थ है कि उन्हें मात्र संबंधित .सी फ़ाइल में जाना चाहिए, हेडर फ़ाइल में नहीं किया जाता है।
-जीसीसी तक और संस्करण 4.2 सहित gnu89 का उपयोग किया <code>inline</code> शब्दार्थ तब भी जब <code>-std=c99</code> स्पष्ट रूप से निर्दिष्ट किया गया था।<ref>{{Cite web|url=https://gcc.gnu.org/ml/gcc-patches/2007-02/msg00119.html|title = Ian Lance Taylor - Clean up extern inline}}</ref> संस्करण 5 के साथ,<ref name="gcc-5-porting"/>Gcc ने gnu89 से gnu11 बोली में स्विच किया, प्रभावी रूप से C99 को सक्षम किया <code>inline</code> डिफ़ॉल्ट रूप से शब्दार्थ। इसके अतिरिक्त gnu89 शब्दार्थ का उपयोग करने के लिए, उन्हें या तो स्पष्ट रूप से सक्षम करना होगा <code>-std=gnu89</code> या, मात्र इनलाइनिंग को प्रभावित करने के लिए, <code>-fgnu89-inline</code>, या जोड़कर <code>gnu_inline</code> सभी के लिए विशेषता <code>inline</code> घोषणाएं। C99 शब्दार्थ सुनिश्चित करने के लिए, या तो <code>-std=c99</code>, <code>-std=c11</code>, <code>-std=gnu99</code> या <code>-std=gnu11</code> (बिना <code>-fgnu89-inline</code>) उपयोग किया जा सकता है।<ref name="gcc-inline"/>
+=== जीएनयू89 ===
+इनलाइन और एक्सटर्न इनलाइन के जीएनयू89 शब्दार्थ अनिवार्य रूप से सी99 के पूर्णतया विपरीत हैं,<ref>{{Cite web|url=http://blahg.josefsipek.net/?p=529|title = Josef "Jeff" Sipek » GNU inline vs. C99 inline}}</ref> इस अपवाद के साथ कि जीएनयू89 एक बाहरी इनलाइन फ़ंक्शन को एक अयोग्य फ़ंक्शन के रूप में फिर से परिभाषित करने की अनुमति देता है, जबकि सी99 इनलाइन ऐसा नहीं करता है।<ref name="gcc-5-porting">{{Cite web|url=https://gcc.gnu.org/gcc-5/porting_to.html|title = Porting to GCC 5 - GNU Project}}</ref> इस प्रकार, पुनर्परिभाषा के बिना जीएनयू89 एक्सटर्न इनलाइन सी99 इनलाइन की तरह है, और जीएनयू89 इनलाइन सी99 एक्सटर्न इनलाइन की तरह है; दूसरे शब्दों में, जीएनयू89 में, एक फ़ंक्शन परिभाषित इनलाइन निरंतर होगा और एक फ़ंक्शन परिभाषित बाहरी इनलाइन कभी भी बाहरी रूप से दृश्यमान फ़ंक्शन उत्सर्जित नहीं करेगा, इसके लिए तर्क यह है कि यह वेरिएबल्स से मेल खाता है, जिसके लिए भंडारण कभी भी आरक्षित नहीं होगा यदि इसे बाहरी के रूप में परिभाषित किया गया है और निरंतर यदि इसके बिना परिभाषित किया गया है। इसके विपरीत, सी99 के लिए तर्क यह है कि यह आश्चर्यजनक होगा यदि इनलाइन का उपयोग करने का एक साइड-इफ़ेक्ट होगा - निरंतर फ़ंक्शन के एक गैर-इनलाइन संस्करण को उत्सर्जित करने के लिए - जो कि इसके नाम से पता चलता है, उसके विपरीत है।
+इनलाइन फ़ंक्शंस के लिए पूर्णतया एक बाहरी रूप से दृश्यमान फ़ंक्शन उदाहरण प्रदान करने की आवश्यकता के बारे में और पहुंच योग्य कोड के साथ परिणामी समस्या के बारे में सी99 की टिप्पणियाँ यथोचित परिवर्तनों के साथ जीएनयू89 पर भी लागू होती हैं।
+संस्करण 4.2 तक और इसमें सम्मलित जीसीसी ने जीएनयू89 इनलाइन शब्दार्थ का उपयोग किया, तब भी जब -एसटीडी =सी99 स्पष्ट रूप से निर्दिष्ट किया गया था।<ref>{{Cite web|url=https://gcc.gnu.org/ml/gcc-patches/2007-02/msg00119.html|title = Ian Lance Taylor - Clean up extern inline}}</ref> संस्करण 5 के साथ,<ref name="gcc-5-porting"/> जीसीसी ने जीएनयू89 से जीएनयू11 डिएलेक्ट में स्विच किया, जिससे डिफ़ॉल्ट रूप से सी99 इनलाइन शब्दार्थ को प्रभावी ढंग से सक्षम किया गया, इसके अतिरिक्त जीएनयू89 शब्दार्थ का उपयोग करने के लिए, उन्हें स्पष्ट रूप से सक्षम करना होगा, या तो -एसटीडी =जीएनयू89 के साथ या, मात्र इनलाइनिंग को प्रभावित करने के लिए, -एफजीएनयू89-इनलाइन, या सभी इनलाइन घोषणाओं में जीएनयू_इनलाइन विशेषता जोड़कर, सी99 शब्दार्थ सुनिश्चित करने के लिए, या तो -एसटीडी =सी99, -एसटीडी =सी11, -एसटीडी =जीएनयू99 या -एसटीडी =जीएनयू11 (-एफजीएनयू89-इनलाइन के बिना) का उपयोग किया जा सकता है।<ref name="gcc-inline"/>
 === सी ++ ===
-सी ++ में, एक फ़ंक्शन परिभाषित किया गया है <code>inline</code> यदि आवश्यक हो, तो अनुवाद इकाइयों के बीच साझा किए गए फ़ंक्शन का उत्सर्जन करेगा, सामान्यतः इसे ऑब्जेक्ट फ़ाइल के सामान्य अनुभाग में डालकर जिसके लिए इसकी आवश्यकता होती है। फ़ंक्शन की हर जगह एक ही परिभाषा होनी चाहिए, निरंतर के साथ <code>inline</code> क्वालीफायर। सी ++ में, <code>extern inline</code> वैसा ही है जैसा कि <code>inline</code>. सी ++ दृष्टिकोण के लिए तर्क यह है कि यह प्रोग्रामर के लिए सबसे सुविधाजनक विधि है, क्योंकि अगम्य कोड को हटाने के लिए कोई विशेष सावधानी नहीं बरती जानी चाहिए और सामान्य कार्यों की प्रकार, इससे कोई फर्क नहीं पड़ता कि क्या <code>extern</code> निर्दिष्ट है या नहीं। <code>inline</code> ई> क्वालीफायर स्वचालित रूप से एक वर्ग परिभाषा के हिस्से के रूप में परिभाषित फ़ंक्शन में जोड़ा जाता है।
+सी ++ में, इनलाइन परिभाषित एक फ़ंक्शन, यदि आवश्यक हो, अनुवाद इकाइयों के बीच साझा किए गए फ़ंक्शन को उत्सर्जित करेगा, सामान्यतः इसे ऑब्जेक्ट फ़ाइल के सामान्य अनुभाग में डालकर जिसके लिए इसकी आवश्यकता होती है। फ़ंक्शन की परिभाषा हर जगह समान होनी चाहिए, निरंतर इनलाइन क्वालिफायर के साथ, सी ++ में, एक्सटर्नल इनलाइन इनलाइन के समान है। सी ++ दृष्टिकोण के लिए तर्क यह है कि यह प्रोग्रामर के लिए सबसे सुविधाजनक विधि है, क्योंकि पहुंच योग्य कोड को हटाने के लिए कोई विशेष सावधानी नहीं बरतनी चाहिए और, सामान्य कार्यों की तरह, इससे कोई फर्क नहीं पड़ता कि बाहरी निर्दिष्ट है या नहीं, इनलाइन क्वालिफायर स्वचालित रूप से क्लास परिभाषा के भाग के रूप में परिभाषित फ़ंक्शन में जोड़ा जाता है।
 === आर्मसीसी ===
-C90 मोड में armcc प्रदान करता है <code>extern inline</code> और <code>inline</code> सिमेंटिक्स जो सी ++ के समान हैं: यदि आवश्यक हो तो ऐसी परिभाषाएं अनुवाद इकाइयों के बीच साझा किए गए फ़ंक्शन को छोड़ देंगी। C99 मोड में, <code>extern inline</code> निरंतर एक फ़ंक्शन का उत्सर्जन करता है, लेकिन सी ++ की प्रकार, इसे अनुवाद इकाइयों के बीच साझा किया जाएगा। इस प्रकार, समान कार्य को परिभाषित किया जा सकता है <code>extern inline</code> विभिन्न अनुवाद इकाइयों में।<ref>{{Cite web|url=http://infocenter.arm.com/help/topic/com.arm.doc.faqs/ka15831.html|title=Documentation – Arm Developer}}</ref> यह यूनिक्स सी कंपाइलर्स के पारंपरिक व्यवहार से मेल खाता है<ref>gcc manual page, description of <code>-fno-common</code></ref> एकाधिक गैर के लिए<code>extern</code> अप्रारंभीकृत वैश्विक चर की परिभाषाएँ।
+सी90 मोड में आर्मसीसी बाहरी इनलाइन और इनलाइन शब्दार्थ प्रदान करता है जो सी ++ के समान हैं: ऐसी परिभाषाएँ यदि आवश्यक हो तो अनुवाद इकाइयों के बीच साझा किए गए फ़ंक्शन का उत्सर्जन करेंगी। सी99 मोड में, एक्सटर्नल इनलाइन निरंतर एक फ़ंक्शन उत्सर्जित करता है, लेकिन सी ++ की तरह, इसे अनुवाद इकाइयों के बीच साझा किया जाएगा। इस प्रकार, एक ही फ़ंक्शन को विभिन्न अनुवाद इकाइयों में एक्सटर्नल इनलाइन परिभाषित किया जा सकता है।<ref>{{Cite web|url=http://infocenter.arm.com/help/topic/com.arm.doc.faqs/ka15831.html|title=Documentation – Arm Developer}}</ref> यह अप्रारंभीकृत वैश्विक चर की कई गैर-बाहरी परिभाषाओं के लिए यूनिक्स सी कंपाइलर्स<ref>gcc manual page, description of <code>-fno-common</code></ref> के पारंपरिक व्यवहार से मेल खाता है।
 == प्रतिबंध ==
-एक का पता लेना <code>inline</code> फ़ंक्शन को किसी भी स्थितियाँ में उस फ़ंक्शन की गैर-रेखांकित प्रतिलिपि के लिए कोड की आवश्यकता होती है।
+किसी इनलाइन फ़ंक्शन का पता लेने के लिए किसी भी स्थिति में उस फ़ंक्शन की गैर-इनलाइन प्रतिलिपि के लिए कोड की आवश्यकता होती है।
-C99 में, ए <code>inline</code> या <code>extern inline</code> फंक्शन का उपयोग नहीं करना चाहिए <code>static</code> वैश्विक चर या गैर परिभाषित<code>const</code> <code>static</code> स्थानीय चर। <code>const static</code> स्थानीय चर भिन्न-भिन्न अनुवाद इकाइयों में भिन्न-भिन्न ऑब्जेक्ट हो सकते हैं या नहीं भी हो सकते हैं, यह इस बात पर निर्भर करता है कि फ़ंक्शन इनलाइन था या कॉल किया गया था या नहीं। मात्र <code>static inline</code> परिभाषाएँ पहचानकर्ताओं को बिना किसी प्रतिबंध के आंतरिक लिंकेज के साथ संदर्भित कर सकती हैं; वे प्रत्येक अनुवाद इकाई में भिन्न-भिन्न वस्तुएँ होंगी। सी ++ में, दोनों <code>const</code> और गैर-<code>const</code> <code>static</code> स्थानीय लोगों को अनुमति है और वे सभी अनुवाद इकाइयों में एक ही वस्तु का उल्लेख करते हैं।
+सी99 में, एक इनलाइन या बाहरी इनलाइन फ़ंक्शन को स्थिर वैश्विक चर तक नहीं पहुंचना चाहिए या गैर-कॉन्स्ट स्थिर स्थानीय चर को परिभाषित नहीं करना चाहिए, स्थिर स्थिर स्थानीय चर भिन्न-भिन्न अनुवाद इकाइयों में भिन्न-भिन्न ऑब्जेक्ट हो भी सकते हैं और नहीं भी, यह इस बात पर निर्भर करता है कि फ़ंक्शन इनलाइन किया गया था या कॉल किया गया था। मात्र स्थिर इनलाइन परिभाषाएँ बिना किसी प्रतिबंध के आंतरिक लिंकेज वाले पहचानकर्ताओं को संदर्भित कर सकती हैं; वे प्रत्येक अनुवाद इकाई में भिन्न-भिन्न वस्तुएँ होती है। सी++ में, कॉन्स्ट और नॉन-कॉन्स्ट दोनों स्थिर स्थानीय की अनुमति है और वे सभी अनुवाद इकाइयों में एक ही ऑब्जेक्ट को संदर्भित करते हैं।
-जीसीसी कार्यों को इनलाइन नहीं कर सकता है यदि<ref name="gcc-inline"/># वे विविध कार्य हैं,
+जीसीसी इनलाइन फ़ंक्शंस नहीं कर सकता है यदि<ref name="gcc-inline"/>
-# उपयोग <code>[[alloca]]</code>
+# वे विविध हैं,
-# गणना का उपयोग करें <code>goto</code>
+# कंप्यूटेड गोटो का उपयोग करें
-# नॉनलोकल का उपयोग करें <code>goto</code>
+# गैर-स्थानीय गोटो का उपयोग करें
 # [[नेस्टेड समारोह|नेस्टेड फंक्शन]] का उपयोग करें
-# उपयोग <code>setjmp</code>
+# सेटजेएमपी का उपयोग करें
-# उपयोग <code>__builtin_longjmp</code>
+# __बिल्टिन_लॉन्गजम्प का उपयोग करें
-# उपयोग <code>__builtin_return</code>, या
+# __बिल्टिन_रिटर्न का उपयोग करें, या
-# उपयोग <code>__builtin_apply_args</code>
+# __बिल्टिन_अप्लाई_आर्ग्स का उपयोग करें
-एमएसडीएन पर माइक्रोसॉफ्ट विनिर्देशों के आधार पर, एमएस विज़ुअल सी ++ इनलाइन नहीं कर सकता (यहां तक कि नहीं <code>__forceinline</code>), यदि
+एमएसडीएन पर माइक्रोसॉफ्ट विनिर्देशों के आधार पर, एमएस विज़ुअल सी ++ इनलाइन नहीं कर सकता (__forceinline के साथ भी नहीं), यदि
 # फ़ंक्शन या उसके कॉलर को /Ob0 (डीबग बिल्ड के लिए डिफ़ॉल्ट विकल्प) के साथ संकलित किया गया है।
-# फ़ंक्शन और कॉलर विभिन्न प्रकार के अपवाद हैंडलिंग (एक में C ++ अपवाद हैंडलिंग, दूसरे में संरचित अपवाद हैंडलिंग) का उपयोग करते हैं।
+# फ़ंक्शन और कॉलर विभिन्न प्रकार के अपवाद हैंडलिंग (एक में सी ++ अपवाद हैंडलिंग, दूसरे में संरचित अपवाद हैंडलिंग) का उपयोग करते हैं।
-# फ़ंक्शन में एक चर तर्क सूची है।
+# फ़ंक्शन में एक परिवर्तनीय तर्क सूची है।
-# फ़ंक्शन [[इनलाइन असेंबली]] का उपयोग करता है, जब तक कि /Og, /Ox, /O1, या /O2 के साथ संकलित न हो।
+# फ़ंक्शन [[इनलाइन असेंबली]] का उपयोग करता है, जब तक कि इसे /Og, /Ox, /O1, या /O2 के साथ संकलित नहीं किया जाता है।
-# फ़ंक्शन [[रिकर्सन (कंप्यूटर विज्ञान)]] है और इसके साथ नहीं है <code>#pragma inline_recursion(on)</code>. प्रागमा के साथ, पुनरावर्ती कार्यों को 16 कॉल की डिफ़ॉल्ट गहराई में रेखांकित किया गया है। इनलाइनिंग गहराई को कम करने के लिए, उपयोग करें <code>inline_depth</code> pragma.
+# फ़ंक्शन [[रिकर्सन (कंप्यूटर विज्ञान)]] है और <code>#pragma inline_recursion(on)</code> के साथ नहीं है। प्राग्मा के साथ, पुनरावर्ती फ़ंक्शन 16 कॉल की डिफ़ॉल्ट गहराई पर इनलाइन होते हैं। इनलाइनिंग गहराई को कम करने के लिए, इनलाइन_डेप्थ प्राग्मा का उपयोग किया जाता है।
-# फ़ंक्शन [[आभासी समारोह|आभासी फंक्शन]] है और इसे वस्तुतः कहा जाता है। आभासी कार्यों के लिए सीधी कॉल को इनलाइन किया जा सकता है।
+# यह फ़ंक्शन [[आभासी समारोह|आभासी फंक्शन]] है और इसे वर्चुअली कहा जाता है। वर्चुअल फ़ंक्शंस पर सीधी कॉल को इनलाइन किया जा सकता है।
-# प्रोग्राम फ़ंक्शन का पता लेता है और फ़ंक्शन को पॉइंटर के माध्यम से कॉल किया जाता है। उन कार्यों के लिए सीधी कॉल जिनका पता लिया जा चुका है, को इनलाइन किया जा सकता है।
+# प्रोग्राम फ़ंक्शन का पता लेता है और पॉइंटर के माध्यम से फ़ंक्शन पर कॉल किया जाता है। जिन कार्यों का पता लिया गया है, उनके लिए सीधी कॉल को इनलाइन किया जा सकता है।
-# फंक्शन को नग्न के साथ भी चिह्नित किया गया है <code>__declspec</code> संशोधक।
+# फ़ंक्शन को नेक्ड __देकलस्पेस संशोधक के साथ भी चिह्नित किया गया है।
 == समस्याएं ==
-{{see also|Inline expansion#Effect on performance}}
+यह भी देखें: [[इनलाइन विस्तार § प्रदर्शन पर प्रभाव]]
-सामान्य रूप से इनलाइन विस्तार की समस्याओं के अतिरिक्त (देखें {{Section link|Inline expansion#Effect on performance}}), <code>inline</code> कई कारणों से एक भाषा सुविधा के रूप में कार्य उतने मूल्यवान नहीं हो सकते जितने वे दिखाई देते हैं:
+सामान्यतः इनलाइन विस्तार की समस्याओं के अतिरिक्त (देखें [[इनलाइन विस्तार § प्रदर्शन पर प्रभाव]]), भाषा सुविधा के रूप में इनलाइन फ़ंक्शन कई कारणों से उतने मूल्यवान नहीं हो सकते जितने वे दिखाई देते हैं:
-* अधिकांशतः, एक कंपाइलर यह तय करने के लिए मानव की तुलना में उत्तम स्थिति में होता है कि किसी विशेष फ़ंक्शन को इनलाइन किया जाना चाहिए या नहीं। कभी-कभी संकलक उतने कार्यों को इनलाइन करने में सक्षम नहीं हो सकता जितना प्रोग्रामर इंगित करता है।
+* अधिकांशतः, एक कंपाइलर यह तय करने के लिए मानव से उत्तम स्थिति में होता है कि किसी विशेष फ़ंक्शन को इनलाइन किया जाना चाहिए या नहीं, कभी-कभी कंपाइलर उतने फ़ंक्शन इनलाइन करने में सक्षम नहीं हो सकता जितना प्रोग्रामर इंगित करता है।
-* ध्यान देने वाली एक महत्वपूर्ण बात यह है कि कोड (का <code>inline</code> function) अपने क्लाइंट (कॉलिंग फ़ंक्शन) के सामने आ जाता है।
+* ध्यान देने योग्य एक महत्वपूर्ण बात यह है कि कोड (इनलाइन फ़ंक्शन का) उसके क्लाइंट (कॉलिंग फ़ंक्शन) के सामने आ जाता है।
-* जैसे-जैसे कार्य विकसित होते हैं, वे इनलाइनिंग के लिए उपयुक्त हो सकते हैं जहां वे पहले नहीं थे, या जहां वे पहले थे वहां इनलाइनिंग के लिए अब उपयुक्त नहीं हैं। किसी फ़ंक्शन को इनलाइन या अन-इनलाइन करते समय मैक्रोज़ में कनवर्ट करने से आसान होता है, फिर भी इसे अतिरिक्त रखरखाव की आवश्यकता होती है जो सामान्यतः अपेक्षाकृत कम लाभ देती है।
+* जैसे-जैसे फ़ंक्शंस विकसित होते हैं, वे इनलाइनिंग के लिए उपयुक्त हो सकते हैं जहाँ वे पहले नहीं थे, या अब इनलाइनिंग के लिए उपयुक्त नहीं रह जाते जहाँ वे पहले थे। चूंकि किसी फ़ंक्शन को इनलाइन करना या अन-इनलाइन करना मैक्रोज़ में कनवर्ट करने से आसान है, फिर भी इसके लिए अतिरिक्त रखरखाव की आवश्यकता होती है जो सामान्यतः अपेक्षाकृत कम लाभ देता है।
-* देशी सी-आधारित संकलन प्रणालियों में प्रसार में उपयोग किए जाने वाले इनलाइन फ़ंक्शंस संकलन समय को बढ़ा सकते हैं, क्योंकि उनके बॉडी के मध्यवर्ती प्रतिनिधित्व को प्रत्येक कॉल साइट में कॉपी किया जाता है।
+* देशी सी-आधारित संकलन प्रणालियों में प्रसार में उपयोग किए जाने वाले इनलाइन फ़ंक्शन संकलन समय को बढ़ा सकते हैं, क्योंकि उनके बॉडी के मध्यवर्ती प्रतिनिधित्व को प्रत्येक कॉल साइट में कॉपी किया जाता है।
-* की विशिष्टता <code>inline</code> सी 99 में फ़ंक्शन की पूर्णतया एक बाहरी परिभाषा की आवश्यकता होती है, यदि इसे कहीं उपयोग किया जाता है। यदि प्रोग्रामर द्वारा ऐसी परिभाषा प्रदान नहीं की गई है, तो इससे आसानी से लिंकर त्रुटियां हो सकती हैं। यह ऑप्टिमाइज़ेशन बंद होने के साथ हो सकता है, जो सामान्यतः इनलाइनिंग को रोकता है। दूसरी ओर, परिभाषाओं को जोड़ना अगम्य कोड का कारण बन सकता है यदि प्रोग्रामर सावधानी से इसे टालता नहीं है, लिंक करने के लिए उन्हें लाइब्रेरी में डालकर, लिंक टाइम ऑप्टिमाइज़ेशन का उपयोग करके, या <code>static inline</code>.
+* सी99 में इनलाइन के विनिर्देशन के लिए फ़ंक्शन की पूर्णतया एक बाहरी परिभाषा की आवश्यकता होती है, यदि इसका उपयोग कहीं किया जाता है। यदि ऐसी कोई परिभाषा प्रोग्रामर द्वारा प्रदान नहीं की गई थी, तो इससे आसानी से लिंकर त्रुटियां हो सकती हैं। ऑप्टिमाइज़ेशन बंद होने पर ऐसा हो सकता है, जो सामान्यतः इनलाइनिंग को रोकता है। दूसरी ओर, परिभाषाएँ जोड़ने से कोड अगम्य हो सकता है यदि प्रोग्रामर उन्हें लिंक करने के लिए लाइब्रेरी में डालकर, लिंक टाइम ऑप्टिमाइज़ेशन या स्टैटिक इनलाइन का उपयोग करके सावधानी से नहीं बचता है।
-* C++ में, a को परिभाषित करना आवश्यक है <code>inline</code> इसका उपयोग करने वाले प्रत्येक मॉड्यूल (अनुवाद इकाई) में कार्य करता है, जबकि एक सामान्य कार्य को मात्र एक मॉड्यूल में परिभाषित किया जाना चाहिए। अन्यथा अन्य सभी मॉड्यूलों से स्वतंत्र रूप से एक मॉड्यूल को संकलित करना संभव नहीं होगा। कंपाइलर के आधार पर, यह प्रत्येक संबंधित ऑब्जेक्ट फ़ाइल को प्रत्येक मॉड्यूल के लिए फ़ंक्शन के कोड की प्रतिलिपि रखने का कारण बन सकता है, जो इनलाइन नहीं किया जा सका।
+* सी ++ में, इसका उपयोग करने वाले प्रत्येक मॉड्यूल (अनुवाद इकाई) में एक इनलाइन फ़ंक्शन को परिभाषित करना आवश्यक है, जबकि एक सामान्य फ़ंक्शन को मात्र एक मॉड्यूल में परिभाषित किया जाता है। अन्यथा किसी एक मॉड्यूल को अन्य सभी मॉड्यूल से स्वतंत्र रूप से संकलित करना संभव नहीं होता है। कंपाइलर के आधार पर, इसके कारण प्रत्येक संबंधित ऑब्जेक्ट फ़ाइल में फ़ंक्शन के कोड की एक प्रति सम्मलित हो सकती है, प्रत्येक मॉड्यूल के लिए कुछ उपयोग के साथ जिसे इनलाइन नहीं किया जा सकता है।
-* [[उपकरणों के नियंत्रण के लिए सॉफ्टवेयर]] में, प्रागमा स्टेटमेंट्स जैसे विशेष संकलक निर्देशों के उपयोग द्वारा अधिकांशतः कुछ कार्यों को कुछ कोड अनुभागों में रखने की आवश्यकता होती है। कभी-कभी, एक मेमोरी सेगमेंट में एक फ़ंक्शन को किसी अन्य मेमोरी सेगमेंट में फ़ंक्शन को कॉल करने की आवश्यकता हो सकती है, और यदि कॉल किए गए फ़ंक्शन की इनलाइनिंग होती है, तो कॉल किए गए फ़ंक्शन का कोड उस सेगमेंट में समाप्त हो सकता है जहां यह नहीं होना चाहिए। उदाहरण के लिए, उच्च-प्रदर्शन स्मृति खंड कोड स्थान में बहुत सीमित हो सकते हैं, और यदि ऐसे स्थान से संबंधित कोई फ़ंक्शन किसी अन्य बड़े फ़ंक्शन को कॉल करता है जो उच्च-प्रदर्शन अनुभाग में नहीं है और कहा गया फ़ंक्शन अनुपयुक्त रूप से इनलाइन हो जाता है, तो इससे उच्च-प्रदर्शन स्मृति खंड कोड स्थान से बाहर हो सकता है। इस कारण से, कभी-कभी यह सुनिश्चित करना आवश्यक होता है कि फ़ंक्शन इनलाइन न हो जाएं।
+* [[एम्बेडेड]] सॉफ़्टवेयर में, अधिकांशतः कुछ कार्यों को में,"प्रागमा" स्टेटमेंट जैसे विशेष कंपाइलर निर्देशों के उपयोग द्वारा कुछ कोड अनुभागों में रखने की आवश्यकता होती है। कभी-कभी, एक मेमोरी सेगमेंट में एक फ़ंक्शन को दूसरे मेमोरी सेगमेंट में एक फ़ंक्शन को कॉल करने की आवश्यकता हो सकती है, और यदि कॉल किए गए फ़ंक्शन की इनलाइनिंग होती है, तो कॉल किए गए फ़ंक्शन का कोड उस सेगमेंट में समाप्त हो सकता है जहां यह नहीं होता है। उदाहरण के लिए, उच्च-प्रदर्शन मेमोरी सेगमेंट कोड स्पेस में बहुत सीमित हो सकते हैं, और यदि ऐसे स्पेस में उपलब्ध एक फ़ंक्शन किसी अन्य बड़े फ़ंक्शन को कॉल करता है जो उच्च-प्रदर्शन अनुभाग में नहीं होता है और कॉल किया गया फ़ंक्शन अनुचित रूप से इनलाइन हो जाता है, तो इससे उच्च-प्रदर्शन मेमोरी सेगमेंट में कोड स्थान समाप्त हो सकता है। फ़ंक्शन इनलाइन न हो जाएं इस कारण से, कभी-कभी यह सुनिश्चित करना आवश्यक होता है।
 == उद्धरण ==
-: एक फंक्शन घोषणा [। . . ] एक इनलाइन विनिर्देशक के साथ एक इनलाइन फ़ंक्शन घोषित करता है। इनलाइन विनिर्देशक कार्यान्वयन को इंगित करता है कि कॉल के बिंदु पर फ़ंक्शन बॉडी के इनलाइन प्रतिस्थापन को सामान्य फ़ंक्शन कॉल तंत्र के लिए प्राथमिकता दी जानी चाहिए। कॉल के बिंदु पर इस इनलाइन प्रतिस्थापन को करने के लिए कार्यान्वयन की आवश्यकता नहीं है; चूंकि, यदि यह इनलाइन प्रतिस्थापन छोड़ दिया गया हो, 7.1.2 द्वारा परिभाषित इनलाइन फ़ंक्शंस के अन्य नियमों का अभी भी सम्मान किया जाएगा।
+: "एक फ़ंक्शन घोषणा [...] एक इनलाइन विनिर्देशक के साथ एक इनलाइन फ़ंक्शन घोषित करता है। इनलाइन विनिर्देशक इम्प्लीमेंटेशन को इंगित करता है कि कॉल के बिंदु पर फ़ंक्शन बॉडी के इनलाइन प्रतिस्थापन को सामान्य फ़ंक्शन कॉल तंत्र के लिए प्राथमिकता दी जानी है। एक इम्प्लीमेंटेशन कॉल के बिंदु पर इस इनलाइन प्रतिस्थापन को निष्पादित करने की आवश्यकता नहीं है; चूंकि, यदि इस इनलाइन प्रतिस्थापन को छोड़ दिया गया हो, 7.1.2 द्वारा परिभाषित इनलाइन फ़ंक्शन के अन्य नियमों का अभी भी सम्मान किया जा सकता है।
-:— ISO/IEC 14882:2011, वर्तमान C++ मानक, खंड 7.1.2
+:— आईएसओ/आईईसी 14882:2011, वर्तमान सी++ मानक, खंड 7.1.2
-: एक इनलाइन फ़ंक्शन विनिर्देशक के साथ घोषित एक फ़ंक्शन एक इनलाइन फ़ंक्शन है। [ . . . ] किसी फ़ंक्शन को इनलाइन फ़ंक्शन बनाने से पता चलता है कि फ़ंक्शन को जितनी जल्दी हो सके कॉल करें। जिस हद तक ऐसे सुझाव प्रभावी हैं, वह कार्यान्वयन-परिभाषित है (''फुटनोट: उदाहरण के लिए, एक कार्यान्वयन इनलाइन प्रतिस्थापन कभी नहीं कर सकता है, या मात्र इनलाइन प्रतिस्थापन इनलाइन घोषणा के दायरे में कॉल करने के लिए कर सकता है।'')
+: "इनलाइन फ़ंक्शन विनिर्देशक के साथ घोषित एक फ़ंक्शन एक इनलाइन फ़ंक्शन है। [...] एक फ़ंक्शन को इनलाइन फ़ंक्शन बनाने से पता चलता है कि फ़ंक्शन पर कॉल जितनी तेज़ हो सके, ऐसे सुझाव किस सीमा तक प्रभावी हैं यह इम्प्लीमेंटेशन-परिभाषित है ( फ़ुटनोट: उदाहरण के लिए, एक इम्प्लीमेंटेशन कभी भी इनलाइन प्रतिस्थापन नहीं कर सकता है, या मात्र इनलाइन घोषणा के दायरे में कॉल के लिए इनलाइन प्रतिस्थापन कर सकता है।)
-: [ . . . ] एक इनलाइन परिभाषा फ़ंक्शन के लिए बाहरी परिभाषा प्रदान नहीं करती है, और किसी अन्य अनुवाद इकाई (प्रोग्रामिंग) में बाहरी परिभाषा को प्रतिबंधित नहीं करती है। एक इनलाइन परिभाषा एक बाहरी परिभाषा के लिए एक विकल्प प्रदान करती है, जिसका उपयोग अनुवादक उसी अनुवाद इकाई में फ़ंक्शन के लिए किसी कॉल को लागू करने के लिए कर सकता है। यह निर्दिष्ट नहीं है कि फ़ंक्शन के लिए कॉल इनलाइन परिभाषा या बाहरी परिभाषा का उपयोग करता है या नहीं।
+: "[...] एक इनलाइन परिभाषा फ़ंक्शन के लिए बाहरी परिभाषा प्रदान नहीं करती है, और किसी अन्य अनुवाद इकाई में बाहरी परिभाषा को प्रतिबंधित नहीं करती है। एक इनलाइन परिभाषा बाहरी परिभाषा का एक विकल्प प्रदान करती है, जिसका उपयोग एक अनुवादक उसी अनुवाद इकाई में फ़ंक्शन में किसी भी कॉल को लागू करने के लिए कर सकता है। यह निर्दिष्ट नहीं है कि फ़ंक्शन पर कॉल इनलाइन परिभाषा या बाहरी परिभाषा का उपयोग करती है या नहीं।"
-:— ISO 9899:1999(E), C99 मानक, खंड 6.7.4
+:— आईएसओ 9899:1999(ई), सी99 मानक, खंड 6.7.4
 == यह भी देखें ==
@@ Line 162: / Line 156: @@
 == बाहरी संबंध ==
-* [https://gcc.gnu.org/onlinedocs/gcc/Inline.html Inline functions] with the [[GNU Compiler Collection]] (GCC)
+* [https://gcc.gnu.org/onlinedocs/gcc/Inline.html Inline functions] with the [[GNU Compiler Collection|जीएनयू Compiler Collection]] (GCC)
 * [https://lists.llvm.org/pipermail/llvm-dev/2021-August/152031.html Summary of "inline" semantics in C and C++], by [[LLVM]] contributor David Chisnall
-{{DEFAULTSORT:Inline Function}}[[Category: सॉफ्टवेयर अनुकूलन]]
+{{DEFAULTSORT:Inline Function}}
-[[Category: Machine Translated Page]]
+[[Category:Articles with hatnote templates targeting a nonexistent page|Inline Function]]
-[[Category:Created On 14/06/2023]]
+[[Category:CS1 errors]]
+[[Category:Created On 14/06/2023|Inline Function]]
+[[Category:Lua-based templates|Inline Function]]
+[[Category:Machine Translated Page|Inline Function]]
+[[Category:Pages with script errors|Inline Function]]
+[[Category:Templates Vigyan Ready|Inline Function]]
+[[Category:Templates that add a tracking category|Inline Function]]
+[[Category:Templates that generate short descriptions|Inline Function]]
+[[Category:Templates using TemplateData|Inline Function]]
+[[Category:सॉफ्टवेयर अनुकूलन|Inline Function]]

Anonymous

Search

इनलाइन फ़ंक्शन: Difference between revisions

Namespaces

More

Page actions

Latest revision as of 10:35, 15 July 2023

Contents

उदाहरण

मानक समर्थन

नॉनस्टैंडर्ड एक्सटेंशन

इनलाइन फ़ंक्शंस का संग्रहण वर्ग

सी 99

जीएनयू89

सी ++

आर्मसीसी

प्रतिबंध

समस्याएं

उद्धरण

यह भी देखें

संदर्भ

बाहरी संबंध

Navigation

Navigation

Wiki tools

Wiki tools

Anonymous

Search

इनलाइन फ़ंक्शन: Difference between revisions

Latest revision as of 10:35, 15 July 2023

उदाहरण

मानक समर्थन

नॉनस्टैंडर्ड एक्सटेंशन

इनलाइन फ़ंक्शंस का संग्रहण वर्ग

सी 99

जीएनयू89

सी ++

आर्मसीसी

प्रतिबंध

समस्याएं

उद्धरण

यह भी देखें

संदर्भ

बाहरी संबंध

Navigation

Wiki tools

Page tools

Other projects

Categories