问题标签 [string-view]

我试图在 C++ 中以最快的方式拆分字符串。我在这里收到一个错误：

Visual Studio 说：cannot convert from 'const char *' to 'const std::_String_const_iterator<std::_String_val<std::_Simple_types<char>>>'

你能帮我吗，我应该在visual studio中启用任何选项来让它工作吗？

string_view是添加到 C++17的 C++ 库基础 TS( N3921 ) 中的一项提议功能

据我了解，它是一种代表某种字符串“概念”的类型，它是任何类型的容器的视图，可以将可视内容存储为字符串。

• 这是正确的吗 ？
• 规范 const std::string&参数类型应该变成string_view?
• 还有一个重要的点string_view要考虑吗？

我只是遇到了一些误解：至少在 libc++ 实现中 std::experimental::string_view 有以下简洁的实现：

这个实现是否意味着如果我们将右值表达式传递给这个构造函数，我们将在构造后使用 __data 时得到未定义的行为？

假设我有一个const string&作为输入的函数，例如：

然后我有一个内部缓冲区const char* buffer;，我知道它的大小。

我想如果我创建内联字符串，仍然会发生一个副本：

但是没有必要复制缓冲区，因为所有东西都是不变的，我只需要字符串类的功能而不是它创建的缓冲区。

我必须提到，我不确定是否发生了复制，但是查看字符串的构造函数，他们都说会发生复制。我不知道编译器优化能否理解这种情况，我也找不到方法来确定是否发生了复制。

有什么方法可以为字符串使用外部缓冲区，或者至少有一种方法可以确保复制发生与否。我目前正在使用 std 字符串和 c++11。

假设我std::vector<std::string>在一个类中有一个成员变量，并且我想使用gsl::array_view和的组合从成员函数将其作为不可变视图返回gsl::cstring_view。不幸的是，以下内容无法编译：

原因是没有可以从中创建cstring_view的容器。array_view所以我的问题是：有没有一种方法可以在不显式添加类似 type 的成员的情况下使用这样的构造std::vector<gsl::cstring_view<>>，这显然是不可取的？

编辑

在我看来，这种“转变”的观点可能更普遍。考虑拥有一个vector拥有指针，例如std::vector<std::shared_ptr<T>>，我想将其作为一个array_view原始指针公开给类的用户：gsl::array_view<const T*>而不公开我的实现定义的存储方法。想法？

boost 中的 string_ref 和 GSL 中的 string_span 都没有定义采用一对迭代器的构造函数。这个决定的原因是什么？

通常这没什么大不了的，我可以像这样创建 string_ref ：

但我想要采用一对迭代器的构造函数的原因是因为我的代码如下所示：

目前，我可以这样称呼它：

我想将其更改为：

但是该代码无法编译，因为缺少构造函数在 string_ref 中采用一对迭代器

我不是 100% 认为以下代码在语义上是正确的：

Live on Wandbox

问题：我可以合法地将右值绑定到std::experimental::basic_string_view，还是只是 UB？如果是，它是如何工作的？据我所知，右值不会const通过构造函数绑定到引用（我假设视图保留原始字符串），所以我认为在语句结束时std::experimental::string_view view_rvalue(std::string{"rvalue string"});引用将悬空。是否string_view使用更复杂的方法？

我问这个是因为我正在尝试为某些矩阵类编写类似的视图，但还不知道如何处理右值（我当然可以禁用它们，但我认为这不是最好的方法）。

以下代码无法在最近的编译器（g++-5.3、clang++-3.7）上构建。

clang 返回的错误：

但是不find应该能够使用可比较的类型吗？Cppreference 提到了以下重载：

template< class K > iterator find( const K& x );

同样的错误发生在boost::string_ref.

Boost 提供了两种不同的实现string_view，它们将成为 C++17 的一部分：

• boost::string_ref在utility/string_ref.hpp
• boost::string_view在core/string_view.hpp

这些之间有什么显着差异吗？未来应该首选哪个？

注意：我注意到在 Boost 1.61 中， boost::log 已弃用 string_ref 以支持 string_view；也许这是一个指标？（http://www.boost.org/users/history/version_1_61_0.html）

似乎 C++17 string_view 的std::hash 函数不是 constexpr 的。

在我看来，绑定到 const char[] 的字符串视图可以在编译时进行散列（这会非常好），或者有什么可以防止这种情况发生吗？