c++17

In n4502 the authors describe an early implementation of the detect idiom that encapsulates the void_t trick. Here's its definition along with usage for defining a trait for is_assignable (really it's is_copy_assignable ) template<class...> using void_t = void; // primary template handles all types not supporting the operation: template< class, template<class> class, class = void_t< > > struct detect : std::false_type { }; // specialization recognizes/validates only types supporting the archetype: template< class T, template<class> class Op > struct detect< T, Op, void_t<Op<T>> > : std::true

I have a std::variant that I'd like to convert to another std::variant that has a super-set of its types. Is there a way of doing it than that allows me to simply assign one to the other? template <typename ToVariant, typename FromVariant> ToVariant ConvertVariant(const FromVariant& from) { ToVariant to = std::visit([](auto&& arg) -> ToVariant {return arg ; }, from); return to; } int main() { std::variant<int , double> a; a = 5; std::variant <std::string, double, int> b; b = ConvertVariant<decltype(b),decltype(a)>(a); return 0; } I'd like to be able to simply write b = a in order to do the

This question already has an answer here: Link errors using <filesystem> members in C++17 2 answers I'm having an issue with my C++ built when trying to use the std::filesystem::directory_iterator from the C++17 standard. Here is the code: std::vector<std::string> IO::getDirectoryList(std::filesystem::path& dirPath) { std::vector<std::string> files; for (auto& file : std::filesystem::directory_iterator(".")) { files.push_back(file.path()); } return files; } I get the following error: > In function > `StoryTime::IO::getDirectoryList(std::filesystem::__cxx11::path&)': > IO.cpp:(.text+0x122):

Is there a utility in the standard library to get the index of a given type in std::variant ? Or should I make one for myself? That is, I want to get the index of B in std::variant<A, B, C> and have that return 1 . There is std::variant_alternative for the opposite operation. Of course, there could be many same types on std::variant 's list, so this operation is not a bijection, but it isn't a problem for me (I can have first occurrence of type on list, or unique types on std::variant list). We could take advantage of the fact that index() almost already does the right thing. We can't

I have a method that takes std::string_view and uses function, which takes null terminated string as parameter. For example: void stringFunc(std::experimental::string_view str) { some_c_library_func(/* Expects null terminated string */); } The question is, what is the proper way to handle this situation? Is str.to_string().c_str() the only option? And I really want to use std::string_view in this method, because I pass different types of strings in it. You cannot alter a string through std::string_view . Therefore you cannot add a terminating '\0' character. Hence you need to copy the string

Consider this code: #include <vector> struct A { static constexpr int kDefaultValue = -1; std::vector<int> v; A(int n): v(n, A::kDefaultValue) {} }; int main() { A(10); return 0; } It fails to link (llvm clang, gcc 4.9, both on OS X): Undefined symbols for architecture x86_64: "A::kDefaultValue", referenced from: A::(int) in main.cpp.o ld: symbol(s) not found for architecture x86_64 The question is what's wrong with it? It can be fixed by static_cast -ing A::kDefaultValue to int . Or by moving kDefaultValue out of A . Both cases seem to be ugly. Is this another way to make it link? This

I've seen on cppreference that std::function::argument_type was deprecated in C++17. What is the reason behind it? And what ISO WG21 paper was proposing that? The relevant papers are P0005R4 (which is the paper that was voted into the draft standard) and P0090R0 (which is referenced by P0005R4). Quotes from P0090R0: Q2. What's wrong with result_type, etc.? A2. These C++98/03/TR1-era typedefs predated decltype and perfect forwarding. Previously, generic code had to request information from function objects before adapting them. Now, manually communicating that information is unnecessary.

This question aims for using std::byte with standard input-output. Are there any plans to add proper function overloads for read(_bytes) and write(_bytes) to the interfaces of basic_istream<CharT> and basic_ostream<CharT> in a future standard? What reasons speak against it? I understand that the CharT* -overloads should be kept. What can I do to use std::byte ? I currently define in my project functions std::istream& read(std::istream&, std::byte*, std::streamsize) std::ostream& write(std::ostream&, const std::byte*, std::streamsize) These use reinterpret_cast<> to char* resp. const char* but

Is it possible to determine how many variable names should I to specify in square brackets using structured bindings syntax to match the number of data members of a plain right hand side struct ? I want to make a part of generic library, which uses structured bindings to decompose arbitrary classes into its constituents. At the moment there is no variadic version of structured bindings (and, I think, cannot be for current syntax proposed), but my first thought is to make a set of overloadings of some function decompose() , which performs decomposition of struct parameter into a set of its