मुझे C ++ 14 स्वचालित वापसी प्रकार कटौती का उपयोग कब करना चाहिए?

Question

जीसीसी 4.8.0 जारी होने के साथ, हमारे पास एक कंपाइलर है जो स्वचालित रिटर्न प्रकार कटौती का समर्थन करता है, सी ++ 14 का हिस्सा है। इसके साथ -std=c++1y, मैं यह कर सकता हूं:

auto foo() { //deduced to be int
    return 5;
}

मेरा प्रश्न है: मुझे इस सुविधा का उपयोग कब करना चाहिए? यह कब आवश्यक है और यह कोड क्लीनर कब बनाता है?

दृष्टांत 1

जब भी संभव हो मैं पहला परिदृश्य सोच सकता हूं। प्रत्येक फ़ंक्शन जिसे इस तरह लिखा जा सकता है, होना चाहिए। इसके साथ समस्या यह है कि यह हमेशा कोड को अधिक पठनीय नहीं बना सकता है।

दृश्य २

अगला परिदृश्य अधिक जटिल रिटर्न प्रकारों से बचने का है। बहुत हल्के उदाहरण के रूप में:

template<typename T, typename U>
auto add(T t, U u) { //almost deduced as decltype(t + u): decltype(auto) would
    return t + u;
}

मुझे विश्वास नहीं है कि यह वास्तव में एक समस्या होगी, हालांकि मुझे लगता है कि रिटर्न प्रकार स्पष्ट रूप से मापदंडों पर निर्भर करता है कुछ मामलों में स्पष्ट हो सकता है।

परिदृश्य 3

अगला, अतिरेक को रोकने के लिए:

auto foo() {
    std::vector<std::map<std::pair<int, double>, int>> ret;
    //fill ret in with stuff
    return ret;
}

C ++ 11 में, हम कभी-कभी return {5, 6, 7};एक वेक्टर के स्थान पर हो सकते हैं , लेकिन यह हमेशा काम नहीं करता है और हमें फ़ंक्शन हेडर और फ़ंक्शन बॉडी दोनों में टाइप निर्दिष्ट करना होगा। यह विशुद्ध रूप से निरर्थक है, और स्वचालित वापसी प्रकार हमें उस अतिरेक से बचाता है।

परिदृश्य 4

अंत में, यह बहुत ही सरल कार्यों के स्थान पर उपयोग किया जा सकता है:

auto position() {
    return pos_;
}

auto area() {
    return length_ * width_;
}

कभी-कभी, हालांकि, हम फ़ंक्शन को देख सकते हैं, सटीक प्रकार जानना चाहते हैं, और यदि यह वहां प्रदान नहीं किया गया है, तो हमें कोड में एक अन्य बिंदु पर जाना होगा, जहां pos_घोषित किया गया है।

निष्कर्ष

उन परिदृश्यों के साथ, उनमें से कौन सा वास्तव में एक ऐसी स्थिति साबित होती है जहां यह सुविधा कोड क्लीनर बनाने में उपयोगी है? उन परिदृश्यों के बारे में जिन्हें मैंने यहाँ उल्लेख करने के लिए उपेक्षित किया है? इस सुविधा का उपयोग करने से पहले मुझे क्या सावधानी बरतनी चाहिए ताकि बाद में यह मुझे काट न सके? क्या कुछ नया है जो इस सुविधा को टेबल पर लाता है जो इसके बिना संभव नहीं है?

_{ध्यान दें कि कई प्रश्नों का अर्थ यह है कि यह उत्तर देने के लिए दृष्टिकोण खोजने में एक सहायता होगी।}

Comments

अद्भुत प्रश्न! जब आप पूछ रहे हैं कि कौन से परिदृश्य कोड को "बेहतर" बनाते हैं, तो मैं यह भी सोच रहा हूं कि कौन से परिदृश्य इसे बदतर बना देंगे ।

— ड्रू डॉर्मन

@DrewDormann, यही मैं भी सोच रहा हूँ। मुझे नई विशेषताओं का उपयोग करना पसंद है, लेकिन यह जानना कि उन्हें कब उपयोग करना है और कब नहीं करना बहुत महत्वपूर्ण है। ऐसी अवधि होती है जब नई सुविधाएँ उत्पन्न होती हैं, जिसे हम यह पता लगाने के लिए लेते हैं, तो चलिए अब इसे करते हैं ताकि हम आधिकारिक तौर पर आने के लिए तैयार हों :)

