std :: bind और std :: thread हमेशा तर्कों की प्रतिलिपि बनाने के पीछे तर्क क्या है?

Question

यह बहुत अच्छी तरह से ज्ञात है कि std :: bind और std :: thread का डिफ़ॉल्ट व्यवहार यह है कि यह इसके द्वारा पारित तर्कों की प्रतिलिपि (या स्थानांतरित) करेगा, और संदर्भ अर्थशास्त्र का उपयोग करने के लिए हमें संदर्भ रैपर का उपयोग करना होगा।

1. क्या किसी को पता है कि यह एक अच्छा डिफ़ॉल्ट व्यवहार क्यों करता है? Esp। सी ++ 11 में रैवल्यू संदर्भ और सही अग्रेषण के साथ, ऐसा लगता है कि यह तर्कों को पूरी तरह से आगे बढ़ाने के लिए और अधिक समझ में आता है।

2. std :: make_shared हालांकि प्रतिलिपि/स्थानांतरित नहीं होता है लेकिन केवल प्रदान किए गए तर्कों को पूरी तरह से आगे बढ़ाता है। यहां तर्कों को अग्रेषित करने के दो अलग-अलग व्यवहार क्यों हैं? (Std :: धागा और std :: बाँध कि हमेशा कॉपी/स्थानांतरित std :: make_shared कि नहीं बनाम)

Answer 1

make_shared आगे एक कन्स्ट्रक्टर को कहा जा रहा है जिसे कहा जा रहा है। यदि निर्माता संदर्भ अर्थशास्त्र द्वारा कॉल का उपयोग करता है, तो यह संदर्भ प्राप्त करेगा; यदि यह मूल्य से कॉल करता है, तो यह एक प्रतिलिपि बना देगा। यहां कोई समस्या नहीं है।

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

Answer 2

सबसे संभावित कारण बस जो C++ है काफी हर जगह डिफ़ॉल्ट रूप से मूल्य अर्थ विज्ञान का उपयोग करता है। और संदर्भों का उपयोग आसानी से निर्दिष्ट वस्तु के जीवनकाल से संबंधित मुद्दों को बना सकता है।

Answer 3

std :: बाइंड एक कॉल करने योग्य बनाता है जो std::bind की कॉल साइट से अलग है, इस प्रकार यह डिफ़ॉल्ट रूप से सभी तर्कों को मूल्य से कैप्चर करने के लिए बहुत अधिक समझ में आता है।

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

लैम्ब्डा प्रोग्रामर के लिए यह तय करने के लिए अधिक लचीलापन देता है कि लैम्ब्डा दायरे के तर्क से परे रहेंगे या नहीं।

Answer 4

std::bind और std::thread दोनों के लिए, दिए गए तर्कों पर फ़ंक्शन का आमंत्रण कॉल साइट से स्थगित कर दिया गया है। दोनों मामलों में, जब फ़ंक्शन को कॉल किया जाएगा तो बस अज्ञात है।

इस तरह के मामले में सीधे पैरामीटर को आगे बढ़ाने के लिए संदर्भों को संग्रहीत करने की आवश्यकता होगी। जिसका अर्थ हो सकता है स्टैक ऑब्जेक्ट्स के संदर्भों को संग्रहीत करना। कॉल वास्तव में निष्पादित होने पर कौन सा अस्तित्व में नहीं हो सकता है।

ओह।

लैम्बडास ऐसा कर सकता है क्योंकि आपको प्रति-कैप्चर आधार पर निर्णय लेने की क्षमता दी जाती है, चाहे आप संदर्भ या मूल्य से कैप्चर करना चाहते हों। std::ref का उपयोग करके, आप संदर्भ द्वारा पैरामीटर बाध्य कर सकते हैं।

Answer 5

मैंने वास्तव में एक छोटी उपयोगिता लिख ​​दी जो देरी से इनवोकेशन फ़ैक्टर (कुछ हद तक std::bind-जैसा बनाता है, लेकिन नेस्टेड बाइंड एक्सप्रेशन/प्लेसहोल्डर्स फीचर्स के बिना)।मेरा मुख्य प्रेरणा इस मामले कि मैंने पाया था जवाबी सहज ज्ञान युक्त:

using pointer_type = std::unique_ptr<int>; 
pointer_type source(); 
void sink(pointer_type p); 

pointer_type p = source(); 

// Either not valid now or later when calling bound() 
// auto bound = std::bind(sink, std::move(p)); 
auto bound = std::bind(
    [](pointer_type& p) { sink(std::move(p)); } 
    , std::move(p)); 
bound(); 

कि एडाप्टर के लिए कारण (जो sink करने के लिए अपने lvalue रेफरी तर्क चलता है) कि std::bind द्वारा कॉल आवरण वापसी हमेशा lvalues ​​के रूप में बाध्य तर्क अग्रेषित करता है । यह समस्या के साथ कोई समस्या नहीं थी C12+ 03 में boost::bind क्योंकि उस लवली या तो अंतर्निहित कॉल करने योग्य ऑब्जेक्ट के संदर्भ तर्क या प्रतिलिपि के माध्यम से मान तर्क के साथ बाध्य होगा। pointer_type के बाद से यहां काम नहीं करता है केवल स्थानांतरित है। कैसे बाध्य तर्क संग्रहीत होना चाहिए, और वे कैसे बहाल होना चाहिए (अर्थात प्रतिदेय वस्तु को पारित कर दिया):

अंतर्दृष्टि है कि मुझे मिल गया वास्तव में दो बातों पर विचार करने के लिए देखते हैं कि है। नियंत्रण जो std::bind अनुदान देता है, आप निम्नानुसार हैं: तर्क या तो उथले (std::ref के उपयोग के माध्यम से) या नियमित तरीके से (std::decay का उपयोग करके आगे बढ़ते हैं); वे हमेशा लालच के रूप में बहाल होते हैं (सीवी-क्वालीफायर के साथ स्वयं कॉल कॉलर से विरासत में मिला)। सिवाय इसके कि आप बाद वाले को एक छोटे से साइट एडाप्टर लैम्ब्डा अभिव्यक्ति के साथ बाईपास कर सकते हैं जैसा मैंने अभी किया था।

यह तर्कसंगत रूप से बहुत कम नियंत्रण और सीखने के लिए अपेक्षाकृत बहुत अभिव्यक्ति है। तुलनात्मक रूप से मेरी उपयोगिता में bind(f, p) (क्षय और स्टोर प्रति, lvalue के रूप में बहाल), bind(f, ref(p)) (उथले रूप से स्टोर, lvalue के रूप में बहाल), bind(f, std::move(p)) (चाल से क्षय और स्टोर, रैवल्यू के रूप में बहाल), bind(f, emplace(p)) (चाल से क्षय और स्टोर, lvalue के रूप में बहाल)। यह एक ईडीएसएल सीखने की तरह लगता है।