इनलाइन फ़ंक्शन का उपयोग कब करें और इसका उपयोग कब न करें?

Question

मुझे पता है कि इनलाइन एक संकेत या संकलक के लिए अनुरोध है और इसका उपयोग फ़ंक्शन कॉल ओवरहेड से बचने के लिए किया जाता है।

तो किस आधार पर यह निर्धारित किया जा सकता है कि एक फ़ंक्शन इनलाइनिंग के लिए एक उम्मीदवार है या नहीं? किस मामले में व्यक्ति को इनलाइनिंग से बचना चाहिए?

Comments

inlineC ++ नवागंतुक के CFLAGSलिए है कि जेंटू नवागंतुक के लिए क्या कर रहे हैं: नहीं, के साथ संकलित -O3 -funroll-loops -finline-functionsकरने से आपका पेंटियम मक्खी नहीं होगा;)

— ग्रेगरी पकोस

इनलाइन का उपयोग नहीं करने का एक कारण यह है कि कुछ डीबगर्स आपको एक विराम समारोह में ब्रेक पॉइंट या स्टेप सेट करने की अनुमति नहीं देंगे।

— Rob deFriesse

डुप्लिकेट: stackoverflow.com/questions/1875947/…

— स्टीव जेसोप

आपको यह निर्धारित नहीं करना चाहिए कि कोई फ़ंक्शन इनलाइन होना चाहिए या नहीं। संकलक इसे करते हैं; आप की तुलना में यह बेहतर है (और प्रत्येक कॉल के वातावरण के आधार पर चुनिंदा तरीके से इनलाइन कार्य कर सकते हैं)।

— डेविड थॉर्नले

@DavidThornley कभी-कभी, O3 ध्वज सेट के साथ भी, कंपाइलर फ़ंक्शन को इनलाइन नहीं करता है यदि परिभाषा cpp फ़ाइल में है। इसलिए, जो अंगूठे का नियम मैं पालन करता हूं, वह एक लाइनर को इनलाइन करता है और वह भी बिना किसी लूप के।

— कहानीकेडोबोबा

Answer 1

एक फ़ंक्शन कॉल की लागत से बचना केवल आधी कहानी है।

करना:

• के inlineबजाय का उपयोग करें#define
• बहुत छोटे कार्य इसके लिए अच्छे उम्मीदवार हैं inline: तेज कोड और छोटे निष्पादन (कोड कैश में रहने की अधिक संभावना)
• फ़ंक्शन छोटा है और बहुत बार कहा जाता है

नहीं है:

• बड़े कार्य: बड़े निष्पादनों की ओर अग्रसर होते हैं, जो कॉलिंग ओवरहेड से होने वाले तेज निष्पादन की परवाह किए बिना प्रदर्शन को महत्वपूर्ण रूप से प्रभावित करते हैं
• इनलाइन फ़ंक्शंस जो I / O बाउंड हैं
• फ़ंक्शन का उपयोग शायद ही कभी किया जाता है
• कंस्ट्रक्टर और डिस्ट्रक्टर्स: खाली होने पर भी कंपाइलर उनके लिए कोड जनरेट करता है
• लाइब्रेरी विकसित करते समय द्विआधारी संगतता को तोड़ना:
  • किसी मौजूदा फ़ंक्शन को इनलाइन करें
  • इनलाइन फ़ंक्शन को बदलें या इनलाइन फ़ंक्शन को नॉन-इनलाइन बनाएं: लाइब्रेरी का पूर्व संस्करण पुराने कार्यान्वयन को कॉल करता है

एक पुस्तकालय विकसित करते समय, भविष्य में एक वर्ग को एक्स्टेंसिबल बनाने के लिए:

• गैर-इनलाइन वर्चुअल विध्वंसक जोड़ें भले ही शरीर खाली हो
• सभी बिल्डरों को इनलाइन न करें
• जब तक क्लास को मान से कॉपी नहीं किया जा सकता तब तक कॉपी कंस्ट्रक्टर और असाइनमेंट ऑपरेटर के गैर-इनलाइन कार्यान्वयन लिखें

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

प्रदर्शन के बारे में, समझदार दृष्टिकोण (हमेशा की तरह) आवेदन को प्रोफाइल करना है, फिर अंततः inlineएक टोंटी का प्रतिनिधित्व करने वाले कार्यों का एक सेट है।

संदर्भ:

• इनलाइन या इनलाइन करने के लिए नहीं
• [९] इनलाइन कार्य
• सी ++ के साथ नीतियां / द्विआधारी संगतता मुद्दे
• गॉट # 33: इनलाइन
• इनलाइन Redux
• प्रभावी सी ++ - आइटम 33: विवेकपूर्ण तरीके से इनलाइनिंग का उपयोग करें

---

संपादित करें: ब्रेज़न स्ट्रॉस्ट्रुप, सी ++ प्रोग्रामिंग भाषा:

एक फ़ंक्शन को परिभाषित किया जा सकता है inline। उदाहरण के लिए:

inline int fac(int n)
{
  return (n < 2) ? 1 : n * fac(n-1);
}

