The std::from_chars function does not throw, it only returns a value of type from_chars_result which is a struct with two fields: struct from_chars_result { const char* ptr; std::errc ec; }; You should inspect the values of ptr and ec when the function returns: #include <iostream> #include <string> #include <charconv> int main() { int i3; std::string_view … Read more
There is no need to use the c’tor taking a range. std::string has a constructor that operates in terms of std::string_view, number 10 in the list. The effect of which is template < class T > explicit basic_string( const T& t, const Allocator& alloc = Allocator() ); Implicitly converts t to a string view sv … Read more
When would I choose std::string by const& instead of string_view for function arguments? Do you need a null-terminated string? If so, then you should use std::string const& which gives you that guarantee. string_view does not – it’s simply a range of const char. If you do not need a null-terminated string, and you do not … Read more
A std::string_view doesn’t provide a conversion to a const char* because it doesn’t store a null-terminated string. It stores a pointer to the first element, and the length of the string, basically. That means that you cannot pass it to a function expecting a null-terminated string, like foo (how else are you going to get … Read more
You need to specify a transparent comparator explicitly (like std::less<>): std::map<std::string, int, std::less<>> m; // ~~~~~~~~~~^ std::map<K,V> defaults its comparator to std::less<K> (i.e., a non-transparent one), and since ([associative.reqmts]/p13): The member function templates find, count, lower_bound, upper_bound, and equal_range shall not participate in overload resolution unless the qualified-id Compare::is_transparent is valid and denotes a type … Read more
The problem is that std::string_view -> std::string makes a copy of the underlying memory, complete with heap allocation, whereas the implicit std::string -> std::string_view does not. If you’ve bothered to use a std::string_view in the first place then you obviously care about copies, so you don’t want one to happen implicitly. Consider this example: void … Read more
The reason for this is given in n3512 string_ref: a non-owning reference to a string, revision 2 by Jeffrey Yasskin: I also omitted operator+(basic_string, basic_string_ref) because LLVM returns a lightweight object from this overload and only performs the concatenation lazily. If we define this overload, we’ll have a hard time introducing that lightweight concatenation later. … Read more
The purpose of any and all kinds of “string reference” and “array reference” proposals is to avoid copying data which is already owned somewhere else and of which only a non-mutating view is required. The string_view in question is one such proposal; there were earlier ones called string_ref and array_ref, too. The idea is always … Read more
std::string_view is faster in a few cases. First, std::string const& requires the data to be in a std::string, and not a raw C array, a char const* returned by a C API, a std::vector<char> produced by some deserialization engine, etc. The avoided format conversion avoids copying bytes, and (if the string is longer than the … Read more