如何解决 C++ std::string_view 范围外问题？

Question

In the following article under the section "Ownership Issues", it mentions that if someone sets up a std::string_view to look at a std::string variable then leaves the scope of that std::string, the std::string_view's behavior will be undefined.

https://www.learncpp.com/cpp-tutorial/6-6a-an-introduction-to-stdstring_view/

I understand that this is caused by the fact that the std::string variable is no longer in scope and "dies", so what's being viewed by the std::string_view is undefined. How would one work around this?

My current function does something to this effect:

std::string_view mergeIntoSV(std::string str1, std::string str2) {
  std::string new_str = str1 + str2;
  return std::string_view { new_str };
}

void callMerge() {
  std::string list[10];
  std::string_view views[5];
  //Assume some code that populates "list"...
  for (int i = 0; i < 10; i+=2) {
    views[i/2] = mergeIntoSV(list[i], list[i+1]);
  }
  //Now I want to be able to read each of the std::string_views.
}

However, after invoking this function elsewhere and then reading the contents of returned std::string_view, I (as the article suggests) read some undefined string value. Unfortunately I can't simply change the return type to std::string due to the fact that I'm working a larger codebase and required the return type to be as is.

How does one work around this out-of-scope problem?

Answer 1

You are creating an string object in a conceptually pure function (no state outside of the inputs/outputs). You then decided that this pure function should return a non-owning view of this object. This is a contradiction: a pure function cannot own state after the function has completed execution. And if the function doesn't own that state, and the return value doesn't own that state... the state doesn't exist.

You have only two options: return something that actually owns the string, or make the function non-pure by having it creating a string which outlives the function call (this could be through a static local, a global, or any number of things). The latter is almost always the wrong answer.

If some larger codebase required this operation, then that larger codebase has a design problem that needs to be resolved.

Answer 2

A string view isn't magical: Essentially, it's just a pointer to the start of the string, and its length. Just like you wouldn't return a pointer to a local variable, you wouldn't return an std::string_view to a local string. It's that simple.

The "solution" is the same as for pointers:

• If the (string) object should be local - don't return a pointer (string view) to it.
• If the (string) object lifetime should to extend the lifetime - either:
  • return by value (there's guaranteed return-value copy elision and NRVO ), or
  • create a buffer through, say, an std::unique_ptr , and then move-return it, or
  • pass a buffer to work with as input, and use that for your string data.