inlineविनिर्देशक संकलक करने के लिए एक संकेत है कि इसके बारे में एक कॉल के लिए कोड उत्पन्न करने का प्रयास करना चाहिए fac()एक बार समारोह के लिए कोड नीचे बिछाने और फिर हमेशा की तरह समारोह कॉल तंत्र के माध्यम से बुला से इनलाइन बल्कि। एक चतुर संकलक 720एक कॉल के लिए निरंतर उत्पन्न कर सकता है fac(6)। पारस्परिक रूप से पुनरावर्ती इनलाइन फ़ंक्शंस, इनलाइन फ़ंक्शंस की संभावना जो इनपुट आदि के आधार पर पुनरावृत्ति या नहीं करती है, यह गारंटी देना असंभव बनाता है कि किसी inlineफ़ंक्शन का प्रत्येक कॉल वास्तव में इनलाइन है। एक संकलक की चतुराई की डिग्री को निर्धारित नहीं किया जा सकता है, इसलिए एक संकलक एक 720और उत्पन्न कर सकता है , और 6 * fac(5)दूसरा एक अन-इनलाइन कॉलfac(6) ।

असामान्य रूप से चतुर संकलन और लिंकिंग सुविधाओं की अनुपस्थिति में इनलाइनिंग को संभव बनाने के लिए, परिभाषा और न केवल एक इनलाइन फ़ंक्शन का घोषणा-पत्र गुंजाइश में होना चाहिए (.29.2)। एक inlineespecifier किसी फ़ंक्शन के शब्दार्थ को प्रभावित नहीं करता है। विशेष रूप से, एक इनलाइन फ़ंक्शन का अभी भी एक अनूठा पता है और इसलिए staticइनलाइन फ़ंक्शन के चर (.27.1.2) हैं।

EDIT2: ISO-IEC 14882-1998, 7.1.2 फ़ंक्शन विनिर्देशक

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

Comments

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

— सीबी बेली

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

— ग्रेगरी पकोस्ज़

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

— जलफ

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

— ग्रेगरी पकोस्ज़

@GregoryPakosz: लेकिन inlineफ़ंक्शन इनलाइनिंग प्राप्त करने के लिए हम सभी उपयोग नहीं करते हैं । कभी-कभी हम अन्य लाभ चाहते हैं, जैसे ओडीआर के आसपास मिलना।

— ऑर्बिट में लाइटनेस दौड़

Answer 2

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

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

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

Comments

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

— रेहो लिंडके

+1। @ रेहन: मुझे यकीन नहीं है कि आप क्या कह रहे हैं। लिंकेज का inlineकीवर्ड से क्या संबंध है ? और एक खुश संयोग क्या है?

— jalf

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

— रेहो लिंडके

सुनिश्चित नहीं हैं कि आपकी टिप्पणी को इतने वोट क्यों मिले, क्योंकि प्रदर्शन इनलाइन का उपयोग करने का प्रमुख कारण है।

— Gast128

Answer 3

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

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

आप आश्चर्यचकित हो सकते हैं, हालांकि - कई सी ++ संकलक स्वचालित रूप से आपके लिए छोटे कार्यों को इनलाइन करेंगे - और वे इनलाइन के आपके अनुरोध को भी अनदेखा कर सकते हैं।

Comments

वास्तव में, मुझे इस बात पर संदेह है कि कुछ कंपाइलर 'इनलाइन' को पूरी तरह से अनदेखा करते हैं और केवल '__inline' या '__force_inline' का जवाब देते हैं। मुझे लगता है कि यह दुरुपयोग को रोकना है!

— रेहो लिंडके

आमतौर पर ऐसा नहीं है। इनलाइन केवल एक संकेत है, लेकिन यह संकेत है कि अधिकांश संकलक गंभीरता से लेते हैं। आप विधानसभा कोड को ऑब्जेक्ट कोड ( /FAcsविजुअल स्टूडियो, -sजीसीसी में) के साथ फेंकने के लिए कंपाइलर सेट कर सकते हैं यह देखने के लिए कि यह क्या करता है। मेरे अनुभव में, वे दोनों कंपाइलर इनलाइन कीवर्ड को काफी भारी रखते हैं।

— क्रैशवर्क

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

— पावेल मिनेव

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

— jalf

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

— dmazzoni

Answer 4

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

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

Answer 5

सभी बुराईयो की जड़ समयपूर्व इष्टतमीकरण है!

अंगूठे के एक नियम के रूप में मैं आमतौर पर केवल "गेटर्स" और "सेटलर्स" को इनलाइन करता हूं। एक बार कोड काम कर रहा है और स्थिर है, प्रोफाइलिंग दिखा सकता है कि कौन से कार्य इनलाइनिंग से लाभान्वित हो सकते हैं।

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

Reasuming - इनलाइन वन-लाइनर फ़ंक्शन लिखें, और बाद में दूसरों के बारे में चिंता करें।

Answer 6

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

आप c ++ faq में inlines के बारे में अधिक पढ़ सकते हैं

Answer 7

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

