C # में इनलाइन फ़ंक्शंस?

276

आप C # में "इनलाइन फ़ंक्शंस" कैसे करते हैं? मुझे नहीं लगता कि मैं इस अवधारणा को समझता हूं। क्या वे गुमनाम तरीकों की तरह हैं? लंबोदर कार्यों की तरह?

नोट : उत्तर लगभग पूरी तरह से इनलाइन फ़ंक्शन की क्षमता से निपटते हैं , अर्थात "एक मैनुअल या कंपाइलर ऑप्टिमाइज़ेशन जो कैली के शरीर के साथ एक फ़ंक्शन कॉल साइट को बदलता है।" यदि आप अनाम (उर्फ लंबोदा) कार्यों में रुचि रखते हैं , तो @ jalf का उत्तर देखें या यह 'लैंबडा' क्या है जिसे हर कोई बोलता रहता है? ।

c# optimization inline

— दीना
स्रोत

11

यह अंततः संभव है - मेरा जवाब देखें।

— konrad.kruczynski 20

1

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

— AppFzx

उत्सुक लोगों के लिए, इस वीएस एक्सटेंशन की जांच करें ।

— ट्रिपलअकेन्टियन

384

अंत में .NET 4.5 में, सीएलआर एक का उपयोग करने का सुझाव देता है / मान का उपयोग करके ¹ विधि को इनलाइन करने का सुझाव देता है MethodImplOptions.AggressiveInlining। यह मोनो के ट्रंक (आज प्रतिबद्ध) में भी उपलब्ध है।

// The full attribute usage is in mscorlib.dll,
// so should not need to include extra references
using System.Runtime.CompilerServices; 

...

[MethodImpl(MethodImplOptions.AggressiveInlining)]
void MyMethod(...)

1 है । पहले "बल" का उपयोग यहां किया गया था। चूंकि कुछ डाउनवोट थे, इसलिए मैं इस शब्द को स्पष्ट करने की कोशिश करूंगा। जैसा कि टिप्पणियों और प्रलेखन में, The method should be inlined if possible.विशेष रूप से मोनो पर विचार करते हुए (जो खुला है), कुछ मोनो-विशिष्ट तकनीकी सीमाएं हैं जो इनलाइनिंग या अधिक सामान्य एक (आभासी कार्यों की तरह) पर विचार कर रही हैं। कुल मिलाकर, हाँ, यह संकलक के लिए एक संकेत है, लेकिन मुझे लगता है कि वही है जो पूछा गया था।

— konrad.kruczynski
स्रोत

17

+1 - फ्रेमवर्क संस्करण आवश्यकताओं के बारे में अधिक विशिष्ट होने के लिए अपना उत्तर अपडेट करें।

— एम। बाबॉक

4

यह शायद अभी भी एक बल इनलाइन नहीं है , लेकिन अधिकांश परिस्थितियों में जेटरस ह्यूरिस्टिक्स को ओवरराइड करना निश्चित रूप से पर्याप्त है।

— कोडइन्चोस

7

एक अलग दृष्टिकोण जो सभी .NET संस्करण के साथ काम कर सकता है, वह यह है कि थोड़ी बहुत बड़ी विधि को दो विधियों में विभाजित किया जाए, एक जो दूसरे को कॉल करता है, जिसमें से कोई भी आईएल के 32 बाइट्स से अधिक नहीं है। शुद्ध प्रभाव ऐसा है मानो मूल अंतर्निर्मित हैं।

— रिक स्लैडकी

4

यह "Inlining" के लिए मजबूर नहीं है, यह सिर्फ JIT के साथ बात करने की कोशिश करता है और यह बताता है कि प्रोग्रामर वास्तव में यहाँ Inlining का उपयोग करना चाहता है, लेकिन JIT के पास इस पर अंतिम शब्द है। इसलिए MSDN: यदि संभव हो तो विधि को इनलाइन किया जाना चाहिए।

— ओरेल इरकी

11