— chris

@ एनकोलबोल, शायद, लेकिन यह तथ्य कि यह एक संकलक की वास्तविक रिलीज में है अब लोगों के लिए व्यक्तिगत कोड में इसका उपयोग शुरू करने के लिए पर्याप्त होगा (यह निश्चित रूप से इस बिंदु पर परियोजनाओं से दूर रखा जाना है)। मैं उन लोगों में से एक हूं जो अपने कोड में नवीनतम संभव सुविधाओं का उपयोग करना पसंद करते हैं, और जब तक मुझे नहीं पता कि प्रस्ताव समिति के साथ कितनी अच्छी तरह से चल रहा है, मैं इस तथ्य को चित्रित करता हूं कि यह इस नए विकल्प में पहली बार शामिल है कुछ कुछ। बाद में बेहतर हो सकता है, या मुझे नहीं पता कि यह कितना अच्छा होगा।

— क्रिस

@ निचलोलस, अगर यह मदद करता है, तो इसे अब अपनाया गया है: पी

— क्रिस

वर्तमान उत्तरों में ऐसा प्रतीत नहीं होता है कि ->decltype(t+u)ऑटो कटौती के साथ प्रतिस्थापित SFINAE को मारता है।

— मार्क ग्लिससे

Answer 1

C ++ 11 समान प्रश्न उठाता है: लैम्ब्डा में रिटर्न टाइप डिडक्शन का उपयोग कब करना है, और autoवेरिएबल्स का उपयोग कब करना है।

C और C ++ 03 में प्रश्न का पारंपरिक उत्तर "बयान सीमाओं के पार है जिसे हम प्रकार स्पष्ट करते हैं, अभिव्यक्ति के भीतर वे आमतौर पर निहित होते हैं लेकिन हम उन्हें जातियों के साथ स्पष्ट कर सकते हैं"। C ++ 11 और C ++ 1y प्रकार कटौती उपकरण पेश करते हैं ताकि आप नए स्थानों में टाइप छोड़ सकें।

क्षमा करें, लेकिन आप सामान्य नियम बनाकर इसे हल नहीं करेंगे। आपको किसी विशेष कोड को देखने की आवश्यकता है, और अपने लिए तय करें कि क्या यह सभी प्रकार के प्रकारों को निर्दिष्ट करने के लिए पठनीयता सहायक है या नहीं: क्या आपके कोड के लिए यह कहना बेहतर है, "इस चीज़ का प्रकार X है", या क्या यह बेहतर है यह कहने के लिए आपका कोड, "इस चीज़ का प्रकार कोड के इस हिस्से को समझने के लिए अप्रासंगिक है: संकलक को जानने की आवश्यकता है और हम शायद इसे काम कर सकते हैं लेकिन हमें इसे यहां कहने की आवश्यकता नहीं है"?

चूंकि "पठनीयता" उद्देश्यपूर्ण रूप से परिभाषित नहीं है [*], और इसके अलावा यह पाठक द्वारा भिन्न होता है, आपके पास एक कोड के लेखक / संपादक के रूप में एक जिम्मेदारी है जो किसी शैली गाइड द्वारा पूरी तरह से संतुष्ट नहीं हो सकता है। यहां तक ​​कि एक शैली गाइड मानदंडों को निर्दिष्ट करता है, यहां तक ​​कि विभिन्न लोग अलग-अलग मानदंडों को पसंद करेंगे और "कम पठनीय" होने के लिए अपरिचित कुछ भी खोजने की प्रवृत्ति करेंगे। इसलिए किसी विशेष प्रस्तावित शैली के नियम की पठनीयता को अक्सर अन्य शैली के नियमों के संदर्भ में ही आंका जा सकता है।

