language-lawyer

问题 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

问题 C++11 first introduced support for defining new literals into C++ by means of user-defined literals . Does C++11 or later also predefine suffixes for fixed-width integer literals for types in <cstdint> ? 回答1: No. As of C++14 the only literal suffixes defined by the standard are provided by <chrono> , <complex> and <string> headers in the standard library. The <chrono> header defines the h , min , s , ms , us , ns suffixes for time durations, <complex> defines the i , il and if suffixes for

问题 C++11 first introduced support for defining new literals into C++ by means of user-defined literals . Does C++11 or later also predefine suffixes for fixed-width integer literals for types in <cstdint> ? 回答1: No. As of C++14 the only literal suffixes defined by the standard are provided by <chrono> , <complex> and <string> headers in the standard library. The <chrono> header defines the h , min , s , ms , us , ns suffixes for time durations, <complex> defines the i , il and if suffixes for

问题 What section of the C++11 standard (here's a copy of a draft standard) requires associative containers like std::set, std::map, std::unordered_set, and std::unordered_map to immediately call destructors of objects that are erased from them? To put it another way - are standard-compliant associative containers allowed to delay (not elide!) their calls to the key and/or value destructors of the keys and values they store? If not, what section in the standard forbids it? I ask because I am

问题 std::get does not seem to be SFINAE-friendly, as shown by the following test case: template <class T, class C> auto foo(C &c) -> decltype(std::get<T>(c)) { return std::get<T>(c); } template <class> void foo(...) { } int main() { std::tuple<int> tuple{42}; foo<int>(tuple); // Works fine foo<double>(tuple); // Crashes and burns } See it live on Coliru The goal is to divert the second call to foo towards the second overload. In practice, libstdc++ gives: /usr/local/bin/../lib/gcc/x86_64-pc-linux

问题 std::get does not seem to be SFINAE-friendly, as shown by the following test case: template <class T, class C> auto foo(C &c) -> decltype(std::get<T>(c)) { return std::get<T>(c); } template <class> void foo(...) { } int main() { std::tuple<int> tuple{42}; foo<int>(tuple); // Works fine foo<double>(tuple); // Crashes and burns } See it live on Coliru The goal is to divert the second call to foo towards the second overload. In practice, libstdc++ gives: /usr/local/bin/../lib/gcc/x86_64-pc-linux

问题 For example, #include <iostream> int main() { unsigned n{}; std::cin >> n; std::cout << n << ' ' << (bool)std::cin << std::endl; } When input -1 , clang 6.0.0 outputs 0 0 while gcc 7.2.0 outputs 4294967295 1 . I'm wondering who is correct. Or maybe both are correct for the standard does not specify this? By fail, I take to mean (bool)std::cin be evaluated false. clang 6.0.0 fails input -0 too. As of Clang 9.0.0 and GCC 9.2.0, both compilers, using either libstdc++ or libc++ in the case of

问题 This question already has an answer here : Fallback variadic constructor - why does this work? (1 answer) Closed 2 years ago . Consider this program: #include <iostream> #include <type_traits> using namespace std; struct russell { template <typename barber, typename = typename enable_if<!is_convertible<barber, russell>::value>::type> russell(barber) {} }; russell verify1() { return 42L; } russell verify2() { return 42; } int main () { verify1(); verify2(); cout << is_convertible<long, russell

问题 This question already has an answer here : Fallback variadic constructor - why does this work? (1 answer) Closed 2 years ago . Consider this program: #include <iostream> #include <type_traits> using namespace std; struct russell { template <typename barber, typename = typename enable_if<!is_convertible<barber, russell>::value>::type> russell(barber) {} }; russell verify1() { return 42L; } russell verify2() { return 42; } int main () { verify1(); verify2(); cout << is_convertible<long, russell

问题 As answered elsewhere, calling functions like memcpy with invalid or NULL pointers is undefined behaviour, even if the length argument is zero. In the context of such a function, especially memcpy and memmove , is a pointer just past the end of the array a valid pointer? I'm asking this question because a pointer just past the end of an array is legal to obtain (as opposed to, e.g. a pointer two elements past the end of an array) but you are not allowed to dereference it, yet footnote 106 of