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

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

उदाहरण
एक  function को C या C++ में इस प्रकार लिखा जा सकता है: फिर, एक बयान जैसे कि निम्नलिखित: में अनुवाद किया जा सकता है (यदि संकलक इनलाइनिंग करने का निर्णय लेता है, जिसे सामान्यतः सक्षम करने के लिए अनुकूलन की आवश्यकता होती है): बहुत सारे स्वैप करते हुए सॉर्टिंग एल्गोरिदम लागू करते समय, यह निष्पादन की गति को बढ़ा सकता है।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

जीसीसी कार्यों को इनलाइन नहीं कर सकता है यदि # वे विविध कार्य हैं, एमएसडीएन पर माइक्रोसॉफ्ट विनिर्देशों के आधार पर, एमएस विज़ुअल सी ++ इनलाइन नहीं कर सकता (यहां तक ​​​​कि नहीं ), अगर
 * 1) उपयोग
 * 2) गणना का उपयोग करें
 * 3) नॉनलोकल का उपयोग करें
 * 4) नेस्टेड समारोह का उपयोग करें
 * 5) उपयोग
 * 6) उपयोग
 * 7) उपयोग , या
 * 8) उपयोग


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

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

उद्धरण

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


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


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

यह भी देखें

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

बाहरी संबंध

 * Inline functions with the GNU Compiler Collection (GCC)
 * Summary of "inline" semantics in C and C++, by LLVM contributor David Chisnall