从 const std::string& 到 std::string_view 的迁移时需要考虑向后兼容性吗？

Question

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

我考虑简单地将所有const std::string&参数的实例替换为std::string_view（可能还要进行功能检查以验证std::string_view是否可用）。这会破坏任何用户的向后兼容性吗？我尝试了简单的更改，并没有发现它会破坏我的代码或测试，但当然这并不是穷尽检查。

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

- user406009

---

你是否曾经依赖于参数当前是以 null 结尾的这个事实？ - Griwes

@Griwes 不是。不过你发现得很好。 - user406009

只是想指出：std::string_view 不允许从 nullptr 构造。 - Jovibor

@Jovibor std::string也不行吗？主要区别似乎在于std::string_view在编译时失败，而std::string在运行时失败。我猜如果人们在模板中玩弄太多技巧可能会导致问题？ - user406009

std::string_view 在运行时失败。 - Jovibor

Answer 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迁移。

- KyleKnoepfel