c++14 | 易学教程

void_t fails on Visual Studio 2015

阅读更多关于 void_t fails on Visual Studio 2015

问题 I don't understand why the following test always fails with Visual Studio 2015 (the static_assert triggers): #include <type_traits> using namespace std; template<class T> using try_assign = decltype(declval<T&>() = declval<T const&>()); template<class, class = void> struct my_is_copy_assignable : false_type {}; template<class T> struct my_is_copy_assignable<T, void_t<try_assign<T>>> : true_type {}; int main() { static_assert(my_is_copy_assignable<int>::value, "fail"); return 0; } It's

Approach for automatic fields reordering in C-like structs

阅读更多关于 Approach for automatic fields reordering in C-like structs

Is there a way to perform automatic fields reordering in C-like structs? I mean the using of the language features like( preprocessor for C and C++ and templates/type traits/etc for C++), which make it possible to do the following macro (Boost.Fusion-like style to adapt structures): REARRANGE(StructureName, (int8_t)(FieldName1), (int32_t)(FieldName2), (int16_t)(FieldName3), (int32_t)(FieldName4)); // is equivalent to (without loss of generality): struct StructureName { int32_t FieldName2; int32_t FieldName4; int16_t FieldName3; int8_t FieldName1; }; Of course, approach should take into account

Explaining a string trimming function

阅读更多关于 Explaining a string trimming function

问题 I came across the code below but need some help with understanding the code. Assume that the string s has spaces either side. string trim(string const& s){ auto front = find_if_not(begin(s), end(s), isspace); auto back = find_if_not(rbegin(s), rend(s), isspace); return string { front, back.base() }; } The author stated that back points to the end of the last space whereas the front points to the first non-white space character. So back.base() was called but I don't understand why. Also what

C++ Zero-Initialization

阅读更多关于 C++ Zero-Initialization

问题 I'm having trouble understanding when and why exactly a member in my class is zero-initialized according to http://en.cppreference.com/w/cpp/language/zero_initialization. Consider the following test program: #include <iostream> #include <stdio.h> class MyTest { private: const static unsigned int dimension = 8; void (* myFunctions [dimension])(); public: MyTest() {} void print() { for(unsigned int i=0; i < MyTest::dimension; i++) { printf("myFunctions[%d] = %p\n", i, this->myFunctions[i]); } }

Small object stack storage, strict-aliasing rule and Undefined Behavior

阅读更多关于 Small object stack storage, strict-aliasing rule and Undefined Behavior

问题 I am writing a type-erased function wrapper similar to std::function . (Yes, I have seen similar implementations and even the p0288r0 proposal, but my use-case is quite narrow and somewhat specialized.). The heavily simplified code below illustrates my current implementation: class Func{ alignas(sizeof(void*)) char c[64]; //align to word boundary struct base{ virtual void operator()() = 0; virtual ~base(){} }; template<typename T> struct derived : public base{ derived(T&& t) : callable(std:

SFINAE to assert() that code DOES NOT compile

阅读更多关于 SFINAE to assert() that code DOES NOT compile

I feel certain it must be possible to use SFINAE (possibly with Macros) to static_assert() that arbitary code will not compile. There are some complex cases in my code-base, where i have a class that I want to forbid taking temporaries (I believe the pattern is): class(const class&& tmp)=delete; /* deny copying from an unnamed temporary */ class (class&& rhs){/* allow construction from non-temporary rvalue*/} Currently, I check an undesired constructor DOES NOT compile, but then of course I have to comment it out to get the tests to compile again! If I could do: static_assert(DOES_NOT_COMPILE

Create a std::function type with limited arguments

阅读更多关于 Create a std::function type with limited arguments

Given the type of a callable function C , I want to get at compile time a std::function ; the type of which: has the same return type of function C the argument types are the first N argument types of function C This means that, for a given type void(int, char, double) and a given N , the type of the function is: N = 1 => result type: std::function<void(int)> N = 2 => result type: std::function<void(int, char)> N = 3 => result type: std::function<void(int, char, double)> N > 3 => compile time error Example: template<std::size_t N, typename R, typename... A> constexpr auto get() { return /*

Why specializing a type_trait could result in undefined behaviour?

阅读更多关于 Why specializing a type_trait could result in undefined behaviour?

Discussion According to the standard §20.10.2/1 Header <type_traits> synopsis [meta.type.synop]: 1 The behavior of a program that adds specializations for any of the class templates defined in this subclause is undefined unless otherwise specified. This specific clause contradicts to the general notion that STL should be expandible and prevents us from expanding type traits as in the example below: namespace std { template< class T > struct is_floating_point<std::complex<T>> : std::integral_constant < bool, std::is_same<float, typename std::remove_cv<T>::type>::value || std::is_same<double,

Why isn't move construction used when initiating a vector from initializer list (via implicit constructor)

阅读更多关于 Why isn't move construction used when initiating a vector from initializer list (via implicit constructor)

To demo move semantics, I wrote the following example code, with an implicit constructor from int. struct C { int i_=0; C() {} C(int i) : i_( i ) {} C( const C& other) :i_(other.i_) { std::cout << "A copy construction was made." << i_<<std::endl; } C& operator=( const C& other) { i_= other.i_ ; std::cout << "A copy assign was made."<< i_<<std::endl; return *this; } C( C&& other ) noexcept :i_( std::move(other.i_)) { std::cout << "A move construction was made." << i_ << std::endl; } C& operator=( C&& other ) noexcept { i_ = std::move(other.i_); std::cout << "A move assign was made." << i_ <<

Return value of placement new

阅读更多关于 Return value of placement new

问题 Consider the following C++14 code: #include <cassert> #include <new> #include <type_traits> struct NonStandardLayout { // ... }; int main() { using T = NonStandardLayout; std::aligned_storage_t< sizeof(T), alignof(T) > storage; T *const valid_ptr = new(static_cast<void *>(&storage)) T; T *const maybe_ptr = reinterpret_cast<T *>(&storage); assert(maybe_ptr == valid_ptr); // ??? valid_ptr->T::~T(); return 0; } Is it guaranteed by the standard that the assert in the example will never fail, for