आपके सभी परिदृश्य (पहले भी) किसी की कोडिंग शैली के लिए उपयोग पाएंगे। व्यक्तिगत रूप से मुझे दूसरा सबसे सम्मोहक उपयोग मामला लगता है, लेकिन फिर भी मैं यह अनुमान लगाता हूं कि यह आपके दस्तावेज़ीकरण उपकरण पर निर्भर करेगा। यह प्रलेखित देखने के लिए बहुत उपयोगी नहीं है कि फ़ंक्शन प्रकार का रिटर्न टेम्प्लेट है auto, जबकि इसे दस्तावेज के रूप में देखने decltype(t+u)से एक प्रकाशित इंटरफ़ेस बनता है, जिस पर आप (उम्मीद) भरोसा कर सकते हैं।

[*] कभी-कभी कोई व्यक्ति कुछ उद्देश्य माप करने की कोशिश करता है। किसी भी हद तक कभी भी किसी भी सांख्यिकीय रूप से महत्वपूर्ण और आम तौर पर लागू होने वाले परिणामों के साथ, वे पूरी तरह से काम कर रहे प्रोग्रामर द्वारा अनदेखी की जाती हैं, जो कि "पठनीय" है।

Comments

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

— क्रिस

@ क्रिस: जैसा मैं कहता हूं, मुझे लगता है कि यह सब एक ही चीज़ के लिए आता है। क्या आपके कोड के लिए यह कहना बेहतर है, "इस चीज़ का प्रकार X है", या क्या आपके कोड के लिए यह कहना बेहतर है, "इस चीज़ का प्रकार अप्रासंगिक है, संकलक को जानना आवश्यक है और हम शायद इसे काम कर सकते हैं लेकिन हमें यह कहने की आवश्यकता नहीं है "। जब हम लिखते हैं कि 1.0 + 27Uहम उत्तरार्द्ध में जोर दे रहे हैं, जब हम लिखते हैं कि (double)1.0 + (double)27Uहम पूर्व को जोर दे रहे हैं। फ़ंक्शन की सादगी, दोहराव की डिग्री, परहेज decltypeसभी इसमें योगदान दे सकते हैं , लेकिन कोई भी निर्णायक रूप से निर्णायक नहीं होगा।

— स्टीव जेसप

क्या आपके कोड के लिए यह कहना बेहतर है, "इस चीज़ का प्रकार X है", या क्या आपके कोड के लिए यह कहना बेहतर है, "इस चीज़ का प्रकार अप्रासंगिक है, संकलक को जानना आवश्यक है और हम शायद इसे काम कर सकते हैं लेकिन हमें यह कहने की आवश्यकता नहीं है "। - यह वाक्य ठीक उसी तरह से है जैसा मैं देख रहा हूँ। इस सुविधा का उपयोग करने के विकल्प और autoसामान्य रूप में आने पर मैं इसे ध्यान में रखूंगा।

— क्रिस

मैं जोड़ना चाहूंगा कि आईडीई "पठनीयता समस्या" को कम कर सकता है। उदाहरण के लिए विज़ुअल स्टूडियो को लें: यदि आप autoकीवर्ड पर मंडराते हैं , तो यह वास्तविक रिटर्न प्रकार प्रदर्शित करेगा।

— और्री

@andreee: यह सीमा के भीतर सच है। यदि किसी प्रकार के कई उपनाम हैं तो वास्तविक प्रकार को जानना हमेशा उतना उपयोगी नहीं होता जितना कि आप आशा करते हैं। उदाहरण के लिए एक इट्रिऐटर प्रकार हो सकता है int*, लेकिन वास्तव में क्या महत्वपूर्ण है, अगर कुछ भी है, तो इसका कारण यह int*है कि ऐसा इसलिए है क्योंकि यह std::vector<int>::iterator_typeआपके वर्तमान निर्माण विकल्पों के साथ है!

— स्टीव जेसोप

Answer 2

सामान्यतया, फ़ंक्शन को दस्तावेज़ करने के लिए फ़ंक्शन रिटर्न प्रकार बहुत मदद करता है। उपयोगकर्ता को पता चल जाएगा कि क्या अपेक्षित है। हालांकि, एक ऐसा मामला है जहां मुझे लगता है कि अतिरेक से बचने के लिए उस रिटर्न प्रकार को छोड़ना अच्छा हो सकता है। यहाँ एक उदाहरण है:

