std::string& vs boost::string_ref

The use case for string_ref (or string_view in recent Boost and C++17) is for substring references.

The case where

• the source string happens to be std::string
• and the full length of a source string is referenced

is a (a-typical) special case, where it does indeed resemble std::string const&.

Note also that operations on string_ref (like sref.substring(...)) automatically return more string_ref objects, instead of allocating a new std::string.

This answer uses the new name string_view to mean the same as string_ref.

What really confuses me is the fact that std::string is also a handle class that only points to the allocated memory

A string allocates, owns, and manages its own memory. A string_view is a handle to some memory that was already allocated. The memory is managed by some other mechanism, unrelated to the string_view.

If you already have some text data, for example in a char array, then the additional memory allocation involved in constructing a string might be redundant. A string_view could be more efficient because it would allow you to operate directly on the original data in the char array. However, it would not permit the data to be modified; string_view allows no non-const access, because it doesn't own the data it refers to.

and since c++11, with move semantics the copy operations noted in the article above are not going to happen.

You can only move from an object that is ready to be discarded. Copying still serves a purpose and is necessary in many cases.

The example in the article constructs two new strings (not copies) and also constructs two copies of existing strings. In C++98 the copies could already be elided by RVO without move semantics, so they're not a big deal. By using string_view it avoids constructing the two new strings. Move semantics are irrelevant here.

In the call to extract_part("ABCDEFG") a string_view is constructed which refers to the char array represented by the string literal. Constructing a string here would have involved a memory allocation and a copy of the char array.

In the call to bar.substr(2,3) a string_view is constructed which refers to parts of the data already referred to by the first string_view. Using a string here would have involved another memory allocation and copy of part of the data.

So, which one is more efficient?

This is a bit like asking if a hammer is more efficient than a screwdriver. They serve different purposes, so it depends what it is you're trying to accomplish.

You need to be careful when using string_view that the memory it refers to remains valid throughout its lifetime.

If you stick to std::string it does not matter, but boost::string_ref also supports const char*. That is, do you intend to call your string processing function foo with std::string only?

void foo(const std::string&); foo("won't work"); // no support for `const char*` 

Since boost::string_ref is constructable from const char*, it is more flexible since it works with both const char* and std::string.

The proposal N3442 might be helpful.

In short: The main benefit of std::string_view over const std::string& is that you can pass both const char* and std::string objects without doing a copy. As others have said, it also allows you to pass substrings without copying, although (in my experience) this is somewhat less often important.

Consider the following (silly) function (yes I know you could just call s.at(2)):

char getThird(std::string s) { if (s.size() < 3) throw std::runtime_error("String too short"); return s[2]; } 

This function works, but the string is passed by value. This means the whole length of the string is copied even though we don't look at all of it, and it also (often) incurs a dynamic memory allocation. Doing this in a tight loop can be very expensive. One solution to this is to pass the string by const reference instead:

char getThird(const std::string& s); 

This works a lot better if you have a std::string variable and you pass it as a parameter to getThird. But now there's a problem: what if you have a null-terminated const char* string? When you call this function, a temporary std::string will get constructed, so you still get still get the copy and dynamic memory allocation.

Here's another attempt:

char getThird(const char* s) { if (std::strlen(s) < 3) throw std::runtime_error("String too short"); return s[2]; } 

This will obviously now work fine for const char* variables. It will also work for std::string variables, but calling it is a little awkward: getThird(myStr.c_str()). What's more, std::string supports embedded null characters, and getThird will misinterpret the string as ended at the first of these. At worst this could cause a security vulnerability - imagine if the function were called checkStringForBadHacks!

Another problem is simply that it's annoying to write a function in terms of old null-terminated strings instead of std::string objects with their handy methods. Did you notice, for example, that this function looks at the whole length of the string even though only the first few characters are important? It's hidden in std::strlen, which iterates over all characters looking for the null terminator. We could replace that with a manual check that the first three characters aren't null, but you can see this is a lot less convenient than the other versions.

Step in std::string_view (or boost::string_view, previously known as boost::string_ref):

char getThird(std::string_view s) { if (s.size() < 3) throw std::runtime_error("String too short"); return s[2]; } 

This gives you the nice methods you expect from a proper string class, like .size(), and it works in both the situations discussed above, plus another:

• It works with std::string objects, which can be implicitly be converted to std::string_view objects.
• It works with const char* null-terminated strings, which can also be implicitly be converted to std::string_view objects.
  • This does have the potential disadvantage that constructing the std::string_view requires iterating over the whole string to find the length, even if the function that uses it never needs it (as is the case here). However, if a caller is using a const char* as a parameter to several functions (or one function in a loop) that take std::string_view objects it could always manually construct that object beforehand. This could even give a performance increase, because if that function(s) do need the length then it is precomputed once and reused.
• As other answers have mentioned, it also avoids a copy when you only want to pass a substring. For example, this is very useful in parsing. But std::string_view is justified even without this feature.

It's worth noting that there is a case where the original function signature, taking a std::string by value, may actually be better than a std::string_view. That's where you were going to make a copy of the string anyway, for example to store in some other variable or to return from the function. Imagine this function:

std::string changeThird(std::string s, char c) { if (s.size() < 3) throw std::runtime_error("String too short"); s[2] = c; return s; } // vs. std::string changeThird(std::string_view s, char c) { if (s.size() < 3) throw std::runtime_error("String too short"); std::string result = s; result[2] = c; return result; } 

Note that both of these involve exactly one copy: In the first case this is done implicitly when the parameter s is constructed from whatever is passed in (including if it is another std::string). In the second case we do it explicitly when we create result. But the return statement does not do a copy, because uses move semantics (as if we had done std::move(result)), or more likely uses the return value optimisation.

The reason the first version can be better is that it is actually possible for it to perform zero copies, if the caller moves the argument:

std::string something = getMyString(); std::string other = changeThird(std::move(something), "x"); 

In this case, the first changeThird does not involve any copy at all, whereas the second one does.