Any reason to use std::string anymore?

With std::string_view, is there any reason to prefer std::string over std::string_view now? I didn't even know std::string_view existed.
Last edited on
string_view is a window into an existing string. I still need std::string to create that string (or a string literal), and if I want to edit the string, string_view won't do either.
Last edited on
http://www.modernescpp.com/index.php/c-17-avoid-copying-with-std-string-view
The purpose of std::string_view is to avoid copying data which is already owned by someone else and of which only a non-mutating view is required.


Apples and oranges. IMHO, based on descriptions, the string_view is much closer to a "smart pointer" than a string. You should prefer to use a wrapper, where the use of wrapper is more effective than the direct use of objects.
Ah right, I misunderstood it's use. So when passing a string into a function as a parameter would it make more sense to now pass an std::string_view rather than a const std::string& (const ref string)
string_view is much closer to a "smart pointer" than a string

Except that it's not smart. It's smart in the sense that it has additional functionality compared to a raw char* pointer but it doesn't handle memory ownership like unique_ptr and shared_ptr do. It just keeps a non-owning raw pointer to the underlying character array, plus the length.

So when passing a string into a function as a parameter would it make more sense to now pass an std::string_view rather than a const std::string& (const ref string)

Yes. If you pass a string literal it will no longer have to construct a string object (and copy the characters) each time the function is called.
Last edited on
So a string_view doesn't really help performance-wise if you're only passing around std::string references, but is better when passing a string literal into a function that expects an std::string reference, because it prevents the std::string constructor from being called?
(i.e. the constructor for std::string_view(const char*) is very lightweight)
Last edited on
std::string_view allows us to create and use sub-strings without constructing a std::string, in an exception free manner; std::string_view is much more efficient in this case.
Note that while converting a std::string to a std::string_view is cheap the opposite is not true.

If the string that is passed to your function is a std::string and you want to pass it to another function that expects a const std::string& it would be less efficient to use a std::string_view because the conversion back and forth forces you to create an unnecessary copy of the string.

1
2
3
4
5
6
7
8
9
10
11
void another_function(const std::string&);

void your_function(std::string_view sv)
{
	another_function(std::string{sv}); // unnecessary copy
}

void function_calling_your_function(const std::string& s)
{
	your_function(s);
}


Also note that std::string_view is not necessarily null-terminated so you can't simply pass it to a function that expects a C-style string (const char*) without making a null-terminated copy of the string.
About performance of std::string_view vs std::string from C++17
https://www.bfilipek.com/2018/07/string-view-perf.html
Note that much of the differences in performance in Bartek's benchmarks has to do with not using the same method.
For std::string he used iterators and for std::string_view he used indices.

If you use the same method for both then std::string_view wins hands down.
http://quick-bench.com/ZbCokit3kd4p0B0-2fDxvfRZ8xE (iterators)
http://quick-bench.com/5MZ0Osf5lqtuawKfiajfRo8FqBY (indices)
Last edited on
Topic archived. No new replies allowed.