string_view
是添加到 C++17的 C++ 库基础 TS( N3921 ) 中的一项提议功能
据我了解,它是一种代表某种字符串“概念”的类型,它是任何类型的容器的视图,可以将可视内容存储为字符串。
- 这是正确的吗 ?
- 规范
const std::string&
参数类型应该变成string_view
? - 还有一个重要的点
string_view
要考虑吗?
string_view
是添加到 C++17的 C++ 库基础 TS( N3921 ) 中的一项提议功能
据我了解,它是一种代表某种字符串“概念”的类型,它是任何类型的容器的视图,可以将可视内容存储为字符串。
const std::string&
参数类型应该变成string_view
?string_view
要考虑吗?任何和所有类型的“字符串引用”和“数组引用”提案的目的是避免复制已经在其他地方拥有的数据,并且只需要非变异视图。有string_view
问题的就是这样一个提议;也有更早的称为string_ref
and array_ref
。
这个想法总是存储一对指向第一个元素的指针和一些现有数据数组或字符串的大小。
这样的视图句柄类可以通过值廉价地传递,并提供廉价的子字符串操作(可以实现为简单的指针增量和大小调整)。
字符串的许多用途不需要实际拥有字符串,并且相关字符串通常已经由其他人拥有。因此,通过避免不需要的副本(想想您可以保存的所有分配和异常),确实有提高效率的潜力。
strtok
原始的 C 字符串存在空终止符是字符串 API 的一部分的问题,因此如果不改变底层字符串 (a la ) ,就无法轻松创建子字符串。在 C++ 中,这很容易通过单独存储长度并将指针和大小包装到一个类中来解决。
我能想到的与 C++ 标准库哲学的一个主要障碍和分歧是,这种“引用视图”类与标准库的其余部分具有完全不同的所有权语义。基本上,标准库中的所有其他内容都是无条件安全和正确的(如果它编译,它就是正确的)。对于像这样的参考类,这不再是真的。程序的正确性取决于使用这些类的环境代码。所以这更难检查和教导。
(2021年自学)
来自微软的<string_view>:
string_view 系列模板特化提供了一种有效的方法来将只读的、异常安全的、非拥有句柄传递给序列的第一个元素在位置零的任何类似字符串的对象的字符数据。(...)
来自 Microsoft 的 C++ 团队博客std::string_view:2018 年 8 月 21 日的字符串类型的管道胶带(2021 年 4 月 1 日检索):
string_view 解决了参数的“每个平台和库都有自己的字符串类型”问题。它可以绑定到任何字符序列,因此您可以将函数编写为接受字符串视图:
void f(wstring_view); // string_view that uses wchar_t's
并调用它而不关心调用代码正在使用什么类似字符串的类型(并且 > for (char*, length) 参数对只需在它们周围添加 {})(...)
(...)
今天,用于传递字符串数据的最常见的“最小公分母”是以空字符结尾的字符串(或标准所称的空字符字符类型序列)。这早在 C++ 之前就已经存在,并提供了干净的“平面 C”互操作性。但是,char* 及其支持库与可利用的代码相关联,因为长度信息是数据的带内属性并且容易被篡改。此外,用于定界长度的空值禁止嵌入空值,并导致最常见的字符串操作之一(要求长度)与字符串长度成线性关系。
(...)
每个编程领域都有自己的新字符串类型、生命周期语义和接口,但是很多文本处理代码并不关心这些。分配数据的整个副本来处理只是为了让不同的字符串类型满意,这对于性能和可靠性来说是次优的。