c++17

问题 Consider this example: template <class T> void Yeap(T); int main() { Yeap(0); return 0; } template <class T> void YeapImpl(); struct X; template <class T> void Yeap(T) { YeapImpl<X>(); // pass X to another template } template <class T> void YeapImpl() { T().foo(); } struct X { void foo() {} }; Note that struct X is not defined until the very end. I used to believe that all odr-used names must be complete at the point of the instantiation. But here, how can the compiler treat it as a complete

问题 template<typename Container, typename Ret, typename ...Args> struct BindImpl { template<Ret (Container::*MemberFunc)(Args...)> class Callable { public: inline constexpr Callable (Container *container) : m_container(container) {} inline Ret operator() (Args ...args) const { return (m_container->*MemberFunc)(std::forward<Args>(args)...); } inline Function<Ret(Args...)> toFunction() const { return Function<Ret(Args...)>(*this); } private: Container *m_container; }; }; template<typename Container

问题 I have following example #include <cstdint> class FooC { public: FooC(uint16_t iPort, uint16_t iPin) : PORT(iPort) , PIN(iPin) { }; ~FooC() = default; FooC() = delete; FooC(const FooC&) = delete; FooC(FooC&&) = delete; private: const uint16_t PORT; const uint16_t PIN; }; int main() { FooC array[2] = { FooC(1,2), FooC(3,4) }; } and I don't want to call the default, move and copy constructor. Due to that I deleted the functions. Unfortunately this results in following error (compiled with C++11

问题 I thought that initializing a std::optional with std::nullopt would be the same as default construction. They are described as the same at cppreference, as form (1) However, both Clang and GCC seem to treat these toy example functions differently. #include <optional> struct Data { char large_data[0x10000]; }; std::optional<Data> nullopt_init() { return std::nullopt; } std::optional<Data> default_init() { return {}; } Compiler Explorer seems to imply that using std::nullopt will simply set the

问题 I thought that initializing a std::optional with std::nullopt would be the same as default construction. They are described as the same at cppreference, as form (1) However, both Clang and GCC seem to treat these toy example functions differently. #include <optional> struct Data { char large_data[0x10000]; }; std::optional<Data> nullopt_init() { return std::nullopt; } std::optional<Data> default_init() { return {}; } Compiler Explorer seems to imply that using std::nullopt will simply set the

问题 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? 回答1: Since this is direct-initialization, we

问题 After C++11, I thought of c_str() and data() equivalently. C++17 introduces an overload for the latter, that returns a non-constant pointer (reference, which I am not sure if it's updated completely w.r.t. C++17): const CharT* data() const; (1) CharT* data(); (2) (since C++17) c_str() does only return a constant pointer: const CharT* c_str() const; Why the differentiation of these two methods in C++17, especially when C++11 was the one that made them homogeneous? In other words, why only the

问题 After C++11, I thought of c_str() and data() equivalently. C++17 introduces an overload for the latter, that returns a non-constant pointer (reference, which I am not sure if it's updated completely w.r.t. C++17): const CharT* data() const; (1) CharT* data(); (2) (since C++17) c_str() does only return a constant pointer: const CharT* c_str() const; Why the differentiation of these two methods in C++17, especially when C++11 was the one that made them homogeneous? In other words, why only the

问题 In the latest working draft (page 572) of the C++ standard the converting constructor of std::variant is annotated with: template <class T> constexpr variant(T&& t) noexcept(see below ); Let Tj be a type that is determined as follows: build an imaginary function FUN (Ti) for each alternative type Ti. The overload FUN (Tj) selected by overload resolution for the expression FUN (std::forward<T>(t)) defines the alternative Tj which is the type of the contained value after construction. Effects:

问题 The way std::variant dispatches to different visitor methods when std::visit is called is pretty reasonable when the variant alternatives are completely different types. Essentially a visitor-specific vtable is built at compile-time and after some error checking 1 the appropriate visitor function is looked by indexing the table based the current index() which resolves to something like an indirect jump on most platforms. If the alternatives share a common base class, however, calling a (non