如果std :: string :: substr返回std :: string_view会存在什么弊端？

Question

看下面的例子（从这里获取）：

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失去一些兼容性-我并没有低估其重要性，我只是想知道是否存在其他缺陷）？

Answer 1

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

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()总是返回 a ，您也std::string_view可以想象这段代码会造成一些痛苦，即使只是在开发/调试期间。