c++17

Implementing rvalue references as parameters in function overloads

£可爱£侵袭症+ 提交于 2019-12-07 05:28:20
问题 I've already asked on code review and software engineering but the topic didn't fit the site, so I'm asking here hoping this is not opinion-based. I am an "old school" C++ developer (I've stopped at C++ 2003) but now I've read a few books on modern C++ 11/17 and I'm rewriting some libraries of mine. The first thing I've made is adding move constructor/assignment operator where needed ( = classes that already had destructor + copy constructor and copy assignment). Basically I'm using the rule

Initializer “sizeof(T)” of inline static auto… Does it need instantiation?

被刻印的时光 ゝ 提交于 2019-12-07 05:19:28
问题 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

Why Must I Still Use -lstdc++fs?

老子叫甜甜 提交于 2019-12-07 05:17:27
问题 There have been several questions about getting experimental/filesystem to compile in the latest versions of GCC and Clang: experimental::filesystem linker error But now filesystem has been accepted into c++17 so no more need for experimental or the -lstdc++fs flag, right? Wrong I cannot even #include <filesystem> on the head version of either clang++ or g++ when I try on: http://melpon.org/wandbox Is there still some other argument I need? -lstdc++fs just gives me the experimental version,

Why does std::apply fail with a generic function?

我怕爱的太早我们不能终老 提交于 2019-12-07 05:06:20
问题 Taken from cppreference, why does the call to std::apply(add_generic, ...) fail to compile? Is there a way to fix it? #include <iostream> #include <tuple> int add(int first, int second) { return first + second; } template<typename T> T add_generic(T first, T second) { return first + second; } int main() { std::cout << std::apply(add, std::make_tuple(1,2)) << '\n'; // template argument deduction/substitution fails std::cout << std::apply(add_generic, std::make_tuple(2.0f,3.0f)) << '\n'; } It

`std::any_cast` returns a copy

瘦欲@ 提交于 2019-12-07 04:58:58
问题 I was reading the documentation for std::any_cast and I find it strange that the API has the cast either return a value to the held object or a pointer to it. Why not return a reference? A copy needs to be made every time the function is called with a non pointer type argument. I can see that the pointer version of the cast might signal intentions a bit more and might be a bit more clear but why not have the value returned be a reference like this? template<typename ValueType> ValueType& any

std::any across shared library bounding in mingw

白昼怎懂夜的黑 提交于 2019-12-07 04:12:32
问题 I stumbled about an issue while using libstdc++'s std::any implementation with mingw across a shared library boundary. It produces a std::bad_any_cast where it obviously should not (i believe). I use mingw-w64, gcc-7 and compile the code with -std=c++1z. The simplified code: main.cpp: #include <any> #include <string> // prototype from lib.cpp void do_stuff_with_any(const std::any& obj); int main() { do_stuff_with_any(std::string{"Hello World"}); } lib.cpp: Will be compiled into a shared

Comparison for objects derived from std::string_view is ambiguous in MSVC

点点圈 提交于 2019-12-07 04:02:26
问题 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

experimental::optional nullopt_t constructor

蓝咒 提交于 2019-12-07 03:27:13
问题 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

Does std::vector::assign/std::vector::operator=(const&) guarantee to reuse the buffer in `this`?

拈花ヽ惹草 提交于 2019-12-07 02:47:15
问题 If I assign or copy one vector to another (that has the same or bigger capacity than the size of the former), can I assume that the buffer of the latter will be reused? The following example demonstrates that I can, however, is it guaranteed by the standard? Is there any difference between behaviour of std::vector::assign and std::vector::operator= in this regard? #include <vector> #include <iostream> #include <cassert> int main() { std::vector a {1, 2, 3, 4, 5}; std::vector b {1, 2, 3, 4};

Unpacking a typelist

狂风中的少年 提交于 2019-12-07 00:08:07
问题 Lets say I have a function that takes just a type template parameter, I cannot change it's definition/implementation. template < typename T > void do_it(); Now I have a typelist defined a usual way, can't change it either: template< typename ...Ts > struct typelist; I want to implement a function that takes a typelist, and runs do_it() on every type: template< typename List > void do_them(); The only solution I found up 'till now is: template< typename T > void do_them_impl() { do_it<T>(); }