rvaluness को हटाएं, lvalue संदर्भ रखें (मानक प्रकार विशेषता उपलब्ध है?)

Question

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

मूल्य प्रकार, lvalue संदर्भ और const lvalue संदर्भ बनाए रखा जाना चाहिए। अस्थायी संदर्भ (अस्थायी संदर्भ) से बचने के लिए अस्थायी (rvalue संदर्भ), मूल्य परिवर्तित करने के लिए "रूपांतरित" होना चाहिए।

वांछित परिणामों का उदाहरण:

int lr = 5; 
const int& clr = lr; 

auto t = make_subpack_tuple(lr, clr, 5); 

static_assert(is_same 
< 
    decltype(t), 
    std::tuple<int&, const int&, int> 
>{}, ""); 

// Ok, modifies lr: 
std::get<0>(t) = 10; 

// Compile-time error, intended: 
// std::get<1>(t) = 20; 

// Ok, 5 was moved into the tuple: 
std::get<2>(t) = 30; 

उदाहरण अधूरा कार्यान्वयन:

template<typename... Ts> 
auto make_subpack_tuple(Ts&&... xs) 
{ 
    return std::tuple 
    < 
     some_type_trait<decltype(xs)>... 
    > 
    (
     std::forward<decltype(xs)>(xs)... 
    ); 
} 

कि मैं क्या मतलब है करने के लिए कोशिश कर रहा हूँ करता है?

क्या कोई मानक प्रकार-विशेषता है जिसका उपयोग some_type_trait के स्थान पर किया जा सकता है? या मुझे अपने स्वयं के समाधान को लागू करना चाहिए?

Answer 1

आप के लिए समाधान हो जाएगा

template<typename... Ts> 
auto make_subpack_tuple(Ts&&... xs) 
{ 
    return std::tuple<Ts...>(std::forward<Ts>(xs)...); 
} 

template argument deduction rules के अनुसार, पैरामीटर पैक Ts... केवल सीवी योग्य प्रकार और lvalues ​​शामिल होंगे। this question में जानकारी भी उपयोगी हो सकती है।

Answer 2

मैं इस बात में झुकना चाहता हूं कि मैं Nick Athanasios's foldable Op<operation> के एक कुशल संस्करण को कार्यान्वित करते हुए, वास्तव में एक समस्या में भाग गया ("मुझे लगता है कि मुझे रैल्यू संदर्भों को क्षीण करने और लैव्यू संदर्भों को छूटा जाना चाहिए")। (कि सत्यापित करने के लिए एक बिट के लिए puzzling, और फिर एक ऐसा सवाल पूछने के लिए शुरू करने, और इस मौजूदा प्रश्न/उत्तर खोजने और mystery_trait_t की मेरी कार्यान्वयन के लिए एक static_assert जोड़ने के बाद

template<class Pack, class Op> 
struct Foldable 
{ 
    mystery_trait_t<Pack> value; 
    const Op& op; 

    template<class RhsPack> 
    auto operator*(const Foldable<RhsPack, Op>& rhs) const { 
     return op(static_cast<std::decay_t<Pack>>(
      (op.f)(std::move(value), std::move(rhs.value)) 
     )); 
    } 

    operator mystery_trait_t<Pack>() && { 
     return std::move(value); 
    } 
}; 

template<class Pack> 
auto NamedOperator::operator()(Pack&& value) const { 
    return Foldable<Pack, NamedOperator>(std::forward<Pack>(value), *this); 
} 

और: मैं इस गड़बड़ था यह वास्तव में एक rvalue संदर्भ प्रकार के साथ लागू नहीं किया गया था!) ​​यह है कि सभी मैं वास्तव में जरूरत निकला

template<class Pack, class Op> 
struct Foldable 
{ 
    Pack value; 
    const Op& op; 

    template<class RhsPack> 
    auto operator*(const Foldable<RhsPack, Op>& rhs) const { 
     return op(
      (op.f)(std::move(value), std::move(rhs.value)) 
     ); 
    } 

    operator Pack() && { 
     return std::move(value); 
    } 
}; 

(See my whole code on Wandbox.)

यह मेरा "जवाब" कोई नई जानकारी योगदान नहीं करता था, लेकिन मैंने सोचा था कि यह साझा करने के लिए उपयोगी होगा, क्योंकि यह सिर्फ यह दिखाने के लिए चला जाता है कि भले ही आपको लगता है कि आप टेम्पलेट मेटाप्रोग्रामिंग में गहरे हैं और सुनिश्चित हैं आपको इस "सशर्त क्षय" व्यवहार की आवश्यकता है ... आपको वास्तव में इसकी आवश्यकता नहीं है !

एक कोरोलरी सामान्य नियम हो सकता है कि लेखन any_template<T&&> हमेशा एक कोड गंध है। विटोरियो के मूल प्रश्न में उन्होंने प्रभावी ढंग से कि दो बार, किया था, हालांकि दोनों बार यह decltype वाक्य रचना से छिपा हुआ था:

some_type_trait<decltype(xs)>... // should have been `Ts...` 
std::forward<decltype(xs)>(xs)... // could equally well be `std::forward<Ts>(xs)...`