c++17

Looking at below code sample I would expect it to perform mandatory copy elision as part of Return Value Optimization (RVO) and compile with C++17 (/std:c++17) but it compiles with an error on Visual Studio 2017 (I'm using VS17, 15.9.8 more specifically). class NoCopyOrMove { public: NoCopyOrMove() = default; NoCopyOrMove(int a, int b){} NoCopyOrMove(const NoCopyOrMove&) = delete; NoCopyOrMove& operator=(const NoCopyOrMove&) = delete; NoCopyOrMove(NoCopyOrMove&&) = delete; NoCopyOrMove& operator=(NoCopyOrMove&&) = delete; private: int a, b; }; NoCopyOrMove get(bool b) { return b ? NoCopyOrMove

What should happen if an expression's type is not dependent, but we use it to initialize a static auto variable? GCC and Clang differ in their behavior template<typename T> struct A { static inline auto x = sizeof(T{}.f); }; A<int> a; GCC doesn't raise an error. But Clang thinks that this is invalid because it instantiates the operand of "sizeof". GCC appears to skip that step because sizeof(T{}.f) always has type size_t (not type dependent), so it already knows type of x without instantiation. Both compilers conformly reject the program if we refer to x , for example by (void) a.x; . Does it

TL;DR: Can I expect that the code below will compile on any c++17 conformant c++ toolchain (based on the current c++17 proposal) and the failure of MSVC to do so is a bug in their implementation? #include <string_view> struct Foo : std::string_view {}; int main() { Foo f1{}; Foo f2{}; return f1 == f2; } Explanation: I have a class that is derived from std::string_view and doesn't implement its own comparison operators, because the std::string_view semantics are exactly what I need and I also want it to be comparable to e.g. a std::string . However, if I try to compare two instances of that

Here is described the nullopt_t and nullopt for the optional object proposed for c++: struct nullopt_t{see below}; constexpr nullopt_t nullopt(unspecified); [...] Type nullopt_t shall not have a default constructor. It shall be a literal type. Constant nullopt shall be initialized with an argument of literal type. The reason for this is explained in the The op = {} syntax chapter of the document: for the op = {} to be unambiguous some tricks have to be adopted, one of which is that nullopt_t must not be default constructible. My question is about what does the literal type means here? I found

This question already has an answer here: Pseudo-destructor call does not destroy an object 1 answer The following program... int main() { int{1}.~int(); } does not compile on (see conformance viewer ) : clang++ trunk, with -std=c++1z g++ trunk, with -std=c++1z CL 19 2017 Introducing a type alias for int ... int main() { using X = int; int{1}.~X(); } ...makes the program valid on all previously mentioned compilers, without warnings (see conformance viewer ) . Why is a type alias required when invoking int 's destructor? Is this because int is not a valid grammar element for a destruction

I have found that the following piece of code: #include <iostream> #include <vector> template <typename T> struct X : std::false_type {}; template <template <typename> class Y, typename U> struct X<Y<U>> : std::true_type {}; int main() { if (X<int>()) std::cout << "wrong\n"; if (X<std::vector<double>>()) std::cout << "correct\n"; return 0; } Only prints correct when compiled with g++-7 with -std=c++1z . Other versions of g++ , clang++ or other std flags fail to produce correct. Is this a bug of the current implementation, and this code should not print anything, or is something changed in C+