इनलाइन फ़ंक्शन

This article is about inline functions in C and C++. For inline expansion more generally, see Inline expansion.

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

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

उदाहरण

एक inline function को C या C++ में इस प्रकार लिखा जा सकता है:

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

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

swap(&x, &y);

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

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

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

मानक समर्थन

C++ और C99, लेकिन इसके पूर्ववर्ती K&R C और C89 (C संस्करण) के लिए समर्थन नहीं है inline कार्य, हालांकि विभिन्न शब्दार्थों के साथ। दोनों ही मामलों में, inline इनलाइनिंग को मजबूर नहीं करता है; संकलक फ़ंक्शन को इनलाइन नहीं करने का चयन करने के लिए स्वतंत्र है, या केवल कुछ मामलों में। अलग-अलग कंपाइलर इस बात में भिन्न होते हैं कि इनलाइन में वे कितने जटिल कार्य कर सकते हैं। विजुअल सी प्लस प्लस | माइक्रोसॉफ्ट विज़ुअल सी++ और जीएनयू संकलक संग्रह जैसे मेनस्ट्रीम सी++ कंपाइलर्स एक ऐसे विकल्प का समर्थन करते हैं जो कंपाइलर्स को स्वचालित रूप से किसी भी उपयुक्त फ़ंक्शन को इनलाइन करने देता है, यहां तक ​​​​कि उन लोगों के रूप में चिह्नित नहीं किया गया है। inline कार्य करता है। हालाँकि, केवल छोड़ना inline कीवर्ड को संकलक को सभी इनलाइनिंग निर्णय लेने देना संभव नहीं है, क्योंकि लिंकर तब विभिन्न अनुवाद इकाइयों में डुप्लिकेट परिभाषाओं के बारे में शिकायत करेगा। यह है क्योंकि inline न केवल संकलक को संकेत देता है कि फ़ंक्शन को रेखांकित किया जाना चाहिए, इसका प्रभाव यह भी है कि संकलक फ़ंक्शन की कॉल करने योग्य आउट-ऑफ-लाइन प्रति उत्पन्न करेगा (इनलाइन फ़ंक्शंस के #Storage वर्ग देखें)।

अमानक एक्सटेंशन

GNU C, बोली gnu89 के हिस्से के रूप में जो इसे प्रदान करता है, के लिए समर्थन है inline C89 के विस्तार के रूप में। हालाँकि, शब्दार्थ C++ और C99 दोनों से भिन्न है। C90 मोड में armcc भी प्रदान करता है inline एक गैर-मानक विस्तार के रूप में, शब्दार्थ के साथ gnu89 और C99 से भिन्न।

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

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

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

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

• 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

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

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

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

भंडारण वर्ग का प्रभाव extern जब लागू किया जाता है या लागू नहीं किया जाता है inline कार्य सी बोलियों के बीच भिन्न होते हैं और सी ++।

सी 99

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

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

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

अगम्य कोड को अंतिम निष्पादन योग्य में जोड़े जाने से रोकने के लिए यदि किसी फ़ंक्शन के सभी उपयोग इनलाइन किए गए थे, तो यह सलाह दी जाती हैऐसी सभी .c फ़ाइलों की ऑब्जेक्ट फ़ाइलों को एक सिंगल के साथ रखने के लिए extern inline आमतौर पर एक स्थिर पुस्तकालय फ़ाइल में कार्य करता है ar rcs, फिर अलग-अलग ऑब्जेक्ट फ़ाइलों के अतिरिक्त उस लाइब्रेरी से लिंक करें। यह केवल उन ऑब्जेक्ट फ़ाइलों को लिंक करने का कारण बनता है जिनकी वास्तव में आवश्यकता होती है, ऑब्जेक्ट फ़ाइलों को सीधे लिंक करने के विपरीत, जिसके कारण उन्हें हमेशा निष्पादन योग्य में शामिल किया जाता है। हालाँकि, लाइब्रेरी फ़ाइल को लिंकर कमांड लाइन पर अन्य सभी ऑब्जेक्ट फ़ाइलों के बाद निर्दिष्ट किया जाना चाहिए, क्योंकि लाइब्रेरी फ़ाइल के बाद कार्यों के लिए निर्दिष्ट ऑब्जेक्ट फ़ाइलों से कॉल को लिंकर द्वारा नहीं माना जाएगा। से कॉल करता है inline दूसरे के लिए कार्य करता है inline कार्यों को लिंकर द्वारा स्वचालित रूप से हल किया जाएगा ( s में विकल्प ar rcs यह सुनिश्चित करता है)।

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

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

gnu89

gnu89 का शब्दार्थ inline और extern inline अनिवार्य रूप से C99 के बिल्कुल विपरीत हैं, इस अपवाद के साथ कि gnu89 a की पुनर्परिभाषा की अनुमति देता है extern inline एक अयोग्य कार्य के रूप में कार्य करता है, जबकि C99 inline नहीं करता। इस प्रकार, gnu89 extern inline पुनर्परिभाषा के बिना C99 की प्रकार है inline, और ग्नू89 inline C99 की प्रकार है extern inline; दूसरे शब्दों में, gnu89 में, एक फ़ंक्शन परिभाषित किया गया है inline हमेशा होगा और एक फ़ंक्शन परिभाषित किया गया है extern inline बाहरी रूप से दिखाई देने वाले कार्य को कभी भी उत्सर्जित नहीं करेगा। इसके लिए तर्क यह है कि यह वेरिएबल्स से मेल खाता है, जिसके लिए भंडारण को कभी भी आरक्षित नहीं किया जाएगा यदि परिभाषित किया गया हो extern और हमेशा अगर बिना परिभाषित किया गया है। इसके विपरीत, C99 का तर्क यह है कि यदि इसका उपयोग किया जाता है तो यह कम से कम विस्मय का सिद्धांत होगा inline एक साइड-इफ़ेक्ट होगा - हमेशा फ़ंक्शन के एक गैर-इनलाइन संस्करण को उत्सर्जित करने के लिए - जो इसके नाम के विपरीत है।

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

जीसीसी तक और संस्करण 4.2 सहित gnu89 का इस्तेमाल किया inline शब्दार्थ तब भी जब -std=c99 स्पष्ट रूप से निर्दिष्ट किया गया था। संस्करण 5 के साथ,Gcc ने gnu89 से gnu11 बोली में स्विच किया, प्रभावी रूप से C99 को सक्षम किया inline डिफ़ॉल्ट रूप से शब्दार्थ। इसके अतिरिक्त gnu89 शब्दार्थ का उपयोग करने के लिए, उन्हें या तो स्पष्ट रूप से सक्षम करना होगा -std=gnu89 या, केवल इनलाइनिंग को प्रभावित करने के लिए, -fgnu89-inline, या जोड़कर gnu_inline सभी के लिए विशेषता inline घोषणाएं। C99 शब्दार्थ सुनिश्चित करने के लिए, या तो -std=c99, -std=c11, -std=gnu99 या -std=gnu11 (बिना -fgnu89-inline) इस्तेमाल किया जा सकता है।

सी ++

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

आर्मसीसी

C90 मोड में armcc प्रदान करता है extern inline और inline सिमेंटिक्स जो सी ++ के समान हैं: यदि आवश्यक हो तो ऐसी परिभाषाएं अनुवाद इकाइयों के बीच साझा किए गए फ़ंक्शन को छोड़ देंगी। C99 मोड में, extern inline हमेशा एक फ़ंक्शन का उत्सर्जन करता है, लेकिन सी ++ की प्रकार, इसे अनुवाद इकाइयों के बीच साझा किया जाएगा। इस प्रकार, समान कार्य को परिभाषित किया जा सकता है extern inline विभिन्न अनुवाद इकाइयों में। यह यूनिक्स सी कंपाइलर्स के पारंपरिक व्यवहार से मेल खाता है एकाधिक गैर के लिएextern अप्रारंभीकृत वैश्विक चर की परिभाषाएँ।

प्रतिबंध

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

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

जीसीसी कार्यों को इनलाइन नहीं कर सकता है यदि# वे विविध कार्य हैं,

1. उपयोग alloca
2. गणना का उपयोग करें goto
3. नॉनलोकल का उपयोग करें goto
4. नेस्टेड समारोह का उपयोग करें
5. उपयोग setjmp
6. उपयोग __builtin_longjmp
7. उपयोग __builtin_return, या
8. उपयोग __builtin_apply_args

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

1. फ़ंक्शन या उसके कॉलर को /Ob0 (डीबग बिल्ड के लिए डिफ़ॉल्ट विकल्प) के साथ संकलित किया गया है।
2. फ़ंक्शन और कॉलर विभिन्न प्रकार के अपवाद हैंडलिंग (एक में C ++ अपवाद हैंडलिंग, दूसरे में संरचित अपवाद हैंडलिंग) का उपयोग करते हैं।
3. फ़ंक्शन में एक चर तर्क सूची है।
4. फ़ंक्शन इनलाइन असेंबली का उपयोग करता है, जब तक कि /Og, /Ox, /O1, या /O2 के साथ संकलित न हो।
5. फ़ंक्शन रिकर्सन (कंप्यूटर विज्ञान) है और इसके साथ नहीं है #pragma inline_recursion(on). प्रागमा के साथ, पुनरावर्ती कार्यों को 16 कॉल की डिफ़ॉल्ट गहराई में रेखांकित किया गया है। इनलाइनिंग गहराई को कम करने के लिए, उपयोग करें inline_depth pragma.
6. फ़ंक्शन आभासी समारोह है और इसे वस्तुतः कहा जाता है। आभासी कार्यों के लिए सीधी कॉल को इनलाइन किया जा सकता है।
7. प्रोग्राम फ़ंक्शन का पता लेता है और फ़ंक्शन को पॉइंटर के माध्यम से कॉल किया जाता है। उन कार्यों के लिए सीधी कॉल जिनका पता लिया जा चुका है, को इनलाइन किया जा सकता है।
8. समारोह को नग्न के साथ भी चिह्नित किया गया है __declspec संशोधक।

समस्याएं

See also: Inline expansion § Effect on performance

सामान्य रूप से इनलाइन विस्तार की समस्याओं के अलावा (देखें Inline expansion § Effect on performance), inline कई कारणों से एक भाषा सुविधा के रूप में कार्य उतने मूल्यवान नहीं हो सकते जितने वे दिखाई देते हैं:

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

उद्धरण

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

— ISO/IEC 14882:2011, वर्तमान C++ मानक, खंड 7.1.2

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

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

— ISO 9899:1999(E), C99 मानक, खंड 6.7.4

यह भी देखें

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

संदर्भ

• 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 GNU Compiler Collection (GCC)
• Summary of "inline" semantics in C and C++, by LLVM contributor David Chisnall