template<typename F, typename Tuple, int... I>
  auto
  apply_(F&& f, Tuple&& args, int_seq<I...>) ->
  decltype(std::forward<F>(f)(std::get<I>(std::forward<Tuple>(args))...))
  {
    return std::forward<F>(f)(std::get<I>(std::forward<Tuple>(args))...);
  }

template<typename F, typename Tuple,
         typename Indices = make_int_seq<std::tuple_size<Tuple>::value>>
  auto
  apply(F&& f, Tuple&& args) ->
  decltype(apply_(std::forward<F>(f), std::forward<Tuple>(args), Indices()))
  {
    return apply_(std::forward<F>(f), std::forward<Tuple>(args), Indices());
  }

यह उदाहरण आधिकारिक समिति के पेपर N3493 से लिया गया है । फ़ंक्शन applyका उद्देश्य किसी फ़ंक्शन के तत्वों को अग्रेषित std::tupleकरना और परिणाम वापस करना है। int_seqऔर make_int_seqकार्यान्वयन का ही हिस्सा हैं, और शायद ही समझने के लिए यह क्या करता है की कोशिश कर किसी भी उपयोगकर्ता को भ्रमित करेंगे।

जैसा कि आप देख सकते हैं, वापसी प्रकार एक decltypeदिए गए एक्सप्रेशन से अधिक कुछ नहीं है । इसके अलावा, apply_उपयोगकर्ताओं द्वारा देखा जाने का मतलब नहीं है, मैं इसके रिटर्न प्रकार के दस्तावेज की उपयोगिता के बारे में सुनिश्चित नहीं हूं, जब यह कमोबेश एक जैसा हो apply। मुझे लगता है कि, इस विशेष मामले में, रिटर्न प्रकार छोड़ने से फ़ंक्शन अधिक पठनीय हो जाता है। ध्यान दें कि यह बहुत ही वापसी प्रकार वास्तव में गिरा दिया गया है और मानक में decltype(auto)जोड़ने के प्रस्ताव द्वारा प्रतिस्थापित किया गया है apply, N3915 (यह भी ध्यान दें कि मेरा मूल उत्तर इस पेपर से पूर्व निर्धारित है ):

template <typename F, typename Tuple, size_t... I>
decltype(auto) apply_impl(F&& f, Tuple&& t, index_sequence<I...>) {
    return forward<F>(f)(get<I>(forward<Tuple>(t))...);
}

template <typename F, typename Tuple>
decltype(auto) apply(F&& f, Tuple&& t) {
    using Indices = make_index_sequence<tuple_size<decay_t<Tuple>>::value>;
    return apply_impl(forward<F>(f), forward<Tuple>(t), Indices{});
}

हालांकि, अधिकांश समय, उस रिटर्न प्रकार को रखना बेहतर होता है। उस विशेष मामले में, जो मैंने ऊपर वर्णित किया था, वापसी प्रकार बल्कि अपठनीय है और एक संभावित उपयोगकर्ता इसे जानने से कुछ भी हासिल नहीं करेगा। उदाहरणों के साथ एक अच्छा प्रलेखन कहीं अधिक उपयोगी होगा।

---

एक और बात जिसका अभी तक उल्लेख नहीं किया गया है: जबकि अभिव्यक्ति SFINAEdeclype(t+u) का उपयोग करने की अनुमति देता है , (भले ही इस व्यवहार को बदलने का कोई प्रस्ताव हो)। उदाहरण के लिए एक फ़ंक्शन लें जो किसी प्रकार के सदस्य फ़ंक्शन को कॉल करेगा यदि यह मौजूद है या यदि यह मौजूद है तो टाइप के सदस्य फ़ंक्शन को कॉल करें , और मान लें कि एक वर्ग हमेशा सटीक होता है या दोनों एक साथ होते हैं:decltype(auto)foobarfoobarfoobar

struct X
{
    void foo() const { std::cout << "foo\n"; }
};

struct Y
{
    void bar() const { std::cout << "bar\n"; }
};

template<typename C> 
auto foobar(const C& c) -> decltype(c.foo())
{
    return c.foo();
}

template<typename C> 
auto foobar(const C& c) -> decltype(c.bar())
{
    return c.bar();
}

