c++17

Given the following code: #include <iostream> #include <optional> struct foo { explicit operator std::optional<int>() { return std::optional<int>( 1 ); } explicit operator int() { return 0; } }; int main() { foo my_foo; std::optional<int> my_opt( my_foo ); std::cout << "value: " << my_opt.value() << std::endl; } gcc 7.2.0 writes value: 1 . MSVC 2017 (15.3) and clang 4.0.0 however write value: 0 . Which one is correct according to the C++ standard? Since this is direct-initialization, we enumerate the constructors and just pick the best one. The relevant constructors for std::optional are :

Say we have this header file: MyClass.hpp #pragma once #include <vector> class MyClass { public: MyClass(double); /* ... */ private: std::vector<double> internal_values; }; Now, whenever we use #include "MyClass.hpp" in some other hpp or cpp file, we effectively also #include <vector> , despite the fact that we do not need it. The reason I am saying it is not needed is that std::vector is only used internally in MyClass , but it is not required at all to actually interact with this class . As a result, I could write Version 1: SomeOtherHeader.hpp #pragma once #include "MyClass.hpp" void func

Are multiple class template specialisations valid, when each is distinct only between patterns involving template parameters in non-deduced contexts? A common example of std::void_t uses it to define a trait which reveals whether a type has a member typedef called "type". Here, a single specialisation is employed. This could be extended to identify say whether a type has either a member typedef called "type1", or one called "type2". The C++1z code below compiles with GCC, but not Clang. Is it legal? template <class, class = std::void_t<>> struct has_members : std::false_type {}; template

Maybe I missed something, but I can't find any hints: is there a constexpr ternary operator in C++17 equivalent to constexpr-if? template<typename Mode> class BusAddress { public: explicit constexpr BusAddress(Address device) : mAddress(Mode::write ? (device.mDevice << 1) : (device.mDevice << 1) | 0x01) {} private: uint8_t mAddress = 0; }; No, there is no constexepr conditional operator. But you could wrap the whole thing in a lambda and immediately evaluate it (an IIFE ): template<typename Mode> class BusAddress { public: explicit constexpr BusAddress(Address device) : mAddress([&]{ if

In the following example, I can access the constexpr variable x from inside the lambda y without explicitly capturing it. This is not possible if x is not declared as constexpr . Are there special rules that apply to constexpr for capturing? int foo(auto l) { // OK constexpr auto x = l(); auto y = []{return x;}; return y(); // NOK // auto x2 = l(); // auto y2 = []{ return x2; }; // return y2(); } auto l2 = []{return 3;}; int main() { foo(l2); } Are there special rules that apply to constexpr for capturing/accessing? Yes, constexpr variables could be read without capturing in lambda : A lambda

So I have an std::string and have a function which takes char* and writes into it. Since std::string::c_str() and std::string::data() return const char* , I can't use them. So I was allocating a temporary buffer, calling a function with it and copying it into std::string . Now I plan to work with big amount of information and copying this buffer will have a noticeable impact and I want to avoid it. Some people suggested to use &str.front() or &str[0] but does it invoke the undefined behavior? C++98/03 Impossible. String can be copy on write so it needs to handle all reads and writes. C++11/14

In C++17 we got inline variables and I have assumed that global constexpr variables are implicitly inline. But apparently this is true only for static member variables. What is the logic/technical limitation behind this? source: A static member variable (but not a namespace-scope variable) declared constexpr is implicitly an inline variable. The point here is that constexpr int x = 1; at namespace scope has internal linkage in C++14. If you make it implicitly inline without changing the internal linkage part, the change would have no effect, because the internal linkage means that it can't be