क्या यह छोरों के लिए C ++ 11 का एक ज्ञात नुकसान है?

Question 1

आइए कल्पना करें कि हमारे पास कुछ सदस्य कार्यों के साथ 3 युगल रखने के लिए एक संरचना है:

struct Vector {
  double x, y, z;
  // ...
  Vector &negate() {
    x = -x; y = -y; z = -z;
    return *this;
  }
  Vector &normalize() {
     double s = 1./sqrt(x*x+y*y+z*z);
     x *= s; y *= s; z *= s;
     return *this;
  }
  // ...
};

यह सादगी के लिए थोड़ा विरोधाभास है, लेकिन मुझे यकीन है कि आप सहमत हैं कि समान कोड वहाँ है। उदाहरण के लिए, विधियाँ आपको आसानी से श्रृंखला की अनुमति देती हैं:

Vector v = ...;
v.normalize().negate();

या और भी:

Vector v = Vector{1., 2., 3.}.normalize().negate();

अब अगर हमने शुरू () और अंत () फ़ंक्शन प्रदान किए हैं, तो हम अपने वेक्टर का उपयोग लूप के लिए एक नई शैली में कर सकते हैं, 3 निर्देशांक x, y और z पर लूप के लिए कह सकते हैं (आप संदेह नहीं कर सकते हैं कि अधिक "उपयोगी" उदाहरणों का निर्माण करें) वेक्टर की जगह जैसे स्ट्रिंग):

Vector v = ...;
for (double x : v) { ... }

हम भी कर सकते हैं:

Vector v = ...;
for (double x : v.normalize().negate()) { ... }

और भी:

for (double x : Vector{1., 2., 3.}) { ... }

हालांकि, निम्नलिखित (यह मुझे लगता है) टूट गया है:

for (double x : Vector{1., 2., 3.}.normalize()) { ... }

हालांकि यह पिछले दो उपयोगों के तार्किक संयोजन की तरह लगता है, मुझे लगता है कि यह अंतिम उपयोग एक झूलने वाला संदर्भ बनाता है जबकि पिछले दो पूरी तरह से ठीक हैं।

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

Question 2

क्या यह सही और व्यापक रूप से सराहा गया है?

हां, आपकी चीजों की समझ सही है।

उपरोक्त में से कौन सा भाग "बुरा" हिस्सा है, जिसे टाला जाना चाहिए?

खराब हिस्सा एक फ़ंक्शन से लौटे अस्थायी पर एल-वैल्यू संदर्भ ले रहा है, और इसे आर-वैल्यू संदर्भ के लिए बाध्य कर रहा है। यह बस के रूप में बुरा है:

auto &&t = Vector{1., 2., 3.}.normalize();

अस्थायी Vector{1., 2., 3.}के जीवनकाल को बढ़ाया नहीं जा सकता क्योंकि संकलक को यह पता नहीं है कि normalizeसंदर्भ से वापसी मूल्य ।

क्या लूप के लिए श्रेणी-आधारित की परिभाषा को बदलकर भाषा में सुधार किया जाएगा, ताकि लूप की अवधि के लिए फॉर-एक्सप्रेशन में निर्मित अस्थायी मौजूद हों?

यह बहुत ही असंगत होगा कि C ++ कैसे काम करता है।

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

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

वर्तमान में (यदि कंपाइलर इसका समर्थन करता है), तो आप इसे बना सकते हैं ताकि अस्थायी पर normalize नहीं बुलाया जा सके:

struct Vector {
  double x, y, z;
  // ...
  Vector &normalize() & {
     double s = 1./sqrt(x*x+y*y+z*z);
     x *= s; y *= s; z *= s;
     return *this;
  }
  Vector &normalize() && = delete;
};

यह Vector{1., 2., 3.}.normalize()एक संकलित त्रुटि देगा, जबकि v.normalize()ठीक काम करेगा। जाहिर है आप इस तरह से सही काम नहीं कर पाएंगे:

Vector t = Vector{1., 2., 3.}.normalize();

लेकिन आप गलत काम भी नहीं कर पाएंगे।

वैकल्पिक रूप से, जैसा कि टिप्पणियों में सुझाया गया है, आप एक संदर्भ के बजाय मूल्य संदर्भ संस्करण लौटा सकते हैं:

struct Vector {
  double x, y, z;
  // ...
  Vector &normalize() & {
     double s = 1./sqrt(x*x+y*y+z*z);
     x *= s; y *= s; z *= s;
     return *this;
  }
  Vector normalize() && {
     Vector ret = *this;
     ret.normalize();
     return ret;
  }
};

यदि Vectorस्थानांतरित करने के लिए वास्तविक संसाधनों के साथ एक प्रकार था, तो आप Vector ret = std::move(*this);इसके बजाय उपयोग कर सकते हैं । नामित रिटर्न वैल्यू ऑप्टिमाइज़ेशन प्रदर्शन के मामले में इसे उचित रूप से इष्टतम बनाता है।

Question 3

(डबल x: वेक्टर {1।, 2., 3।}। सामान्य करें ()) {...}

यह भाषा की सीमा नहीं है, बल्कि आपके कोड की समस्या है। अभिव्यक्ति Vector{1., 2., 3.}एक अस्थायी बनाता है, लेकिन normalizeफ़ंक्शन एक अंतराल-संदर्भ देता है । क्योंकि अभिव्यक्ति एक अंतराल है , संकलक मानता है कि वस्तु जीवित होगी, लेकिन क्योंकि यह एक अस्थायी का संदर्भ है, पूर्ण अभिव्यक्ति का मूल्यांकन होने के बाद वस्तु मर जाती है, इसलिए आपको झूलने वाले संदर्भ के साथ छोड़ दिया जाता है।

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

Question 4

IMHO, दूसरा उदाहरण पहले से ही त्रुटिपूर्ण है। *thisआपके द्वारा बताए गए तरीके से संशोधन करने वाले परिचालक वापसी सुविधाजनक है: यह संशोधक का पीछा करने की अनुमति देता है। इसका उपयोग केवल संशोधन के परिणाम को सौंपने के लिए किया जा सकता है, लेकिन ऐसा करना त्रुटि-प्रवण है क्योंकि इसे आसानी से अनदेखा किया जा सकता है। अगर मुझे कुछ ऐसा दिख रहा है

Vector v{1., 2., 3.};
auto foo = somefunction1(v, 17);
auto bar = somefunction2(true, v, 2, foo);
auto baz = somefunction3(bar.quun(v), 93.2, v.qwarv(foo));

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

auto normalized(Vector v) -> Vector {return v.normalize();}
auto negated(Vector v) -> Vector {return v.negate();}

और फिर छोरों को लिखें

for( double x : negated(normalized(v)) ) { ... }

तथा

for( double x : normalized(Vector{1., 2., 3}) ) { ... }

यह IMO बेहतर पठनीय है, और यह अधिक सुरक्षित है। बेशक, इसके लिए एक अतिरिक्त प्रतिलिपि की आवश्यकता होती है, हालांकि ढेर-आवंटित डेटा के लिए यह संभव हो सकता है एक सस्ते C ++ 11 चालन ऑपरेशन में।