c++17

问题 With class template argument deduction we can write: std::less Fn; However, G++ 8.2 rejects this code: #include <algorithm> #include <vector> #include <functional> int main() { std::vector v= { 1, 3, 2, 7, 5, 4 }; std::sort(v.begin(),v.end(),std::greater()); } emitting the following error: error: cannot deduce template arguments for 'greater' from () Clang++ 7.0 and MSVC 15.8.0 compile it without warnings. Which compiler is right? 回答1: GCC is wrong. There is already a bug report. [dcl.type

问题 I know that the C++ heavyweights are working on getting ranges into the language, or at least the standard library: Eric Niebler discusses ranges on his blog Interview with @BjarneStroustrup on his thoughts re C++17 ISO C++ standards committee (SC 22) proposal N4128 by Niebler, Parent and Sutton To be fair - I haven't read through the official suggestion. I'm just a humble C++ programmer who wants to use simple range functionality. What should I do today rather than after C++17 to use, say,

问题 std::make_unique() (and similar functions) have a little problem: #include <cstdio> #include <memory> using namespace std; struct S { S() { printf("ctor\n"); } ~S() { printf("dtor\n"); } S(S const&) { printf("cctor\n"); } S(S&&) { printf("mctor\n"); } }; S foo() { return S(); } int main() { { printf("--------------- case 1 ---------------\n"); unique_ptr<S> s1 = make_unique<S>( foo() ); } { printf("--------------- case 2 ---------------\n"); unique_ptr<S> s2 { new S( foo() ) }; } } Output: --

问题 What is the correct way to declare instantiation methods when defining an interface class? Abstract base classes are required to have a virtual destructor for obvious reasons. However, the following compilation warning is then given: "'InterfaceClass' defines a non-default destructor but does not define a copy constructor, a copy assignment operator, a move constructor or a move assignment operator", which is the 'rule of five'. I understand why the 'rule of five' should be obeyed in general,

问题 Say we have this header file: MyClass.hpp #pragma once #include <vector> class MyClass { public: MyClass(double); /* ... */ private: std::vector<double> internal_values; }; Now, whenever we use #include "MyClass.hpp" in some other hpp or cpp file, we effectively also #include <vector> , despite the fact that we do not need it. The reason I am saying it is not needed is that std::vector is only used internally in MyClass , but it is not required at all to actually interact with this class . As

问题 In the following example, I can access the constexpr variable x from inside the lambda y without explicitly capturing it. This is not possible if x is not declared as constexpr . Are there special rules that apply to constexpr for capturing? int foo(auto l) { // OK constexpr auto x = l(); auto y = []{return x;}; return y(); // NOK // auto x2 = l(); // auto y2 = []{ return x2; }; // return y2(); } auto l2 = []{return 3;}; int main() { foo(l2); } 回答1: Are there special rules that apply to

问题 In the following example, I can access the constexpr variable x from inside the lambda y without explicitly capturing it. This is not possible if x is not declared as constexpr . Are there special rules that apply to constexpr for capturing? int foo(auto l) { // OK constexpr auto x = l(); auto y = []{return x;}; return y(); // NOK // auto x2 = l(); // auto y2 = []{ return x2; }; // return y2(); } auto l2 = []{return 3;}; int main() { foo(l2); } 回答1: Are there special rules that apply to

问题 In C++17 we got inline variables and I have assumed that global constexpr variables are implicitly inline. But apparently this is true only for static member variables. What is the logic/technical limitation behind this? source: A static member variable (but not a namespace-scope variable) declared constexpr is implicitly an inline variable. 回答1: The point here is that constexpr int x = 1; at namespace scope has internal linkage in C++14. If you make it implicitly inline without changing the

问题 In C++17 we got inline variables and I have assumed that global constexpr variables are implicitly inline. But apparently this is true only for static member variables. What is the logic/technical limitation behind this? source: A static member variable (but not a namespace-scope variable) declared constexpr is implicitly an inline variable. 回答1: The point here is that constexpr int x = 1; at namespace scope has internal linkage in C++14. If you make it implicitly inline without changing the

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