c++14

问题 The problem is the following, in C++14 : Let's have two functions FV&& valid_f , FI&& invalid_f , and arguments Args&&... args The function apply_on_validity should apply valid_f on args if the expression std::forward<FV>(valid_f)(std::forward<Args>(args)...) is valid Otherwise and if std::forward<FV>(invalid_f)(std::forward<Args>(args)...) is a valid expression, apply_on_validity should apply invalid_f on args Otherwise apply_on_validity should do nothing I guess the code should look like

问题 I have templated gray_code class which is meant to store some unsigned integer whose underlying bits are stored in Gray code order. Here it is: template<typename UnsignedInt> struct gray_code { static_assert(std::is_unsigned<UnsignedInt>::value, "gray code only supports built-in unsigned integers"); // Variable containing the gray code UnsignedInt value; // Default constructor constexpr gray_code() = default; // Construction from UnsignedInt constexpr explicit gray_code(UnsignedInt value):

问题 Having: struct Value { template<class T> static constexpr T value{0}; }; (0) ideone template<typename TValue> struct Something { void x() { static_assert(TValue::template value<int> == 0, ""); } }; int main() { Something<Value>{}.x(); return 0; } Does not compile with clang++ 3.6. error: cannot refer to variable template 'value' without a template argument list Does not compile with g++ 5.2. error: ‘template constexpr const T Value::value’ is not a function template (1) ideone Compiles with

问题 Background Everybody agrees that using <typedef-name> = <type>; is equivalent to typedef <type> <typedef-name>; and that the former is to be preferred to the latter for various reasons (see Scott Meyers, Effective Modern C++ and various related questions on stackoverflow). This is backed by [dcl.typedef]: A typedef-name can also be introduced by an alias-declaration. The identifier following the using keyword becomes a typedef-name and the optional attribute-specifier-seq following the

问题 Issue: passing a generic lambda (to a template function) that captures this and calls a member function of this without an explicit this-> does not compile on gcc. If the lambda is not generic, or if the lambda is not passed to any other function but called in place, it compiles withoit an explicit this-> . Clang is cool with the code in all situations. Time for another round of clang vs gcc . Who's right? Wandbox example template<typename TF> void call(TF&& f) { f(1); } struct Example { void

问题 I've seen N3690, N4140, and N4296 mentioned in various places. I'm guessing it's N4140 because that was released in late 2014. N4296 seems to have stuff that isn't in C++14, like fold expressions. 回答1: N3690 is an old committee draft for C++14; massive changes have been made since then (e.g., the removal of <optional> and <dynarray> ), and it shouldn't be used for anything other than perhaps standard archaeology. N3936 is the version that's sent out for final balloting (well, the version that

问题 I wanted to create a lambda in the following way: auto l1 = condition ? [](){ return true; } : [number](){ return number == 123; }; However, I got error: operands to ?: have different types ‘main()::<lambda()>’ and ‘main()::<lambda()>’ Obviously, the types seem to be the same. I thought, that capturing number in only one of lambdas might be a problem, but I get the same error for these: //check if capturing number in both lambdas would help auto l2 = condition ? [number](){ return true; } :

问题 Background For a long time, gcc has been providing a number of builtin bit-twiddling functions, in particular the number of trailing and leading 0-bits (also for long unsigned and long long unsigned , which have suffixes l and ll ): — Built-in Function: int __builtin_clz (unsigned int x) Returns the number of leading 0-bits in x , starting at the most significant bit position. If x is 0, the result is undefined. — Built-in Function: int __builtin_ctz (unsigned int x) Returns the number of

问题 Background For a long time, gcc has been providing a number of builtin bit-twiddling functions, in particular the number of trailing and leading 0-bits (also for long unsigned and long long unsigned , which have suffixes l and ll ): — Built-in Function: int __builtin_clz (unsigned int x) Returns the number of leading 0-bits in x , starting at the most significant bit position. If x is 0, the result is undefined. — Built-in Function: int __builtin_ctz (unsigned int x) Returns the number of

问题 What is the right way to initialize static data members in C++? I'm also interested in how it has changed from C++98, to C++11 to C++14. Here is an example: // bufferedOutput.h class BufferedOutput { // Static member declaration. static long bytecount; }; // bufferedOutput.cpp long BufferedOutput::bytecount = 50; Are there other ways to initialize static data members? 回答1: The rules have always been as follows: A const static data member (SDM) of integral or enumeration type can be