c++17

问题 The following code contains a fold expression, which afaiu is a c++17 feature: template <typename... T> static bool variable_length_or(const T ... v) { return (v || ...); } bool foo () { return variable_length_or(true, false, true, false); } what I find odd is that both g++ and clang++ seem to be fine with it when building with -std=c++14 (compiler-explorer). They do create a warning: <source>:2:16: warning: pack fold expression is a C++17 extension [-Wc++17-extensions] return (v || ...);

问题 In implementation of reader-writer lock, we can make use of the std::shared_mutex with std::shared_lock and std::lock_guard or std::unique_lock . Question > Is this new feature writer or reader preferring? Update based on Andrew's comment Reference: // Multiple threads/readers can read the counter's value at the same time. unsigned int get() const { std::shared_lock<std::shared_mutex> lock(mutex_); return value_; } // Only one thread/writer can increment/write the counter's value. void

问题 Considering the following code snippet: template <typename TF> void post(TF){ } template <typename... TFs> struct funcs : TFs... { funcs(TFs... fs) : TFs{fs}... { } void call() { (post([&]{ static_cast<TFs&>(*this)(); }), ...); } }; clang++ 3.8+ successfully compiles the code. g++ 7.0 fails to compile with the following error: prog.cc: In lambda function: prog.cc:10:43: error: parameter packs not expanded with '...': (post([&]{ static_cast<TFs&>(*this)(); }), ...); ~~~~~~~~~~~~~~~~~~~~~~~~^~

问题 Consider the following: struct X { X() {} X(X&&) { puts("move"); } }; X x = X(); In C++14, the move could be elided despite the fact that the move constructor has side effects thanks to [class.copy]/31, This elision of copy/move operations ... is permitted in the following circumstances ... when a temporary class object that has not been bound to a reference (12.2) would be copied/moved to a class object with the same cv-unqualified type In C++17 this bullet was removed. Instead the move is

问题 In n4502 the authors describe an early implementation of the detect idiom that encapsulates the void_t trick. Here's its definition along with usage for defining a trait for is_assignable (really it's is_copy_assignable ) template<class...> using void_t = void; // primary template handles all types not supporting the operation: template< class, template<class> class, class = void_t< > > struct detect : std::false_type { }; // specialization recognizes/validates only types supporting the

问题 I was looking at the various signatures for std::find_if on cppreference.com, and I noticed that the flavors that take a predicate function appear to accept it by value: template< class InputIt, class UnaryPredicate > InputIt find_if( InputIt first, InputIt last, UnaryPredicate p ); If I understand them correctly, lambdas with captured variables allocate storage for either references or copies of their data, and so presumably a "pass-by-value" would imply that the copies of captured data are

问题 This is a follow up of this question. As mentioned in the comments to the answer: An inline variable has the property that - It has the same address in every translation unit . [...] Usually you achieved that by defining the variable in a cpp file, but with the inline specifier you can just declare/define your variables in a header file and every translation unit using this inline variable uses exactly the same object. Moreover, from the answer itself: While the language does not guarantee

问题 Please consider the following code snippet: template<class Tuple> class vector { public: typename Tuple::size_type size() const noexcept(noexcept(m_elements.size())) { return m_elements.size(); } private: Tuple m_elements; }; class tuple { public: using size_type = std::size_t; size_type size() const { return 0; } size_type size() noexcept { return 0; } }; int main() { vector<tuple> x; static_assert(noexcept(x.size()), "x.size() might throw"); return 0; } Is the use of the member variable m

问题 Inspired by this answer, I tried to copy and paste (and add testing in main() ) this code: template<typename T> std::tuple<int, double> foo(T a) { if constexpr (std::is_same_v<int, T>) return {a, 0.0}; else if (std::is_same_v<double, T>) return {0, a}; else return {0, 0.0}; } int main() { auto [x, y] = foo(""); std::cout << x << " " << y; } This is very straightforward - if T is deduced as int , we want to return a tuple of [a, 0.0] . If T is deduced as double , we want to return a tuple of

问题 Closed. This question is off-topic. It is not currently accepting answers. Want to improve this question? Update the question so it's on-topic for Stack Overflow. Closed 5 years ago . There is a study group in the C++ standardization committee to provide compile-time reflection in C++1z or after. I would like to know what is exactly the purpose and how powerful the expected tools will be? For example will it be possible to name functions or classes using these tools? struct A {int f() {return