तुलना करके, C ++ के इनलाइन सुझाव, यहां तक कि संकलक-विशिष्ट भी, वास्तव में एक इनलाइन को मजबूर नहीं करते हैं: सभी कार्यों को इनलाइन नहीं किया जा सकता है (पुनरावर्ती कार्यों की तरह मौलिक चीजें कठिन हैं, लेकिन अन्य मामले भी हैं)। तो हाँ, यह "नहीं-काफी" बल विशिष्ट है।

— Eamon Nerbonne

87

इनलाइन विधियां बस एक संकलक अनुकूलन हैं जहां एक फ़ंक्शन का कोड कॉलर में लुढ़का हुआ है।

ऐसा कोई तंत्र नहीं है जिसके द्वारा C # में ऐसा किया जा सके, और उनका उपयोग उन भाषाओं में किया जाए जहाँ उनका समर्थन किया जाता है - यदि आपको नहीं पता कि उनका उपयोग कहीं क्यों किया जाना चाहिए, तो उन्हें नहीं होना चाहिए।

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

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

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

— कोडी ब्रोशर
स्रोत

35

आम तौर पर मुझे लगता है कि यह ठीक है कि कंपाइलर इनलाइनिंग को संभालता है। लेकिन ऐसी परिस्थितियां हैं जहां मुझे संकलक निर्णय को ओवरलाइन करना पसंद है और एक विधि को इनलाइन या इनलाइन नहीं करना है।

— mmmmmmmm

7

@ जोएल कोएहॉर्न: यह बुरा अभ्यास होगा क्योंकि यह संशोधन और पहुंच संरक्षण को तोड़ देगा। (एक कक्षा में एक अंतर्निर्मित विधि के बारे में सोचें जो निजी सदस्यों तक पहुंचती है और कोड में अलग-अलग बिंदुओं से कहलाती है!)

— mmmmmmmm

9

@Poma inlining का उपयोग करने का एक अजीब कारण है। मुझे अत्यधिक संदेह है कि यह प्रभावी साबित होगा।

— क्रिस शौट्स

56

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

— उज्जवल

6

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

56

अद्यतन: प्रति konrad.kruczynski के उत्तर के लिए , निम्न 4.0 और .NET सहित .NET के संस्करणों के लिए सही है।

आप किसी विधि को इनलाइन होने से रोकने के लिए MethodImplAttribute वर्ग का उपयोग कर सकते हैं ...

[MethodImpl(MethodImplOptions.NoInlining)]
void SomeMethod()
{
    // ...
}

... लेकिन इसके विपरीत करने का कोई तरीका नहीं है और इसे मजबूर करने के लिए मजबूर किया जाता है।

— सूअर का मांस
स्रोत

2

यह जानना दिलचस्प है, लेकिन बिल्ली एक विधि को इनबिल्ट होने से क्यों रोकती है? मैंने मॉनीटर में घूरने में कुछ समय बिताया लेकिन मैं एक कारण नहीं बता सकता कि इनलाइनिंग कोई नुकसान क्यों पहुंचा सकती है।

— कैमिलो मार्टिन

3

यदि आप एक कॉल स्टैक (यानी NullReferenceException) प्राप्त करते हैं और स्पष्ट रूप से कोई तरीका नहीं है कि स्टैक के शीर्ष पर विधि ने इसे फेंक दिया है। बेशक, इसकी एक कॉल हो सकती है। पर कौनसा?

— dzendras

19

GetExecutingAssemblyऔर GetCallingAssemblyअलग-अलग परिणाम दे सकता है यह इस बात पर निर्भर करता है कि क्या विधि अंतर्निर्मित है। गैर-इच्छुक होने के लिए एक विधि को मजबूर करना किसी भी अनिश्चितता को समाप्त करता है।

— स्टसमिथ

1

@Downvoter: यदि आपने जो लिखा है, उससे असहमत हैं तो आपको यह बताते हुए टिप्पणी क्यों पोस्ट करनी चाहिए। न केवल यह सामान्य शिष्टाचार है, आप 20+ उत्तर के कुल वोट को डिंग करके भी पूरा नहीं करते हैं।

— बैकोन

2

काश मैं +2 हो पाता क्योंकि आपका नाम अकेले +1: D का हकदार है।