void IncreaseCount() { freeInstancesCnt++; }

पाठक तुरंत कोड का पूरा शब्दार्थ जानता है।

Answer 8

मैं आम तौर पर एक अंगूठे नियम का पालन करता हूं जहां मैं इनलाइन के रूप में 3-4 सरल बयानों के साथ एक फ़ंक्शन करता हूं। लेकिन यह याद रखना अच्छा है कि यह केवल संकलक के लिए एक संकेत है। इसे इनलाइन बनाने या न करने के लिए अंतिम कॉल केवल कंपाइलर द्वारा लिया जाता है। यदि इन कई कथनों से अधिक है तो मैं इनलाइन घोषित नहीं करूंगा क्योंकि यह एक बेवकूफ संकलक के साथ कोड ब्लोट को जन्म दे सकता है।

Answer 9

सबसे अच्छा तरीका होगा कि इनलेट और इनलाइन के लिए उत्पन्न निर्देशों की जांच करना और तुलना करना। हालांकि, यह हमेशा के लिए सुरक्षित है inline। इस्तेमाल inlineकरने से आपको परेशानी नहीं हो सकती है।

Answer 10

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

इसलिए, आपको अपने लिए निर्णय लेना होगा: क्या उत्पन्न मशीन कोड के आकार में वृद्धि या कमी होती है? यह कैसे संभव है कि फ़ंक्शन को कॉल करने से कैश मिस हो जाएगा? अगर इसे पूरे कोड में डाला जाता है, तो मैं कहूंगा कि संभावना अधिक है। यदि यह एकल तंग लूप तक सीमित है तो संभावना कम है।

मैं आमतौर पर उन मामलों में इनलाइनिंग का उपयोग करता हूं, जो मैं सूचीबद्ध करता हूं। हालांकि, जहां आप वास्तव में प्रदर्शन के बारे में चिंतित हैं, प्रोफाइलिंग आवश्यक है। इसके अलावा, आप जाँच सकते हैं कि संकलक वास्तव में संकेत लेता है या नहीं।

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

Answer 11

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

जब किसी inlineविधि को स्रोत फ़ाइल में स्थानांतरित किया जाता है और किसी भी अधिक इनबिल्ट नहीं किया जाता है, तो पूरी परियोजना को फिर से बनाया जाना चाहिए (कम से कम यह मेरा अनुभव रहा है)। और यह भी जब तरीकों को इनलाइन में परिवर्तित किया जाता है।

Comments

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

— jalf

हालाँकि, एक इनलाइन विधि को बदलने से अत्यधिक बिल्ड बनाम बनाम गैर-इनलाइन विधि को shource फ़ाइल में बदलना होगा।

— थॉमस मैथ्यूज

Answer 12

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

Answer 13

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

Answer 14

मैंने कुछ उत्तर पढ़े हैं और देखा कि कुछ सामान गायब है।

मैं जिस नियम का उपयोग करता हूं, वह इनलाइन का उपयोग नहीं करना है, जब तक कि मैं नहीं चाहता कि यह इनलाइन हो। मूर्खतापूर्ण लगता है, अब स्पष्टीकरण।

कंपाइलर काफी स्मार्ट होते हैं और छोटे कार्य हमेशा इनलाइन बनाते हैं। और कभी भी इनलाइन के रूप में लंबे समय तक कार्य नहीं करता है, जब तक कि प्रोग्रामर ने ऐसा करने के लिए नहीं कहा है।

मुझे पता है कि इनलाइन एक संकेत या संकलक के लिए अनुरोध है

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

तो कब इस्तेमाल करें inline?

यदि आप कुछ कोड इनलाइन करना चाहते हैं तो इसका उपयोग करने के लिए। मैं केवल एक उदाहरण जानता हूं, क्योंकि मैं केवल एक ही स्थिति में इसका उपयोग करता हूं। यह उपयोगकर्ता प्रमाणीकरण है।

उदाहरण के लिए मेरे पास यह फ़ंक्शन है:

inline bool ValidUser(const std::string& username, const std::string& password)
{
    //here it is quite long function
}

कोई फर्क नहीं पड़ता कि यह फ़ंक्शन कितना बड़ा है, मैं इसे इनलाइन के रूप में रखना चाहता हूं क्योंकि यह मेरे सॉफ़्टवेयर को क्रैक करना कठिन बनाता है।

Comments

इनलाइन अभी भी एक संकेत है। कंपाइलर इनलाइन को विफल कर सकता है यदि वह यह मानता है कि आपका फ़ंक्शन बहुत फूला हुआ है।

— इत्तेफाक

एक कहता है कि इनलाइन एक आदेश है ... दूसरा कहता है कि इसका संकेत क्या कोई उसके कथन को प्रमाणित करेगा ताकि हम यह निर्धारित कर सकें कि कौन सा सत्य है?

@ user2918461 मैं इनलाइन स्टेटमेंट का समर्थन करता हूं सिर्फ एक संकेत है। यह कई वेबसाइटों और पुस्तकों द्वारा समर्थित किया गया है

— वारहेड