कॉलिंग foobarका एक उदाहरण पर Xप्रदर्शित करेगा foo, जबकि बुला foobarका एक उदाहरण पर Yइच्छा प्रदर्शन bar। यदि आप इसके बजाय (या उसके बिना decltype(auto)) स्वत: रिटर्न प्रकार कटौती का उपयोग करते हैं , तो आपको अभिव्यक्ति SFINAE नहीं मिलेगी और या foobarतो एक उदाहरण पर कॉल करना होगा Xया Yएक संकलन-समय त्रुटि को ट्रिगर करेगा।

Answer 3

यह कभी आवश्यक नहीं है। जैसा कि आपको कब करना चाहिए- आपको इसके बारे में बहुत सारे उत्तर मिलने वाले हैं। मैं तब तक बिलकुल नहीं कहूंगा जब तक कि वास्तव में मानक का एक स्वीकृत हिस्सा और उसी तरह से प्रमुख संकलक के बहुमत द्वारा समर्थित न हो।

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

Comments

मैं इस बात से सहमत हूं कि विभिन्न पृष्ठभूमि वाले लोग इस पर अलग-अलग राय रखेंगे, लेकिन मैं उम्मीद कर रहा हूं कि यह C ++ - ish निष्कर्ष पर आता है। (लगभग) हर मामले में, भाषा सुविधाओं का दुरुपयोग करने के लिए इसे दूसरे में बनाने की कोशिश करना अक्षम्य है, जैसे कि #defineS ++ को VB में बदलने के लिए s का उपयोग करना। भाषा के प्रोग्रामर के आदी होने के अनुसार, आम तौर पर उचित उपयोग और क्या नहीं है, इस पर भाषा की मानसिकता के भीतर सुविधाओं का एक अच्छा सहमति है। एक ही सुविधा कई भाषाओं में मौजूद हो सकती है, लेकिन इसके उपयोग पर प्रत्येक का अपना दिशानिर्देश होता है।

— क्रिस

कुछ विशेषताओं में एक अच्छी सहमति है। कई नहीं मुझे पता है कि बहुत से प्रोग्रामर को लगता है कि अधिकांश बूस्ट कचरा है जिसका उपयोग नहीं किया जाना चाहिए। मैं कुछ ऐसे लोगों को भी जानता हूं जो C ++ की सबसे बड़ी बात समझते हैं। किसी भी मामले में मुझे लगता है कि इस पर कुछ दिलचस्प चर्चाएँ होनी थीं, लेकिन इस साइट पर रचनात्मक विकल्प के रूप में इसका वास्तव में सटीक उदाहरण है।

— गाबे सांचे

नहीं, मैं आपसे पूरी तरह असहमत हूं, और मुझे लगता autoहै कि शुद्ध आशीर्वाद है। यह अतिरेक को दूर करता है। यह केवल कभी-कभी रिटर्न प्रकार दोहराने के लिए एक दर्द है। यदि आप एक लंबोदर लौटना चाहते हैं, तो परिणाम को एक में जमा किए बिना यह असंभव भी हो सकता है std::function, जो कुछ ओवरहेड को उकसा सकता है।

— योंगवेई वू

कम से कम एक स्थिति है जहाँ यह सब है लेकिन पूरी तरह से आवश्यक है। मान लीजिए कि आपको फ़ंक्शन कॉल करने की आवश्यकता है, तो उन्हें वापस करने से पहले परिणामों को लॉग इन करें, और फ़ंक्शंस जरूरी नहीं कि सभी एक ही रिटर्न प्रकार हैं। यदि आप ऐसा लॉगिंग फ़ंक्शन के माध्यम से करते हैं जो फ़ंक्शंस और उनके तर्कों को पैरामीटर के रूप में लेता है, तो आपको लॉगिंग फ़ंक्शन के रिटर्न प्रकार को घोषित करने की आवश्यकता होगी autoताकि यह हमेशा पारित फ़ंक्शन के रिटर्न प्रकार से मेल खाता हो।

— जस्टिन टाइम -

