रैवल्यू संदर्भ: क्यों राजस्व स्पष्ट रूप से स्थानांतरित नहीं होते हैं?

Question

सी ++ रावल्यू संदर्भ (http://www.artima.com/cppsource/rvalue.html) के बारे में आर्टिमा लेख पर शब्द हैं: यही कारण है कि बेस क्लास में जाने पर केवल x की बजाय चाल (x) कहना आवश्यक है। यह कुछ नामित चर से दो बार गलती से चलने से रोकने के लिए डिज़ाइन की गई सैमसंगिक्स की एक प्रमुख सुरक्षा सुविधा है।

मैं ऐसी स्थिति को नहीं सोच सकता जब ऐसा डबल चाल प्रदर्शन कर सकता है। क्या आप इसका उदाहरण दे सकते हैं? दूसरे शब्दों में, यदि T&& के सभी सदस्य रैवलू संदर्भ होंगे और न केवल संदर्भ होंगे तो क्या गलत होगा?

Answer 1

इस परिदृश्य पर विचार करें:

void foo(std::string x) {} 
void bar(std::string y) {} 

void test(std::string&& str) 
{ 
    // to be determined 
} 

हम एक ही मूल्य के साथ str साथ foo, तो str साथ bar, दोनों कॉल करना चाहते हैं। यह करने के लिए सबसे अच्छा तरीका है: क्योंकि पहला कदम str का मूल्य अनिर्दिष्ट है के बाद

foo(std::move(str)); // move str to x 
bar(std::move(str)); // move str to y...er, except now it's empty 

:

foo(str); // copy str to x 
bar(std::move(str)); // move str to y; we move it because we're done with it 

यह यह करने के लिए एक गलती होगी।

तो रावल संदर्भों के डिजाइन में, यह निहित कदम वहां नहीं है। यदि यह था, तो हमारा सबसे अच्छा तरीका काम नहीं करेगा क्योंकि str का पहला उल्लेख इसके बजाय std::move(str) होगा।

Answer 2

तरह से मैं इसे देख यह है कि अगर हम कुछ rvalue संदर्भ एक्स था:

T&& x = ...; 

और हम एक पैरामीटर के रूप में एक्स का उपयोग कर कुछ काम कहा जाता है:

f(x) 

हम किसी न किसी प्रकार की जरूरत च बताने के लिए चाहे वह एक्स को नुकसान पहुंचाए या नहीं (या "एक्स का स्वामित्व लेना" या "एक्स का उपयोग करने वाला अंतिम ग्राहक है")।

एक तरीका यह डिजाइन करने के लिए हर कॉल अर्हता प्राप्त करने के होगा:

f(yours_now(x)) // ok to damage 
f(still_mine(x)) // dont damage 

और अयोग्य कॉल अवैध हैं।

एक और तरीका है एक ही रास्ता डिफ़ॉल्ट बनाने के लिए होगा:

कोई एक:

f(yours_now(x)) // ok to damage 
f(x) // dont damage 

या

f(x) // ok to damage 
f(still_mine(x)) // dont damage 

तो अगर हम हर बार इस्तेमाल करने योग्यता सहमत है भी भारी और हम डिफ़ॉल्ट होना चाहिए एक तरफ, जो सबसे अच्छा है? खैर, दोनों मामलों में गलती से डिफ़ॉल्ट चुनने की लागत को देखते हैं:

पहले मामले में यह नुकसान ठीक था, लेकिन हमने गलती से कहा कि यह नहीं था। इस मामले में हम प्रदर्शन खो देते हैं क्योंकि एक अनावश्यक प्रतिलिपि बनाई गई थी, लेकिन इसके अलावा कोई बड़ा सौदा नहीं था।

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

तो पहला मामला चुना गया था क्योंकि इसका "सुरक्षित" था।