2013-08-30 7 views
7

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

+0

RVO कर सकते हैं/NRVO की जगह * सभी * कॉपी/कदम आपरेशन? मौजूदा कोड को कॉपी/मूव ब्रेक को खत्म कर देगा? अगर कॉपी/चाल को साफ से हटाया नहीं जा सकता है, तो क्यों .. कीड़े। – user2246674

+0

जहां तक ​​मैं समझता हूं, (एन) आरवीओ "* as-if *" नियम के अंतर्गत आता है। मेरा मानना ​​है कि जहां तक ​​मानक का संबंध है, यह समझ में आता है। और, ** नहीं **, यह आपको प्रतिलिपि/चालक रचनाकारों से पूरी तरह से छुटकारा पाने की अनुमति नहीं देगा, क्योंकि इन्हें कई अन्य संदर्भों में उपयोग किया जाता है। मानक द्वारा – syam

+2

आरवीओ/एनआरवीओ *** *** की अनुमति है, इसलिए यह करने के लिए संकलक पर निर्भर है या नहीं। मैं पूछ रहा हूं कि लागू मामलों में *** हमेशा *** क्यों नहीं है। इससे अस्पष्टता कम हो जाएगी जो एक अच्छी बात है। – lizarisk

उत्तर

2

कॉपी इलिजन की वजह से नहीं, क्योंकि वह सभी मामलों में इसे लागू करने के सभी कार्यान्वयन की आवश्यकता होगी है।

वापसी-मूल्य-अनुकूलन बनाम नाम-वापसी-मूल्य-अनुकूलन के मामले को देखें। इस कार्यात्मक रूप से समान कोड में

std::string Func() 
{ 
    return std::string("foo"); 
} 

: बस इस मोड़

std::string Func() 
{ 
    std::string named("foo"); 
    return named; 
} 

बाद एक बहुत पूर्व से संकलक से बाहर अधिक की आवश्यकता है। विभिन्न परिसरों में विभिन्न परिसरों में एनआरवीओ का समर्थन करते हैं। निश्चित रूप से, उनमें से अधिकतर इस मामूली मामले में इसका समर्थन करते हैं, लेकिन वहां विभिन्न मामलों के लॉट हैं। और ऐसे कुछ मामले हैं जहां कंपाइलर्स बस "इसे पेंच" कहते हैं और ऑप्टिमाइज़ेशन पूरी तरह से नहीं करते हैं।

आपका तरीका निम्न में से एक की आवश्यकता होगी:

  1. सभी लागू मामलों में प्रति इलिजन लागू करने के लिए, कोई फर्क नहीं पड़ता compilers के लिए लागू करने के लिए कितना मुश्किल। तो अब हर संकलक लेखक इस तरह के मामलों से निपटने के लिए है:

    std::string Func(bool b) 
    { 
        if(b) 
        { 
        std::string named("foo"); 
        return named; 
        } 
        else 
        { 
        std::string named("bar"); 
        return named; 
        } 
    } 
    

    कई compilers उन मामलों में NRVO संभाल नहीं है। और यह सरल केस है; वे उससे ज्यादा जटिल हो सकते हैं।

  2. हर संकलक के माध्यम से जाओ और उन मामलों में जहां प्रति इलिजन हमेशा प्रयोग किया जाता है की एक आम सबसेट मिल जाए, तो उन्हें आवश्यकताओं के रूप में मानक में निर्दिष्ट करें। यह पूरी तरह से विनोदी है; आप कार्यान्वयन विवरण के आधार पर मानकीकरण करेंगे। यह कभी अच्छी बात नहीं है।

ध्यान दें कि सी ++ 17 को एक विशिष्ट मामले में guarantee of copy elision मिल रहा है। अर्थात्, एक प्रतिलिपि/चाल के लिए किसी भी समय एक अस्थायी का उपयोग उसी प्रकार की वस्तु को प्रारंभ करने के लिए किया जाता है। यह एक समारोह से एक स्थिर वस्तु वापस करने के लिए संभव बनाता है।

+0

ऐसा लगता है कि नामित वापसी मूल्य में कोई अस्पष्टता नहीं होने पर एनआरवीओ करने का एक नियम (यानी लौटा चर स्थिर रूप से निर्धारित किया जा सकता है) पर्याप्त होगा, इसलिए मुझे नहीं लगता कि यह बहुत अधिक कार्यान्वयन विवरण है। और मुझे कोई मामला नहीं दिखता है जब शुद्ध आरवीओ नहीं किया जा सकता है। – lizarisk

+0

"* जब नामित वापसी मूल्य में कोई अस्पष्टता नहीं है *" और एक कंपाइलर के बारे में क्या है जो * ऐसे मामलों में कर सकता है? आपको अभी भी spec में वर्तमान प्रति elision भाषा की आवश्यकता होगी ताकि उन कंपाइलर्स उन मामलों को अनुकूलित कर सकें। किस बिंदु पर, आप कीमती छोटी कमाई की है। आपने कल्पना को और अधिक जटिल बना दिया है जो आपके पास पहले से ही एक अनुकूलन प्राप्त करने के लिए है। किसी भी तरह से आपके कंपाइलर में कुछ भी सुधार नहीं हुआ है। तो ... बात क्या है? –

+0

संकलक एनआरवीओ कैसे कर सकता है जब यह निर्धारित नहीं कर सकता कि कौन सा स्थानीय चर वापस किया जाएगा? मेरे लिए असंभव लगता है, कम से कम जीसीसी 4.8.1 उसमें सक्षम नहीं है, जैसा कि मैंने आपके परीक्षण को चलाने से देखा था। अन्य कंपाइलर क्या कर सकते हैं? – lizarisk

संबंधित मुद्दे

 संबंधित मुद्दे