— 13

33

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

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

C # में कोई इनलाइन कीवर्ड नहीं है, क्योंकि यह एक ऑप्टिमाइज़ेशन है जिसे आमतौर पर कंपाइलर, विशेषकर JIT'ed भाषाओं में छोड़ा जा सकता है। JIT कंपाइलर में रनटाइम आँकड़े होते हैं जो यह तय करने में सक्षम बनाता है कि कोड लिखते समय आप इनलाइन से अधिक कुशलता से क्या कर सकते हैं। यदि कंपाइलर तय करता है तो एक फ़ंक्शन इनबिल्ड हो जाएगा, और इसके बारे में आप कुछ भी नहीं कर सकते हैं। :)

— jalf
स्रोत

20

"कोई फ़ंक्शन समान व्यवहार करता है चाहे वह इनबिल्ट हो या नहीं।" कुछ दुर्लभ मामले हैं जहां यह सच नहीं है: अर्थात् लॉगिंग फ़ंक्शन जो स्टैक ट्रेस के बारे में जानना चाहते हैं। लेकिन मैं आपके आधार विवरण को बहुत कम नहीं करना चाहता: यह आम तौर पर सच है।

— जोएल कोएहॉर्न

"और इसके बारे में आप कुछ भी नहीं कर सकते हैं।" - सच नहीं है। यहां तक कि अगर हम कुछ भी करने के रूप में संकलक को "मजबूत सुझाव" नहीं दे रहे हैं, तो आप फ़ंक्शन को इनलाइन होने से रोक सकते हैं।

— बार्टोज़केपी

21

क्या आप सी ++ अर्थ में इनलाइन कार्यों का मतलब है? जिसमें एक सामान्य फ़ंक्शन की सामग्री को स्वचालित रूप से कॉल इनलाइन में कॉपी किया जाता है? अंतिम प्रभाव यह है कि कोई फ़ंक्शन कॉल वास्तव में किसी फ़ंक्शन को कॉल करते समय नहीं होता है।

उदाहरण:

inline int Add(int left, int right) { return left + right; }

यदि हां, तो नहीं, इसके बराबर कोई C # नहीं है।

या क्या आप उन कार्यों से मतलब रखते हैं जो किसी अन्य फ़ंक्शन के भीतर घोषित किए गए हैं? यदि ऐसा है तो हां, C # अनाम विधियों या लंबोदर भावों के माध्यम से इसका समर्थन करता है।

उदाहरण:

static void Example() {
  Func<int,int,int> add = (x,y) => x + y;
  var result = add(4,6);  // 10
}

— JaredPar
स्रोत

21

कोडी में यह सही है, लेकिन मैं एक इनलाइन फ़ंक्शन क्या है, इसका एक उदाहरण प्रदान करना चाहता हूं।

मान लें कि आपके पास यह कोड है:

private void OutputItem(string x)
{
    Console.WriteLine(x);

    //maybe encapsulate additional logic to decide 
    // whether to also write the message to Trace or a log file
}

public IList<string> BuildListAndOutput(IEnumerable<string> x)
{  // let's pretend IEnumerable<T>.ToList() doesn't exist for the moment
    IList<string> result = new List<string>();

    foreach(string y in x)
    {
        result.Add(y);
        OutputItem(y);
    }
    return result;
}

~~संकलक~~ बस-इन-टाइम अनुकूलक बार-बार स्टैक पर OutputItem () करने के लिए कॉल कर देते हैं से बचने के लिए कोड को बदलने के लिए चुन सकते हैं, इतनी के रूप में अगर आप इस तरह के बजाय कोड लिखा था कि यह होगा:

public IList<string> BuildListAndOutput(IEnumerable<string> x)
{
    IList<string> result = new List<string>();

    foreach(string y in x)
    {
        result.Add(y);

        // full OutputItem() implementation is placed here
        Console.WriteLine(y);   
    }

    return result;
}

इस मामले में, हम कहेंगे कि OutputItem () फ़ंक्शन इनबिल्ड था। ध्यान दें कि यदि अन्य स्थानों से भी इसे OutputItem () कहा जाता है तो भी ऐसा हो सकता है।

