短暂视图：在std::string_view的所有权中，性能优先于安全性

编程语言 2026-07-12

#include <string_view>
#include <iostream>

int main() {
    std::string_view sv = std::string("Hello") + " World"; 
    std::cout << sv << std::endl;
}

C++17引入 std::string_view，用以提供对字符数据的轻量级、非拥有引用。然而，语言允许将一个 prvalue（加法产生的临时字符串结果）赋给一个会在语句结束后仍然存在的视图。

既然编译器已经知道右侧是一个临时值，为什么语言设计成允许这种“静默悬空引用”，而不是强制对右值删除构造函数？这是否意味着在C++17中，「性能」被有意置于高于「类型安全」的位置，以致开发者成为主要的内存管理者，即使是对现代抽象也如此？

解决方案

值类别并不等同于生存期。

void use1(const std::string&);
void use2(std::string_view);
auto get() -> std::string;

use1(get()); // A. should this be allowed?
use2(get()); // B. or this?

两行都完全安全，A也是被允许的。当在语言中加入 std::string_view 时，你需要决定是否应允许B。它是安全的，并且有助于采纳诸如 use1 -> use2 这样的变更，这是我们想要鼓励的。

另一方面，和引用一样，它也可能被滥用。我们是否应该让它更难按我们希望的方式使用，以便也更难以在不合适的方式使用？

或者……我们是否应该把视图类型当作引用来对待，因此不要存储它们，并注意生存期？

我不会说这是在把性能放在类型安全之上。C++的类型系统不够丰富，无法表示生存期。是的，这也意味着开发者必须关注生存期。

C++