c++17

问题 I have a situation where a function must return a value taken from a table. A cell in this table (let's assume the table just works...) may contain a value, or it might not. This value can also be one of several types: int, double, string, date (but no other type). What would such a function return? Is it a good idea to return std::optional<std::variant<std::string, int, double, std::chrono::time_point>> ? Would that be a good use of optional and variant ? 回答1: I would consider this to be a

问题 Consider this union: union A{ int a; struct{ int b; } c; }; c and a are not layout-compatibles types so it is not possible to read the value of b through a : A x; x.c.b=10; x.a+x.a; //undefined behaviour (UB) For Trial 1 and Trial 2 see this question Trial 3 Now let's use std::launder for what it does not seems to be intended: A x; x.a=10; auto p = &x.a; //(1) x.c.b=12; //(2) p = std::launder(p); //(2') *p+*p; //(3) UB? Could std::launder change anything? According to [ptr.launder]: template

问题 std::experimental::apply has the following signature: template <class F, class Tuple> constexpr decltype(auto) apply(F&& f, Tuple&& t); It basically invokes f by expanding t 's elements as the arguments. I would like something that does the exact same thing, but with multiple tuples at the same time: template <class F, class... Tuples> constexpr decltype(auto) multi_apply(F&& f, Tuples&&... ts); Example usage: std::tuple t0{1, 2, 3}; std::tuple t1{4, 5, 6}; auto sum = [](auto... xs){ return

问题 template <typename T> struct X { template <typename Iter> X(Iter a, Iter b) {} template <typename Iter> auto f(Iter a, Iter b) { return X(a, b); } }; In the "C++ Templates, The Complete Guide" 2nd edition, there was the previous example about the subtitles of implicit deduction guides with injected class names. The author mentioned that class argument deduction is disabled for injected class names because the type of the return of f would be X<Iter> due to the implicit deduction guide. But I

问题 What is the best way of declaring memory efficient Global Constants in C++1z which do not make internal linkage , so a single copy is used though out all the translation units ? Although it's been mentioned in many places, we didn't have any singular "The best approach" question and answer, so here it is. Here is a partial list of places where I have found related questions. constexpr global constants in a header file and odr global declarations/initializations using static, const, constexpr

问题 The current draft standard (and presumably C++17) say in [basic.compound/4]: [ Note: An array object and its first element are not pointer-interconvertible, even though they have the same address. — end note ] So a pointer to an object cannot be reinterpret_cast 'd to get its enclosing array pointer. Now, there is std::launder , [ptr.launder/1]: template<class T> [[nodiscard]] constexpr T* launder(T* p) noexcept ; Requires: p represents the address A of a byte in memory. An object X that is

问题 As a follow up of this question, I tested the behavior of both clang and gcc. It appears that the two compiler have a different interpretation of the c++ standard. In the example below, GCC refuses to compile, if a non copyable argument would need to be copied according to the deduction guide hypothetical constructor argument. Clang does not perform this check: #include <cstddef> struct not_copyable{ not_copyable()=default; not_copyable(const not_copyable&)=delete; }; struct movable{ movable(

问题 Assume we have a simple getter method in a class that returns a const reference to a std::string member: const std::string& getString() const noexcept { return someString; } With the advent of std::string_view in C++17, I wonder whether it has any advantages of writing this instead: const std::string_view getString() const noexcept { return someString; } Does one method have advantages/disadvantages over the other? Clearly (correct me if I'm wrong) both solutions will definitely be better

问题 Consider this simplified and very specific implementation of a recursive variant on top of std::variant : #include <map> #include <variant> struct recursive_tag; template <typename...> struct RecursiveVariant; template <> struct RecursiveVariant<int, std::map<int, recursive_tag>> : std::variant<int, std::map<int, RecursiveVariant<int, std::map<int, recursive_tag>>>> { using underlying = std::variant<int, std::map<int, RecursiveVariant<int, std::map<int, recursive_tag>>>>; using underlying:

问题 In C++, the expression left() = right() evaluates right() left() in that sequence. The right() goes first, as has been discussed here. I cannot think of a reason for right() to go first. Can you? I presume that there exists a reason. Otherwise, the standard would hardly say what it says, but consider: right() will return some result. At the machine-code level, does the CPU not need to know where to put the result right() will return before asking right() to return it? If you happen to know