एक परिदृश्य को दिखाने के लिए संपादित किए जाने की संभावना अधिक है।

— जोएल कोएहॉर्न
स्रोत

9

हालांकि स्पष्ट करने के लिए; यह जेआईएल है जो इनलाइनिंग करता है; सी # कंपाइलर नहीं।

— मार्क ग्रेवल

यह भी ध्यान दें कि, मूल रूप से कम से कम, JIT विधानसभा सीमाओं के पार भी इनलाइन स्टैटिक विधियों को 'पसंद' करेगा। इस प्रकार, अनुकूलन के लिए एक पुरानी स्कूल तकनीक को आपके तरीकों को स्थिर के रूप में चिह्नित करना था। तब से यह समुदाय द्वारा पराजित किया गया है, लेकिन आज तक मैं इनलाइन विधियों का चयन करूंगा जो कि आंतरिक, गैर-बहुरूपी प्रकृति में हैं और आमतौर पर संबंधित स्टैक फिल + स्पिल की तुलना में निष्पादित करने के लिए कम खर्च होता है।

— शॉन विल्सन

7

हां, वास्तव में, एकमात्र अंतर यह तथ्य है कि यह एक मूल्य लौटाता है।

सरलीकरण (अभिव्यक्ति का उपयोग नहीं):

List<T>.ForEach एक कार्रवाई करता है, यह एक वापसी परिणाम की उम्मीद नहीं करता है।

तो एक Action<T>प्रतिनिधि पर्याप्त होगा .. कहते हैं:

List<T>.ForEach(param => Console.WriteLine(param));

कहने के समान है:

List<T>.ForEach(delegate(T param) { Console.WriteLine(param); });

अंतर यह है कि परम प्रकार और प्रतिनिधि घोषणा के उपयोग से अनुमान लगाया जाता है और एक सरल इनलाइन विधि पर ब्रेस की आवश्यकता नहीं होती है।

जहाँ तक

List<T>.Where एक परिणाम लेता है, एक परिणाम की उम्मीद है।

तो एक Function<T, bool>उम्मीद की जाएगी:

List<T>.Where(param => param.Value == SomeExpectedComparison);

जो समान है:

List<T>.Where(delegate(T param) { return param.Value == SomeExpectedComparison; });

आप इन विधियों को इनलाइन भी घोषित कर सकते हैं और उन्हें IE को चर में निर्दिष्ट कर सकते हैं:

Action myAction = () => Console.WriteLine("I'm doing something Nifty!");

myAction();

या

Function<object, string> myFunction = theObject => theObject.ToString();

string myString = myFunction(someObject);

आशा है कि ये आपकी मदद करेगा।

— क्विंटन रॉबिन्सन
स्रोत

2

ऐसे मौके हैं जहां मैं कोड को लाइन में खड़ा होने के लिए मजबूर करना चाहता हूं।

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

मुझे पता है कि उन सहायक कार्यों को लाइन में खड़ा किया जाना चाहिए क्योंकि यह तरीका है कि कोड को लिखा जाएगा यदि इसे कभी भी मानव द्वारा नहीं समझा जाना चाहिए। मैं निश्चित रूप से इस मामले में यह सुनिश्चित करना चाहूंगा कि ओवरहेड कॉलिंग फ़ंक्शन नहीं थे।

— डेवलपर
स्रोत

2

बयान "इन चीजों को अकेले छोड़ने और संकलक को काम करने देने के लिए अपना सर्वश्रेष्ठ।" (कोड़ी ब्रोचेस) पूरी तरह से बकवास है। मैं 20 वर्षों से उच्च प्रदर्शन गेम कोड की प्रोग्रामिंग कर रहा हूं, और मुझे अभी तक एक कंपाइलर पर आना है जो यह जानने के लिए 'स्मार्ट' है कि किस कोड को इनबिल्ड किया जाना चाहिए (फ़ंक्शन) या नहीं। सी # में "इनलाइन" स्टेटमेंट होना उपयोगी होगा, सच तो यह है कि कंपाइलर के पास यह पता लगाने के लिए कि कौन सा फ़ंक्शन हमेशा इनलाइन होना चाहिए या "इनलाइन" संकेत के बिना नहीं होना चाहिए। यकीन है कि यदि फ़ंक्शन छोटा है (एक्सेसर) तो यह स्वचालित रूप से इनलाइन हो सकता है, लेकिन क्या होगा यदि यह कोड की कुछ पंक्तियां हैं? बकवास, संकलक को जानने का कोई तरीका नहीं है, आप केवल उस कोड को अनुकूलित कोड (एल्गोरिदम से परे) के लिए छोड़ सकते हैं।

