从 const std::string& 移动到 std::string_view 时的向后兼容性考虑？答案

【问题标题】：Backwards compatability considerations when moving from const std::string& to std::string_view?从 const std::string& 移动到 std::string_view 时的向后兼容性考虑？
【发布时间】：2020-02-04 01:17:50
【问题描述】：

我维护一个 C++ 库，该库经常在其 API 中使用 const std::string& 参数。但是，我收到了一些用户请求切换到 std::string_view 以帮助实现当前 API 无法实现的效率。

我正在考虑用std::string_view 简单地替换所有const std::string& 参数实例（可能通过验证std::string_view 可用的功能检查）。这会破坏我的任何用户的向后兼容性吗？我尝试了简单的替换，它似乎没有破坏我的代码或测试中的任何内容，但这当然不是一个详尽的检查。

^{我确实意识到这会破坏一些依赖于我的库的确切函数签名的代码。为了简单起见，假设我不允许用户依赖于我的函数的确切类型签名/参数。}

【问题讨论】：

您是否曾经依赖于您的参数当前是空终止的事实？
@Griwes 没有。不过很好。
只是指出：std::string_view 不允许从 nullptr 构造。
@Jovibor std::string 也没有？主要区别似乎是 std::string_view 在编译时失败，但 std::string 在运行时失败。我想如果人们在模板上玩太多花样，这可能会导致问题？
std::string_view 在运行时失败。

标签： c++ backwards-compatibility string-view

【解决方案1】：

我曾多次尝试在我自己的代码中将std::string const& 替换为std::string_view，但以下情况之一总是让我感到困惑：

std::string_view 从不拥有，因此如果您的任何基于 std::string 的代码出于生命周期的原因必须拥有字符缓冲区，则该部分代码无法转换为使用 std::string_view。这些问题可能很微妙，因此应格外小心。
基于第一点，任何需要所有权/std::string 使用的代码都意味着您在完全使用std::string_view 时可能获得的效率提升可能无法完全实现。
如果您依赖以空字符结尾的字符串，那么std::string_view 不是一个好的选择。密切注意可能需要char const* 参数的任何函数，其中隐含假设字符缓冲区以'\0' 结尾。

如果您可以保证满足上述所有条件，那么您可能会很好地进行 std::string 到 std::string_view 的迁移。

【讨论】：