trailing-return-type

问题 What is the advantage of specifying a trailing return type in C++11, as opposed to a normal return type? Look at foo1 vs foo2 here: int foo1() { return 1; } auto foo2() -> int { return 1; } int main() { foo1(); foo2(); } 回答1: In this example, they mean the exact same thing. However, there are a few advantages to using the trailing return type form consistently (Phil Nash calls these "East End Functions", since the return type is on the east end). Using parameters. Obviously when using

问题 What is the advantage of specifying a trailing return type in C++11, as opposed to a normal return type? Look at foo1 vs foo2 here: int foo1() { return 1; } auto foo2() -> int { return 1; } int main() { foo1(); foo2(); } 回答1: In this example, they mean the exact same thing. However, there are a few advantages to using the trailing return type form consistently (Phil Nash calls these "East End Functions", since the return type is on the east end). Using parameters. Obviously when using

问题 I understand that template member functions are only generated if used. This is convenient if not all used types support such a function. However, this does not appear to work for functions with trailing return type specification. Below is a small experiment: // helper function for case A workaround template <typename A, typename T> auto F(T&& x) -> decltype(x.template f <A>()) { return x.template f <A>(); } // helper function for case B workaround template <typename A, typename T> auto G(T&&

问题 Is there actually any reason to use the following syntax anymore : template<typename T> auto access(T& t, int i) -> decltype(t[i]) { return t[i]; } Now that we can use : template<typename T> decltype(auto) access(T& t, int i) { return t[i]; } The trailing return type syntax now seems a little redundant? 回答1: Deduced return types are not SFINAE friendly. This overload will simply drop out of the overload set if t[i] is invalid: template<typename T> auto access(T& t, int i) -> decltype(t[i]) {

问题 What is the usage of adding -> auto in []() -> auto { return 4; } ? For me - it is not different than []() { return 4; } 回答1: It is auto by default. The Standard, [expr.prim.lambda]/4, reads: If a lambda-expression does not include a lambda-declarator , it is as if the lambda-declarator were () . The lambda return type is auto , which is replaced by the trailing-return-type if provided and/or deduced from return statements as described in [dcl.spec.auto]. My addition. So, -> auto itself is

问题 I'm trying to implement the following class: template <typename Container> class reverse_adaptor { public: // Construction reverse_adaptor(Container &container) : m_container(container) {} public: // STL container static polymorphism auto begin() const -> decltype(m_container.rbegin()) { return m_container.rbegin(); } auto end() const -> decltype(m_container.rend()) { return m_container.rend(); } private: // Members Container &m_container; }; The reason I'm using the trailing return type is

问题 I've been writing code, and I've recently found out that g++ doesn't warn me about a certain class of issue: per C++11 5.1.2.4, if your lambda is not a single return statement then the return type must be declared as a trailing-return-type or be void. Although g++ is allowed to compile invalid code if it makes enough sense, is there a way to either turn this behavior off (allowed with -fpedantic in g++-4.7) or all least warn about it? Example code: []() { return 0; } //is fine [&a]() { a++;

问题 This question already has answers here : decltype as a return type in class member function (3 answers) Closed 2 years ago . For example struct A { auto count() -> decltype(m_count) { return m_count; } int m_count; }; The above gets compilation error because m_count in decltype is not recognized. How to work around it? auto return and get the type from m_count must be used. The code compiles when the order is changed struct A { int m_count; auto count() -> decltype(m_count) { return m_count;

问题 I was merily experimenting with the new trailing return types, where I hit a problem with this (simplified) code #include <list> class MyContainer{ std::list<int> ints; auto begin( ) -> decltype(ints.begin()) { return ints.begin(); } auto begin( ) const -> decltype(ints.begin()) { return ints.begin(); } }; Ignore the fact of how pointless this code is. The important part is the compiler error generated when using GCC 4.6.1 (with -std=c++0x flag): In member function 'std::list<int>::iterator

问题 Suppose you attempt to do the following: template</* args */> typename std::enable_if< /*conditional*/ , /*type*/ >::type static auto hope( /*args*/) -> decltype( /*return expr*/ ) { } Is it possible to combine conditional inclusion/overloading ( std::enable_if ) with trailing-return-type ( auto ... -> decltype() )? I would not be interesting in solutions using the preprocessor. I can always do things like #define RET(t) --> decltype(t) { return t; } and extend it to take also the whole