c++ - 如果 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 对我来说似乎合乎逻辑，因为返回的字符串是字符串的 View ，它的性能更高，因为没有进行复制。

如果 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 是什么，请不要使用它!

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

Would there be any drawbacks if substr returned std::string_view (besides the obvious drawback: losing some compatibility with C++14)?

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

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