我在 C++ 项目中使用了一些 C 遗留代码。

使用过的 C 函数看起来像这样

现在当我像这样从 C++ 代码调用这个函数时

我收到编译器警告 ISO C++ 禁止将字符串转换为字符。所以为了摆脱这个，我想用 string_view 创建一个 c++ 包装器，以避免对我的字符串进行不必要的处理

现在，如果我正确理解引用 string_view 不一定包含终止空字符，对于所有 c 函数都是必不可少的，因为它不拥有字符串对象。它只是显示它。

但是，我可以假设在我的特定情况下 string1 和 string2 是空终止的吗？

std::string_view使用临时初始化 a 是一个常见的错误std::string。

那是因为"bar"s, 临时, 在full-expressionstd::string结束时被销毁。

但是怎么样"foo"sv？

当然这应该可行，因为后缀sv在其他情况下是无用的。但这与 有何根本不同"baz"s？也就是说，为什么引入的字符串"baz"sv不会过期？

Assume we have a simple getter method in a class that returns a const reference to a std::string member:

With the advent of std::string_view in C++17, I wonder whether it has any advantages of writing this instead:

Does one method have advantages/disadvantages over the other? Clearly (correct me if I'm wrong) both solutions will definitely be better than this:

I've seen this related question, but I'm asking for something slightly different.

考虑一个从返回 astd::string_view的方法const std::string&或从空字符串返回 a 的方法。令我惊讶的是，以这种方式编写方法会导致悬空字符串视图：

https://godbolt.org/z/1Hu_p2

似乎编译器首先将std::string结果的临时副本otherMethod()放在堆栈上，然后返回此临时副本的视图，而不是仅返回引用的视图。首先我想到了一个编译器错误，但是 G++ 和 clang 都这样做了。

修复很简单：包装otherMethod成显式构造string_view解决了这个问题：

https://godbolt.org/z/Q-sEkr

为什么会这样？为什么原始代码会在没有警告的情况下创建隐式副本？

有没有一种安全的标准转换std::string_view方式int？

由于 C++11std::string允许我们使用stoi转换为int：

但stoi不支持std::string_view。因此，或者，我们可以使用atoi，但必须非常小心，例如：

所以atoi也不起作用，因为它基于空终止符'\0'（例如sv.substr不能简单地插入/添加一个）。

现在，由于 C++17 还有from_chars，但在提供不良输入时似乎不会抛出：

介绍

我正在编写一些通信应用程序。在 C++17（没有 Boost）之前，我使用std::string和它的 const 引用作为cls1.

从 C++17 开始，我将std::string_view我的代码介绍为cls2. 但是，我没有明确的政策何时应该使用std::string_view. 我的通信应用程序从网络接收数据并将其存储到recv_buffer. 并从recv_buffer.

建造

如果我只关注cls1' 的构造函数，则移动构造是有效的。但我认为参数s来自哪里。如果它最初来自recv_buffer，我可以std::string_view在接收（很早）点创建。并在recv_buffer's 生命周期内启用，std::string_view随处使用。如果我需要存储部分recv_buffer然后创建std::string.

我注意到的唯一例外recv_buffer是始终包含我的应用程序类的完整数据。在这种情况下，移动构造是有效的。

吸气剂

我认为使用返回类型 asstd::string_view具有优势。一些成员函数例如substr()是有效的。但到目前为止，我没有看到任何缺点。

问题

我怀疑我可能只看到std::string_view. 在重写许多代码之前，我想知道你的想法。

PoC 代码

运行演示：https ://wandbox.org/permlink/TW8w3je3q3D46cjk

我有一个 C++ 应用程序，它具有多年开发的深度、精致的逻辑。遗憾的是，它结合了各种不同类型的字符串：std::string、C 字符串、Pascal 字符串和操作系统/平台特定的字符串。此外，这些字符串类型中的每一种都经常使用各种编码。

我创建了一个包装类 WBString，它包含一个 std::string，并且可以从我预先存在的近十种字符串中构造。

但是，我希望底层实现能够使用 std::string_view。如果我从已经是 const 的源字符串构造，则在初始化和传递我的类时，std::string_view 可以节省所有形式的幕后构造。

看起来好像 C++17 的 std::string_view 可以简单地尝试与 std::string 更好地集成，但我想这可能会破坏现有的应用程序。

我可以看到很多这样做的方法：

1) 将我的 WBString 类模板化以保存一个 std::string 用于非常量函数和一个单独的 WBStringView 用于 const 字符串；

