c++17

I read about enumeration declaration in C++ using cppreference . Then I have made Enum class and check whether it is a class type or not using std::is_class . #include <iostream> enum class Enum { red = 1, blue, green }; int main() { std::cout << std::boolalpha; std::cout << std::is_class<Enum>::value << '\n'; } Then I compiled and ran in G++ compiler on Linux platform, it prints false value. So Is enum class type or not? If enum is a class type, then why I'm getting false value? enum class is not a class definition - the combination of keywords is used to define a scoped enumeration , which

In Herb Sutter's talk at CppCon16 he suggested writing pimpl idiom with const std::unique_ptr (roughly 10 minutes in). How is this supposed to work with move constructors/assignments? Is there something in c++17? I couldn't find anything. If your class is supposed to be never-empty, a non-const unique ptr (with default move/assigns) is not appropriate. The move ctor and move assign will both empty the rhs. A const unique ptr will disable these automatic methods, and if you want move you will have to write it within the impl (and a bit of glue outside). I would personally write a value ptr with

Consider a method that returns a std::string_view either from a method that returns a const std::string& or from an empty string. To my surprise, writing the method this way results in a dangling string view: const std::string& otherMethod(); std::string_view myMethod(bool bla) { return bla ? otherMethod() : ""; // Dangling view! } https://godbolt.org/z/1Hu_p2 It seems that the compiler first puts a temporary std::string copy of the result of otherMethod() on the stack and then returns a view of this temporary copy instead of just returning a view of the reference. First I thought about a

According to this answer , since C++17, even if a pointer has the right address and the right type dereferencing it can cause undefined behaviour . alignas(int) unsigned char buffer[2*sizeof(int)]; auto p1=new(buffer) int{}; auto p2=new(p1+1) int{}; *(p1+1)=10; // UB since c++17 The reason is that the pointer value of p1+1 is a pointer past-the-end of an object. Can this example be brought back to defined behavior using std::launder : *std::launder(p1+1)=10; // still UB? Secondly, would it also be useful in this following case? alignas(int) unsigned char buffer[3*sizeof(int)]; auto pi = new

Studying about "noexcept specifier(and operator)", I wrote a simple code. And I am surprised that this piece of code: void asdf() noexcept {} int main() { auto f = asdf; std::cout << std::boolalpha << noexcept(f()) << std::endl; } prints false , even function "asdf" is noexcept-specified. So while searching why this mysterious phenomenon is happening, I found C++17's "exception specifier type system"- P0012R1 . According to this (accepted) proposal, since C++17; as noexcept is part of function type, will the code above print true ? And one more, in this question's one line: std::function<void(