[ऐसा करने के लिए तकनीकी रूप से एक और तरीका है, लेकिन यह मूल रूप से सटीक एक ही काम करने के लिए टेम्प्लेट जादू का उपयोग करता है, और अभी भी autoरिटर्न प्रकार के अनुगामी के लिए लॉगिंग फ़ंक्शन की आवश्यकता है ।]

— जस्टिन टाइम -

Answer 4

यह फ़ंक्शन की सरलता ( माना जाता है कि इस प्रश्न के अब-हटाए गए डुप्लिकेट के रूप में) से कोई लेना-देना नहीं है।

या तो वापसी प्रकार तय हो गया है (उपयोग न करें auto), या टेम्पलेट पैरामीटर पर एक जटिल तरीके से निर्भर है ( autoज्यादातर मामलों में उपयोग , decltypeजब कई वापसी बिंदु होते हैं)।

Answer 5

वास्तविक उत्पादन वातावरण पर विचार करें: कई प्रकार के कार्य और इकाई परीक्षण सभी प्रकार के अन्योन्याश्रित रिटर्न प्रकार पर निर्भर करते हैं foo()। अब मान लीजिए कि रिटर्न प्रकार को जो भी कारण से बदलना होगा।

यदि रिटर्न का प्रकार autoहर जगह है, और कॉल करने वाले foo()और संबंधित फ़ंक्शन autoरिटर्न वैल्यू प्राप्त करते समय उपयोग करते हैं, तो जो परिवर्तन किए जाने की आवश्यकता है, वे न्यूनतम हैं। यदि नहीं, तो इसका मतलब हो सकता है कि बहुत थकाऊ और त्रुटि वाले काम के घंटे।

एक वास्तविक दुनिया के उदाहरण के रूप में, मुझे हर जगह कच्चे पॉइंटर्स का उपयोग करने से स्मार्ट पॉइंटर्स तक एक मॉड्यूल को बदलने के लिए कहा गया था। इकाई परीक्षणों को ठीक करना वास्तविक कोड की तुलना में अधिक दर्दनाक था।

हालांकि ऐसे अन्य तरीके हैं जिन्हें संभाला जा सकता है, autoवापसी प्रकार का उपयोग एक अच्छा फिट की तरह लगता है।

Comments

उन मामलों पर, क्या यह लिखना बेहतर नहीं होगा decltype(foo())?

— ओरेन एस

व्यक्तिगत रूप से, मुझे लगता है कि इन मामलों में, विशेष रूप से तब जब वे वर्ग-स्कोप किए गए हों, typedefउर्फ घोषणाएं (यानी usingप्रकार की घोषणा) बेहतर हैं।

— मेकित्गार

Answer 6

मैं एक उदाहरण प्रदान करना चाहता हूं, जहां वापसी प्रकार ऑटो एकदम सही है:

कल्पना करें कि आप लंबे समय तक फ़ंक्शन कॉल के लिए एक छोटा उपनाम बनाना चाहते हैं। ऑटो के साथ आपको मूल रिटर्न प्रकार की देखभाल करने की आवश्यकता नहीं है (शायद यह भविष्य में बदल जाएगा) और उपयोगकर्ता वास्तविक रिटर्न प्रकार प्राप्त करने के लिए मूल फ़ंक्शन पर क्लिक कर सकता है:

inline auto CreateEntity() { return GetContext()->GetEntityManager()->CreateEntity(); }

पुनश्च: इस सवाल पर निर्भर करता है ।

Answer 7

परिदृश्य 3 के लिए मैं चारों ओर लौटाए जाने वाले स्थानीय चर के साथ वापसी प्रकार के फ़ंक्शन हस्ताक्षर को चालू करूंगा। यह क्लाइंट प्रोग्रामर्स के लिए फंक्शन रिटर्न से नफरत करता है। ऐशे ही:

परिदृश्य 3 अतिरेक को रोकने के लिए:

std::vector<std::map<std::pair<int, double>, int>> foo() {
    decltype(foo()) ret;
    return ret;
}

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

Comments

इसके लिए IMO का बेहतर समाधान यह है कि जो भी इरादा किया जाए, उसकी अवधारणा के लिए एक डोमेन-विशिष्ट नाम प्रदान किया जाए vector<map<pair<int,double>,int>और फिर उसका उपयोग किया जाए।

— दाविदबक