— gvick2002
स्रोत

3

"बकवास, संकलक को जानने का कोई तरीका नहीं है" जेटर फ़ंक्शन कॉल की रियल टाइम प्रोफाइलिंग करता है ..

— ब्रायन गॉर्डन

3

.NET JIT को संकलन-समय पर 2-पास स्थैतिक विश्लेषण के साथ जितना संभव हो, रन-टाइम को बेहतर बनाने के लिए जाना जाता है। "पुराने स्कूल" कोडर्स को समझने के लिए कठिन हिस्सा यह है कि जेआईटी, संकलक नहीं, देशी कोड पीढ़ी के लिए जिम्मेदार है। JIT, संकलक नहीं, इनलाइन विधियों के लिए जिम्मेदार है।

— शॉन विल्सन

1

मेरे लिए कोड को संकलित करना संभव है, जिसे आप मेरे स्रोत कोड के बिना कॉल करते हैं, और जेआईटी कॉल को इनलाइन कर सकता है। आम तौर पर मैं सहमत होता हूं, लेकिन मैं एक इंसान के रूप में कहूंगा कि आप अब औजारों को पार करने में सक्षम नहीं हैं।

— शॉन विल्सन

1

मुझे पता है कि यह सवाल C # के बारे में है। हालाँकि, आप .NET में F # के साथ इनलाइन फ़ंक्शन लिख सकते हैं। देखें: एफ # में `इनलाइन` का उपयोग

— Goswin
स्रोत

मुझे यहाँ से पुनर्निर्देशित किया गया: stackoverflow.com/questions/13764789/…

— गोसविन

0

नहीं, C # में ऐसा कोई निर्माण नहीं है, लेकिन .NET JIT कंपाइलर JIT समय पर इनलाइन फ़ंक्शन कॉल करने का निर्णय ले सकता है। लेकिन मैं वास्तव में नहीं जानता कि क्या यह वास्तव में इस तरह के अनुकूलन कर रहा है।
(मुझे लगता है कि यह :-))

— mmmmmmmm
स्रोत

0

यदि आपकी असेंबली ngen-ed होगी, तो आप TargetedPatchingOptOut पर एक नज़र रखना चाहते हैं। यह इनलाइन तरीकों को तय करने में मदद करेगा। MSDN संदर्भ

यह अभी भी केवल एक घोषणात्मक संकेत है कि हालांकि, अनुकूलन की आज्ञा नहीं है।

— टिम लवेल-स्मिथ
स्रोत

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

— वू

-7

लैम्ब्डा भाव इनलाइन फ़ंक्शन हैं! मुझे लगता है, कि C # doesn`t में इनलाइन जैसा कोई अतिरिक्त गुण है या ऐसा कुछ है!

— cordellcp3
स्रोत

9

मैंने आपको निराश नहीं किया, लेकिन कृपया प्रश्नों को पढ़ें और सुनिश्चित करें कि आप एक यादृच्छिक उत्तर पोस्ट करने से पहले उन्हें समझ लें। en.wikipedia.org/wiki/Inline_function

— कैमिलो मार्टिन

1

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

— स्टुअर्टएलसी

-7

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

static void Main(string[] args)
{
    int a = 1;

    Action inline = () => a++;
    inline();
    //here a = 2
}

— योरदन पावलोव
स्रोत

10

इनलाइन फ़ंक्शन के साथ क्या करना है? यह बेनामी विधि है।

— तोमर डब्ल्यू