Hacker News Reader

Comment by pdpi | Hacker News Reader

std::string_view is, as the name implies, a view into a std::string.

If you own the actual string, use std::string — there is no other string for you to view.

If somebody else owns it and you're working on the whole string `const std::string&` is probably your best bet — you're holding a reference to the string as a whole — but std::string_view also works and might make more sense in context.

If you're working with a substring of somebody else's string, std::string_view is the natural choice.

The key idea here is that you want to reference, rather than copy, some underlying string. If you're working on something where your code needs to own a deep copy of the original string for some reason, by all means continue using std::string!

View on HN

> If somebody else owns it and you're working on the whole string `const std::string&` is probably your best bet

Actually string_view is more general. You can build one out of a string literal, a vector<char>, some memory from a memmap call, and an unbounded list of other things. If an interface uses a `const std::string&` and you don't have one, you have to, implicitly or explicitly, copy the data into a `std::string` to be able to use that interface.

Is it just me, or does it seem like std::string_view is just an alternative in semantics to a `char *` plus a size? It doesn't null-terminate (which would require copying or mutating). Is there some extra safety checking this provides?

Under the hood it's just "std::pair<const char, std::size_t>". It's like an abstract data type or a newtype in Haskell: construction of the aliased type is restricted to the functions that are provided.

You are correct, there is no safety --- you can call the constructor std::string_view(const char, size_t) and stuff anything you want in there. The main reason string_view is nice is the implicit conversions you get from the other string types. Pass in a "const char*", it finds the terminating null for you. Pass in a std::string, no problem. No boilerplate.

There are mild benefits to having one value that represents both a size and an address. So you're passing around a pair of things that go together instead of just using convention.

But the real benefit is in providing it as a "vocabulary type". Once C++ code starts using string_view everywhere, you don't need to massage your char sequences this way and that [1] to pass it from the top of your application all the way down into the low-level libraries the application relies on. And you don't incur the overhead (both in lines of code and in copies) of all that massaging.

[1] Maybe your request handler has to convert from char* and size to a string to call your business logic, then your string has to convert from a string to a char pointer and and int length to call saveName. saveName might actually use std::copy under the hood to put the data into a chunk of memory, so it turns the pointer and length into two pointers.

- It has range semantics, so you can use it with standard algos or range for.

- It encodes the invariant in a type (char * points to at least size bytes, no expectation of null termination, no ambiguous definition of an empty range)

- The size always travel with the pointer so no chance that it gets separated.

- syntactically simple conversion from string (or other string-like entities) to string view reduces clutter in the code.

I consider lack of null termination a plus.

This is true as long as your implementation doesn't call any functions that take a `const string&`. If you need to call such a function, then you first have to make a copy of your string_view into a new string object before you call it.

Is there a way to do this without involving the overhead of a full copy, though?

Not that I'm aware of - a const std::string& parameter needs to be a reference to a std::string object, and there's no guarantee that a given string_view object is pointing to a std::string.

Whenever I'm working with substrings, I'm always nervous about bugs resulting from different encodings. I'm never comfortable with search for substrings or applying regular expressions or iterating over a string.

Encodings in general a bit of a headache. I work on Windows and it wants UTF-16 internally and everything external wants UTF-8.

Reply on news.ycombinator.com