为何std::string_view未采用替代实现？能否优化其失效问题？

先看问题重现的代码：

#include <iostream>
#include <cassert>
#include <string>

using std::cout;
using std::endl;

int main() {
    std::string s = "hi";
    std::string_view v = s;

    cout << v << endl;

    s = "this is a long long long string now";

    cout << v << endl;
}

输出结果：

hi
#

这个问题的本质是：std::string_view仅存储指向字符序列的指针和长度，不会跟踪原字符串的内存变化。当std::string的内容超过SSO（小字符串优化）阈值时，它会把内容迁移到堆内存，原内存地址失效，此时string_view持有的指针就指向了无效内存，访问会导致未定义行为。

能不能打造更智能的std::string_view？ #

基于现有std::string的实现，理论上可以设计一个绑定到std::string的"智能视图"，但存在几个关键问题，导致标准库不会采用这种方案：

• 失去轻量性：std::string_view的核心设计目标是零开销，仅占用两个指针的大小。如果改成存储std::string的指针，每次访问视图都要间接从原string获取最新的字符地址和长度，会带来额外的性能开销，违背了它的设计初衷。
• 通用性丧失：std::string_view的优势在于能兼容C风格字符串、字符串字面量、char数组等多种字符序列。如果限制它只能绑定std::string，就无法处理这些非std::string的场景，适用范围大幅缩小。
• 线程安全与竞态风险：如果原std::string在其他线程被修改，智能视图的访问会出现竞态条件，而原生string_view因为不跟踪状态，不存在这个问题。

替代解决方案 #

如果需要避免这种失效问题，可以参考以下做法：

• 避免在修改原字符串后使用视图：如果必须修改std::string，要么在修改前不再使用对应的string_view，要么修改后重新生成string_view。
• 提前预留足够空间：通过std::string::reserve()提前分配足够的内存，避免后续扩容导致的内存迁移。
• 直接使用string引用或拷贝：如果需要长期跟踪字符串内容，直接持有std::string的引用（注意生命周期），或者拷贝一份独立的字符串，而不是使用视图。

内容的提问来源于stack exchange，提问作者PYA