c++14 | 易学教程

GCC can't capture 'this' pointer to templated type using init-capture

阅读更多关于 GCC can't capture 'this' pointer to templated type using init-capture

问题 A templated class can capture its own this pointer in a lambda: template <typename T> class Foo { public: void foo(void) {} auto getCallableFoo(void) { return [this]() { this->foo(); }; } }; This and all other Foo examples can be tested using the following code: int main() { Foo<int> f; auto callable = f.getCallableFoo(); callable(); } However, if instead an init-capture is used, this no longer works with GCC: auto getCallableFoo(void) { return [ptr = this]() { ptr->foo(); }; } Error message

std::unordered_map<T,std::unique_ptr<U>> copyable? GCC bug?

阅读更多关于 std::unordered_map copyable? GCC bug?

问题 g++ --version yields: g++.exe (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 4.9.1 Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Program: #include <memory> #include <type_traits> #include <unordered_map> static_assert(!std::is_copy_constructible<std::unordered_map<int,std::unique_ptr<int>>>::value,"Copyable"); int main () { } Result of

Matching variadic non-type templates

阅读更多关于 Matching variadic non-type templates

Let's say I have two structs, Foo and Bar : template<int...> struct Foo{}; template<unsigned long...> struct Bar{}; I want to create a type trait (call it match_class ) that returns true if I pass two Foo<...> types or two Bar<...> types, but false if I try to mix them: int main() { using f1 = Foo<1, 2, 3>; using f2 = Foo<1>; using b1 = Bar<1, 2, 3>; using b2 = Bar<1>; static_assert(match_class<f1, f2>::value, "Fail"); static_assert(match_class<b1, b2>::value, "Fail"); static_assert(!match_class<f1, b1>::value, "Fail"); } For C++1z (clang 5.0.0 and gcc 8.0.0) it's sufficient to do this ( Demo

Checking if a sequence container is contiguous in memory

阅读更多关于 Checking if a sequence container is contiguous in memory

问题 Is there a way to check if a sequence container is contiguous in memory? Something like: #include <iostream> #include <vector> #include <deque> #include <array> int main() { std::cout << std::boolalpha; std::cout << is_contiguous<std::vector<int>>::value << '\n' // true std::cout << is_contiguous<std::deque<int>>::value << '\n'; // false std::cout << is_contiguous<std::array<int, 3>>::value << '\n'; // true } Clarification This question is referring to type traits, rather than the properties

Possible to instantiate templates using a for loop in a C++14 constexpr function?

阅读更多关于 Possible to instantiate templates using a for loop in a C++14 constexpr function?

问题 I've been messing around with an SVN build of clang to experiment with the relaxed rules for constexpr . One of the things I've been unable to determine as of yet is whether it's possible to loop through the elements inside a tuple at compile-time in a constexpr function. Because I don't have a C++14 compliant standard library to test on, I've prepared the following equivalent test: template<int N> constexpr int foo() { return N; } constexpr int getSum() { auto sum = 0; for (auto i = 0; i <

Why aren't std::algorithms constexpr and which could be?

阅读更多关于 Why aren't std::algorithms constexpr and which could be?

问题 Why aren't any std::algorithm methods constexpr ? If I understand the new C++14 rules correctly, many of these methods could be constexpr . For example, why can't std::find be constexpr ? static constexpr std::array<char, 4> DnaBases {'A', 'C', 'G', 'T'}; constexpr bool is_dna(char b) { return std::find(std::cbegin(DnaBases), std::cend(DnaBases), b) != std::cend(DnaBases); // why not? } Which other std::algorithm s could be constexpr ? 回答1: It could be constexpr , but cannot be evaluated as a

Given that p is a pointer is “p > nullptr” well-formed?

阅读更多关于 Given that p is a pointer is “p > nullptr” well-formed?

Given a pointer p : char *p ; // Could be any type assuming p is properly initialized is the following well-formed: if (p > 0) // or p > nullptr More generally is it well-formed to use a relational operator when one operand is a pointer and the other is a null pointer constant? In C++14 this code is ill-formed but prior to the C++14 this was well-formed code( but the result is unspecified ), as defect report 583: Relational pointer comparisons against the null pointer constant notes: In C, this is ill-formed (cf C99 6.5.8): void f(char* s) { if (s < 0) { } } ...but in C++, it's not. Why? Who

C++ Compiler allows circular definition?

阅读更多关于 C++ Compiler allows circular definition?

I ran into the following oddity when making a mistake writing some code for trees. I've stripped down this example a lot so it is only a Linear Tree. Basically, in the main() function, I wanted to attach a Node to my tree, but instead of attaching it to "tree.root", I attached it to just "root". However, to my surprise, not only did it all compile just fine, but I was able to call methods on the nodes . It only errored when I tried to access the "value" member variable. I guess my main question is, why didn't the compiler catch this bug? std::shared_ptr<Node> root = tree.AddLeaf(12, root);

Does the defaulted default constructor initialize variables to zero?

阅读更多关于 Does the defaulted default constructor initialize variables to zero?

问题 I'm updating a class to C++14, and trying to figure out the simplest way to initialize all of the instance variables to zero on construction. Here's what I have so far: class MyClass { public: int var; float* ptr; double array[3]; MyStruct data; unique_ptr<MyStruct> smart_ptr; MyClass() = default; ~MyClass() = default; } Is setting the constructor to default the equivalent of doing: MyClass() : var{}, ptr{}, array{}, data{}, smart_ptr{} {} ... or do I need to init each variable? (I've tried

T declval() instead of T && declval() for common_type

阅读更多关于 T declval() instead of T && declval() for common_type

Isn't it better to use std::declval declared in form: template< class T > T declval(); // (1) then current one: template< class T > T && declval(); // (2) for std::common_type (possibly with different name only for this current purpose)? Behaviour of common_type using (1) is closer to the behaviour of the ternary operator (but not using std::decay_t ) than the behaviour when using (2) : template< typename T > T declval(); template <class ...T> struct common_type; template< class... T > using common_type_t = typename common_type<T...>::type; template <class T> struct common_type<T> { typedef T