问题标签 [string-view]

我发现来自新 C++17 标准的 string_view 有点多余。

我们有一个非常冗长的简单机制集合，用于将数据传递给被调用者，没有太多开销，现在还有一个也只针对一种容器类型。

我不明白为什么只为字符串提供这种机器，而不是为其他容器提供一些更通用的类型。一个明智的答案是我们已经有了这些解决方案。例如，在C++17 及以后的演示文稿中，string_view 被解释为observer_ptr<T> (or T*) for string.

请针对更通用的 container_view 陈述论点，与 C++17 引入的 string_view 形成对比。

在我之前的问题中，有人建议我的boost::spirit::x3解析器的性能可以通过解析为boost::string_view使用raw指令来提高。

但是，我很难编译它。这是我发现的：

• 之前x3，必须专门assign_to_attribute_from_iterators（参见例如this SO answer）来处理raw指令。

• x3现在改用move_tofree 函数（参见例如这个 SO answer）。

因此，我添加了一个move_to重载，如果我解析来自char*：

活生生的例子

但是，它不会编译：

1）如果我使用解析std::string::const_iterator

的构造函数boost::string_view需要 aconst char*或 a std::string&。

活生生的例子

如何实例化boost::string_viewfrom std::string::const_iterator？

2) Ifboost/spirit/home/x3.hpp包含在move_to重载之前

活生生的例子

为什么没有选择我的重载？它不是比中定义的任何一个更好的重载boost/spirit/home/x3/support/traits/move_to.hpp吗？无论包含顺序如何，我如何确保选择我的超载？

这是我之前关于boost::spirit::x3and的问题的后续问题boost::string_view。

虽然我可以解析为std::vector<std::string>（现场示例），但解析为std::vector<boost::string_view>失败并出现以下编译错误：

活生生的例子

我在这里想念什么？

我理解使用std::string_view的动机；
它可以帮助避免在函数参数中进行不必要的分配。

例如：
以下程序将从std::string字符串文字创建一个。
这会导致不希望的动态分配，因为我们只对观察字符感兴趣。

使用string_view将解决问题：

这给我留下了一个问题。
我什么时候会选择 std::string by const& 而不是 string_view 作为函数参数？

查看 的接口std::string_view，看起来我可以替换所有std::string通过的实例const&。这有什么反例吗？是std::string_view为了代替std::string const&参数传递吗？

在实现 C++1zstd::basic_string_view以在较旧的编译器上使用它时，我遇到了流输出运算符重载的问题。基本上，它必须输出由string_viewwhile 引用的内容，而不依赖于存在的任何空终止符（因为string_view不保证为空终止）。

通常，编写重载 foroperator<<非常容易，因为您可以依赖已经存在的重载，因此不需要使用SO 上这个问题中提到的哨兵对象。

但是在这种情况下，没有预定义的重载来operator<<获取字符指针和长度（显然）。因此，我std::string在当前的实现中创建了一个临时实例：

这行得通，但我真的不喜欢我必须创建一个临时实例的事实std::string，因为这需要冗余复制数据和动态内存的潜在使用。至少在我看来，这违背了使用轻量级引用类型的目的。

所以我的问题是：

在没有开销的情况下为我的 string_view 实现正确格式化输出的最佳方法是什么？

在研究时，我发现 LLVM 是这样做的：（在此处找到）

的实现__put_character_sequence驻留在这个文件中，但它大量使用内部函数来进行格式化。我需要自己重新实现所有格式吗？

std::string_view已经到了 C++17 并且被广泛推荐使用它而不是const std::string&.

原因之一是性能。

有人可以解释一下究竟 std::string_view是/将比const std::string&用作参数类型时更快吗？（假设在被调用者中没有复制）

我正在用不同的编译器玩std::string_view并注意到每个编译器在使用非空终止的 char 数组初始化std::string_view时打印出不同的大小。

似乎每个编译器在打开优化时都打印出正确的大小，但在关闭优化时打印出错误的大小（GCC 除外，它在两种情况下都打印出正确的大小）。

我的问题是：为什么会这样？

代码：

输出：Visual C++ 19.00.24619.0

输出：Clang 4.0.0-r282394（使用 MinGW-w64）

输出：GCC 6.2.0 (MinGW-w64)

在 C++ 中进行原型设计和玩耍时，尝试了一些概念来制作可识别 utf8 的不可变字符串，但我遇到了以下两难境地：

有什么方法可以返回字符串的不可变视图。就像，我希望能够返回一个引用原始字符串一部分的子字符串，而不是返回一个子字符串。

此代码具有未定义的行为：

原因是它std::string_view可以存储非空终止字符串，并且在调用时不包含空终止符data。这确实是限制性的，为了使上述代码定义的行为，我必须从中构造一个std::string：

在这种情况下，这确实是std::string_view不必要的，我仍然必须复制传递给的字符串foo，那么为什么不使用移动语义并更改msg为 astd::string呢？这可能会更快，但我没有测量。

无论哪种方式，std::string每次我想将 a 传递const char*给只接受 a 的函数时都必须构造 aconst char*有点不必要，但委员会这样决定肯定是有原因的。

那么，为什么不std::string_view::data返回一个以 null 结尾的字符串std::string::data呢？

是UB做以下事情吗？

谢谢！