c++17

问题 On MSVC 15.8.5 in debug mode I get that Run-Time Check Failure #2 - Stack around the variable 'insert_into' was corrupted. Is there a bug in MSVC or have I done something bad? Runs fine on clang version 6.0.0-1ubuntu2 and clang version 7.0.0-svn341916-1~exp1~20180911115939.26 #include <set> template <typename... T> struct Overload : T... { //support struct for combining and overloading multiple lambdas using T::operator()...; }; template <typename... T> Overload(T...)->Overload<T...>; using

问题 On MSVC 15.8.5 in debug mode I get that Run-Time Check Failure #2 - Stack around the variable 'insert_into' was corrupted. Is there a bug in MSVC or have I done something bad? Runs fine on clang version 6.0.0-1ubuntu2 and clang version 7.0.0-svn341916-1~exp1~20180911115939.26 #include <set> template <typename... T> struct Overload : T... { //support struct for combining and overloading multiple lambdas using T::operator()...; }; template <typename... T> Overload(T...)->Overload<T...>; using

问题 The following compiles in GCC 9 but not in clang 10 and I'm wondering which of the two compilers is standard conforming: template<typename T> struct A { static const T s; static const T v; }; template<typename T> constexpr const T A<T>::s = T(1); template<typename T> constexpr const T A<T>::v = A<T>::s; int main(int, char**) { constexpr auto a = A<double>::v; return 0; } This is intended to be a minimal example of a bigger issue which is why the fields s and v are explicitly declared as const

问题 Since there is no index based parallel for algorithm in c++17, I'm wondering if ranges::view::iota can be used in combination with std::for_each to emulate that. That is: using namespace std; constexpr int N= 10'000'000; ranges::iota_view indices(0,N); vector<int> v(N); for_each(execution::par_unseq,indices.begin(),indices.end(),[&](int i) { v[i]= i; }); iota_view seems to provide random access for appropriate types ([range.iota.iterator]): iota_view<I, Bound>::iterator::iterator_category is

问题 The reasoning of std::optional is made by saying that it may or may not contain a value. Hence, it saves us the effort of constructing a, probably, big object, if we don't need it. For example, a factory here, will not construt the object if some condition is not met: #include <string> #include <iostream> #include <optional> std::optional<std::string> create(bool b) { if(b) return "Godzilla"; //string is constructed else return {}; //no construction of the string required } But then how is

问题 There is a shared_mutex class planned for C++17. And shared_timed_mutex already in C++14. (Who knows why they came in that order, but whatever.) Then there is a recursive_mutex and a recursive_timed_mutex since C++11. What I need is a shared_recursive_mutex . Did I miss something in the standard or do I have to wait another three years for a standardized version of that? If there is currently no such facility, what would be a simple (first priority) and efficient (2nd priority) implementation

问题 Look at this simple code: struct Point { int x; int y; }; void something(int *); int main() { Point p{1, 2}; something(&p.x); return p.y; } I expect, that main 's return value can be optimized to return 2; , as something doesn't have access to p.y , it only gets a pointer to p.x . But, none of the major compilers optimize the return value of main to 2 . Godbolt. Is there something in the standard, which allows something to modify p.y , if we only give access to p.x ? If yes, does this depend

问题 Reading about universal references led me to wonder: how can I construct a class template such that it stores by reference if possible, or by value if it must? That is, can I do something like this template <class T> class holder { T obj_m; // should be a reference if possible... public: holder(T t) :obj_m { t } {} } auto hold_this(T && t) { return holder<T>(t); } Except that when hold_this() is given an lvalue the holder will hold a reference, and when given an rvalue the holder will make a

问题 When you have class template argument deduction available from C++17, why can't you deduce the template arguments of std::unique_ptr? For example, this gives me an error: std::unique_ptr smp(new D); That says "Argument list of class template is missing". Shouldn't the template arguments (at least the pointer type) be deducable? See this: any declaration that specifies initialization of a variable and variable template 回答1: I'm not going to repeat the rationale in @NathanOliver's great answer,

问题 When you have class template argument deduction available from C++17, why can't you deduce the template arguments of std::unique_ptr? For example, this gives me an error: std::unique_ptr smp(new D); That says "Argument list of class template is missing". Shouldn't the template arguments (at least the pointer type) be deducable? See this: any declaration that specifies initialization of a variable and variable template 回答1: I'm not going to repeat the rationale in @NathanOliver's great answer,