क्यों std :: function :: argument_type को बहिष्कृत किया गया है?

Question

मैंने cppreference पर देखा है कि std::function::argument_type को C++ 17 में बहिष्कृत किया गया था। इसके पीछे क्या कारण है? और आईएसओ डब्लूजी 21 पेपर क्या प्रस्तावित कर रहा था?

Answer 1

प्रासंगिक कागजात P0005R4 कर रहे हैं और P0090R0 (जो P0005R4 द्वारा संदर्भित है) (जो कागज कि मसौदा मानक में मतदान किया था) है। P0090R0 से

उद्धरण:

Q2। परिणाम_ प्रकार, आदि के साथ क्या गलत है?

ए 2। ये सी ++ 98/03/TR1-era typedefs ने decltype और सही अग्रेषण की भविष्यवाणी की। पहले, जेनेरिक कोड को फ़ंक्शन ऑब्जेक्ट्स से उन्हें अनुकूलित करने से पहले जानकारी का अनुरोध करना था। अब, मैन्युअल रूप से संचार कर रहा है कि जानकारी अनावश्यक है। decltype supsedes results_type, क्योंकि संकलक बस रिपोर्ट कर सकता है कि विशिष्ट तर्कों के साथ फ़ंक्शन ऑब्जेक्ट को कॉल करने का नतीजा क्या होगा। और सही अग्रेषण तर्क_ प्रकार परिवार को सुपरसिस करता है, क्योंकि एडेप्टर आसानी से मनमाने ढंग से तर्क ले/स्टोर/अग्रेषित कर सकते हैं।

वास्तव में, ये टाइपिफ बेकार से भी बदतर हैं। वे प्रतिकूल उत्पादक हैं, क्योंकि कई कॉल करने योग्य वस्तुओं में उनकी कमी है। फंक्शन सदस्यों के लिए पॉइंटर्स और पॉइंटर्स हमेशा उनकी कमी नहीं करते हैं। ptr_fun(), जो इन टाइपपीफ के साथ फ़ंक्शन पॉइंटर्स को लपेटता है, हाल ही में हटा दिया गया था (देखें [1] फिर से)। सबसे महत्वपूर्ण बात यह है कि लैम्ब्डा में हमेशा इन टाइपिफ्स की कमी होती है, और वे सभी की सबसे महत्वपूर्ण कार्य वस्तुएं हैं। जेनेरिक लैम्बडास भी अधिक असंगत हैं।

इसका मतलब क्या है कि एक उपयोगकर्ता typedefs की RESULT_TYPE परिवार का उपयोग कर द्वारा सामान्य कोड लिखने के लिए प्रयास करता है, अपने कोड नहीं किया जाएगा सामान्य है - यह lambdas, सामान्य lambdas, समारोह संकेत, आदि को संभालने के लिए असफल करेंगे

इन टाइपिफ को हटा दिया जाना चाहिए क्योंकि वे सक्रिय रूप से आधुनिक कोड के लिए हानिकारक हो गए हैं।

Answer 2

कारण उन typedefs मौजूद हैं, not1, bind1st और दोस्तों की तरह तो बातें हैं callables उन्हें पारित कर दिया क्वेरी और प्रतिदेय लागू करने का परिणाम के प्रकार को पुनः प्राप्त कर सकता है, इसके तर्क प्रकारों आदि

करने के लिए उनके उपयोग को सुखद बनाने के लिए, unary_function, ptr_fun, mem_fun आदि जैसे बहुत से समर्थन मशीनरी को भी परिभाषित किया गया था। ध्यान दें कि इनमें से सभी केवल एक या दो तर्क लेने वाले कॉलबेल को अपनाने के लिए सीमित हैं, इसलिए वे उस अर्थ में सीमित हैं।

अब जब हम decltype है कि काम करता है, आदि पर तर्कों की मनमाना संख्या अग्रेषित करने के लिए एक प्रतिदेय की वापसी प्रकार, variadic टेम्पलेट्स और सही अग्रेषण अनुमान किया जा सकता है पूर्व सी ++ 11 तंत्र रास्ता भी उपयोग करने के लिए बोझिल कर रहे हैं ।

स्टीफन टी लैववेज ने पहले p0090r0 में सी ++ 17 में इन से छुटकारा पाने का प्रस्ताव दिया था। पेपर से प्रासंगिक अंश:

प्रश्न 1। आप क्या प्रस्तावित कर रहे हैं
* result_type के हर उल्लेख, argument_type, first_argument_type निकाला जा रहा है, और second_argument_type ...
* negators not1() और not2() है, जो इन typedefs द्वारा संचालित थी निकाला जा रहा है।

प्रश्न 2। result_type, आदि के साथ क्या गलत है?
ए 2। ये सी ++ 98/03/TR1-era typedefs ने decltype और पूर्ण अग्रेषण की भविष्यवाणी की। पहले, जेनेरिक कोड को उन्हें अनुकूलित करने से पहले फ़ंक्शन ऑब्जेक्ट्स से जानकारी का अनुरोध करना पड़ता था। अब, उस जानकारी को मैन्युअल रूप से संचार करना अनावश्यक है। decltyperesult_type का अधिग्रहण करता है, क्योंकि संकलक बस रिपोर्ट कर सकता है कि विशिष्ट तर्कों के साथ फ़ंक्शन ऑब्जेक्ट को कॉल करने का नतीजा क्या होगा। और सही अग्रेषण argument_type परिवार को पीछे छोड़ देता है, क्योंकि एडेप्टर आसानी से मनमाने ढंग से तर्क ले सकते हैं/स्टोर/अग्रेषित कर सकते हैं।

आप [func.wrap.func] के लिए कागज खोजते हैं, तो यह std::function typedefs आप के बारे में पूछ रहे हैं हटाने के बारे में विशेष रूप से बात करती है।