如果 std::string::substr 返回 std::string_view 会有什么缺点？

Question

看这个例子（取自here）：

class foo {
    std::string my_str_;

public:
    std::string_view get_str() const {
        return my_str_.substr(1u);
    }
};

这段代码不好，因为substr返回一个临时的std::string，所以返回的std::string_view指的是一个已经被销毁的对象。但是，如果substr返回std::string_view，就不会存在这个问题了。

此外，如果substr 返回std::string_view 而不是std::string，对我来说似乎是合乎逻辑的，因为返回的字符串是字符串的视图，而且性能更高，因为没有复制。

如果substr 返回std::string_view 是否会有任何缺点（除了明显的缺点：失去与 C++14 的一些兼容性 - 我并没有低估这一点的重要性，我只是想知道是否还有其他缺点存在）？

相关问题：How to efficiently get a `string_view` for a substring of `std::string`

Answer 1

当string_view 被发明时，关于它是否应该存在的争论太多了。所有反对的论点都来自你展示的例子。

然而，就像我总是用这样的坏例子告诉大家：C++ 不是 Java，也不是 Python。 C++ 是一种低级语言，您几乎可以完全控制内存，我重复蜘蛛侠的陈词滥调：能力越大，责任越大。如果你不知道string_view 是什么，那就不要使用它！

你问题的另一部分有一个简单的答案，你自己回答了：

如果 substr 返回 std::string_view 会有什么缺点（除了明显的缺点：失去与 C++14 的一些兼容性）？

危害在于每个使用来自substr 的字符串副本的程序可能不再有效。向后兼容在计算机业务中是一件严肃的事情，这就是为什么英特尔的 64 位处理器仍然接受 x86 指令的原因，这也是它们没有倒闭的原因。重新发明轮子要花很多钱，而钱是编程的主要部分。因此，除非您打算将所有 C++ 都扔进垃圾箱并重新开始（就像 RUST 那样），否则您应该在每个新版本中保留旧规则。

您可以弃用某些东西，但要非常小心且非常缓慢。但弃用不像您建议的那样更改 API。

Answer 2

下面是一个具体的（如果稍微不完整的）代码示例，它当前是安全的，但会随着更改而变成未定义的行为：

std::string some_fn();
auto my_substr = some_fn().substr(3, 4);
// ... make use of my_substr ...

可以说，auto 的使用在这里有点可疑，但在以下情况下它是完全合理的（在我看来），重复类型名称几乎是多余的：

const char* some_fn();
auto my_substr = std::string(some_fn()).substr(3, 4);
// ... make use of my_substr ...

编辑：即使substr()总是返回std::string_view，你可以想象这段代码会造成一些痛苦，即使只是在开发/调试期间。

Answer 3

缺点很明显：这将是一个重大的 API 突破性变化，而 C++ 的每个版本都可以追溯到开始。

C++ 不是一种倾向于破坏 API 兼容性的语言。

Answer 4

一方面，c++ 字符串的底层数据结构与 c 字符串保持大部分兼容（可通过c_str() 成员访问）。 C 字符串以null 终止。所以你基本上只有一个起始 char 指针，并保持递增直到指针指向 0。

因此，子字符串可以从原始字符串的任意位置开始。但是，由于您不能只在原始字符串的某处插入 null，因此您的子字符串仍需要在与原始字符串相同的位置结束。

--编辑-- 正如 John Zwinck 所指出的，c++ 字符串可以包含 \0 字符，但这仍然意味着子字符串会丢失它们的 c_str 成员，因为它需要修改原始字符串。 string_view 的一个缺点在 Using std::string_view with api, what expects null terminated string 中也注意到了