2）创建一个没有数据的基类和两个独立的继承类：WBString / WBStringView；

3) 有一个包含 std::string 和 std::string_view 作为数据成员的类；

4) 保留一个可以是任一类型的 void* 数据成员。

以前有人必须面对这个问题吗？

每个[string.view.synop]：

只有四个“common”basic_string_view是hash启用的特化。其他basic_string_views 的hashes 被禁用。

根据[unord.hash]/2：

[...] 对于Key库和用户都没有提供类模板的显式或部分特化的 任何类型hash，hash<Key>被禁用。

根据[unord.hash]/4：

如果H是 的禁用特化hash，则这些值为 false： is_­default_­constructible_­v<H>、is_­copy_­constructible_­v<H>、 is_­move_­constructible_­v<H>、is_­copy_­assignable_­v<H>和 is_­move_­assignable_­v<H>。禁用的特化hash不是函数对象类型。[注意：这意味着 hash 的特殊化存在，但任何将其用作 a 的尝试都是错误Hash 的。— <em>结束注释]

因此，以下 Minimal Reproducible Example 不应编译，因为它尝试默认构造 的禁用特化hash：

但是，这在 Clang 8.0.0 上编译得很好。挖掘 libc++ 的源代码，我们看到：

所以 libc++ 实际上hash为所有basic_string_views 启用。

因此，我断定这是 libc++ 中的一个错误。我的分析正确吗？

我正在尝试使用现代字符串处理方法（如std::string_view或GSL'sstring_span）与将字符串作为空终止的 C API（DBus）进行交互const char*，例如

string_view并且string_span不保证它们的内容是空终止的——因为跨度是(char* start, ptrdiff_t length)对的，这在很大程度上是重点。但是 GSL 也提供了一个zstring_view，它保证是空终止的。周围的评论zstring_span表明它是专为处理遗留 API 和 C API 而设计的，但我一开始使用它就遇到了几个症结：

1. 将字符串文字表示为 astring_span很简单：

   但是将一个表示为 azstring_span需要您将文字包装在辅助函数中：

   这使得声明更加嘈杂，而且文字（保证以 null 结尾）不能隐式转换为 a 似乎也很奇怪zstring_span。ensure_z()也不是constexpr，不像string_span.

2. 有一个类似的奇怪之处std::string，它可以隐式转换为string_span，但不是zstring_span，尽管std::string::data()自 C++11 以来已保证返回一个以空值结尾的序列。同样，您必须致电ensure_z()：

   /li>

3. 似乎存在一些 const 正确性问题。上述工作，但

   编译失败，出现关于无法转换为的span<char, ...>错误span<const char, ...>

4. 这一点比其他点小，但返回 a 的成员函数char*（您可以将其提供给像 DBus 这样的 C API）被调用assume_z()。当构造函数期望一个以空值结尾的范围时，会假设什么？zstring_span

如果zstring_span设计为“将零终止跨度转换为遗留字符串”，为什么在这里使用它看起来如此麻烦？我在滥用它吗？有什么我忽略的吗？

我知道琐碎std::string_view的事情不能保证以空值结尾。但是，我不知道是否std::string_view保证文字以空值结尾。

例如：

C++17 或更高版本是否保证以my_sv.data()空值结尾？

===下面更新了===

以下所有内容均来自n4820：

1. 根据 5.13.5.14，字符串文字以空值结尾。
2. 根据 5.13.8，用户定义的字符串文字由字符串文字加上自定义后缀组成。说，，"hello"sv是hello字符串文字，sv是后缀。
3. 按照 5.13.8.5，"hello"sv被视为按照operator "" sv(str, len);5.13.5.14形式的调用，以str空值终止。
4. 根据 21.4.2.1，sv必须data()返回str。

他们能证明"hello"sv.data()C++ 标准保证它是空终止的吗？