如何有效地为 `std::string` 的子字符串获取 `string_view`

How to efficiently get a `string_view` for a substring of `std::string`

使用http://en.cppreference.com/w/cpp/string/basic_string_view作为参考,我认为没有办法更优雅地做到这一点:

std::string s = "hello world!";
std::string_view v = s;
v = v.substr(6, 5); // "world"

更糟糕的是,天真的方法是一个陷阱,它会留下 v 对临时对象的悬空引用:

std::string s = "hello world!";
std::string_view v(s.substr(6, 5)); // OOPS!

似乎记得 标准库中可能添加了一个 return 子字符串作为视图:

auto v(s.substr_view(6, 5));

我可以想到以下解决方法:

std::string_view(s).substr(6, 5);
std::string_view(s.data()+6, 5);
// or even "worse":
std::string_view(s).remove_prefix(6).remove_suffix(1);

坦率地说,我认为这些都不是很好。现在我能想到的最好的事情就是使用别名来简单地使事情不那么冗长。

using sv = std::string_view;
sv(s).substr(6, 5);

有自由函数路线,但除非您还为 std::string 提供重载,否则它就是蛇坑。

#include <string>
#include <string_view>

std::string_view sub_string(
  std::string_view s, 
  std::size_t p, 
  std::size_t n = std::string_view::npos)
{
  return s.substr(p, n);
}

int main()
{
  using namespace std::literals;

  auto source = "foobar"s;

  // this is fine and elegant...
  auto bar = sub_string(source, 3);

  // but uh-oh...
  bar = sub_string("foobar"s, 3);
}

恕我直言,string_view 的整个设计是一场恐怖表演,它将把我们带回到一个充满段错误和愤怒客户的世界。

更新:

甚至为 std::string 添加重载也是一场恐怖表演。看看你是否能发现微妙的段错误定时炸弹...

#include <string>
#include <string_view>

std::string_view sub_string(std::string_view s, 
  std::size_t p, 
  std::size_t n = std::string_view::npos)
{
  return s.substr(p, n);
}

std::string sub_string(std::string&& s, 
  std::size_t p, 
  std::size_t n = std::string::npos)
{
  return s.substr(p, n);
}

std::string sub_string(std::string const& s, 
  std::size_t p, 
  std::size_t n = std::string::npos)
{
  return s.substr(p, n);
}

int main()
{
  using namespace std::literals;

  auto source = "foobar"s;
  auto bar = sub_string(std::string_view(source), 3);

  // but uh-oh...
  bar = sub_string("foobar"s, 3);
}

编译器在这里没有发现任何警告。我确信代码审查也不会。

我已经说过了,我再说一遍,以防 c++ 委员会的任何人在看,允许从 std::stringstd::string_view 的隐式转换是一个可怕的错误,只会让 c++ 声名狼藉

更新

在 cpporg 留言板上提出这个(对我来说)相当令人震惊的 属性 的 string_view,我的担忧得到了冷漠的回应。

这个小组的一致意见是 std::string_view 绝不能从函数中 return 编辑,这意味着我上面的第一个提供是错误的形式。

当然没有编译器帮助捕捉意外发生的时间(例如通过模板扩展)。

因此,std::string_view的使用应格外小心,因为从内存管理的角度来看,它等同于指向另一个对象状态的可复制指针,该对象可能不再存在.但是,它在所有其他方面的外观和行为都像值类型。

因此代码如下:

auto s = get_something().get_suffix();

get_suffix() return 是 std::string 时是安全的(按值或引用)

但是如果 get_suffix() 被重构为 return a std::string_view.

就是 UB

这在我看来意味着任何使用 auto 存储 returned 字符串的用户代码都会中断,如果他们调用的库被重构为 return std::string_view 代替 std::string const&.

所以从现在开始,至少对我来说,“几乎总是自动”必须变成“几乎总是自动,除非是字符串”。

您可以使用从 std::stringstd::string_view:[=11= 的转换运算符]

std::string s = "hello world!";
std::string_view v = std::string_view(s).substr(6, 5);

这就是您高效创建子字符串的方法 string_view。

#include <string>
inline std::string_view substr_view(const std::string& source, size_t offset = 0,
                std::string_view::size_type count = 
                std::numeric_limits<std::string_view::size_type>::max()) {
    if (offset < source.size()) 
        return std::string_view(source.data() + offset, 
                        std::min(source.size() - offset, count));
    return {};
}

#include <iostream>
int main(void) {
  std::cout << substr_view("abcd",3,11) << "\n";

  std::string s {"0123456789"};
  std::cout << substr_view(s,3,2) << "\n";

  // be cautious about lifetime, as illustrated at https://en.cppreference.com/w/cpp/string/basic_string_view
  std::string_view bad = substr_view("0123456789"s, 3, 2); // "bad" holds a dangling pointer
  std::cout << bad << "\n"; // possible access violation

  return 0;
}

我意识到这个问题是关于 C++17 的,但值得注意的是 C++20 引入了一个 string_view 构造函数,它接受两个迭代器到 char(或任何基本类型),这允许写作

std::string_view v{ s.begin() +6, s.begin()+6 +5 };

不确定是否有更简洁的语法,但不难

#define RANGE(_container,_start,_length) (_container).begin() + (_start), (_container).begin() + (_start) + (_length)

决赛

std::string_view v{ RANGE(s,6,5) };

PS:我调用 RANGE 的第一个参数 _container 而不是 _string 的原因是:该宏可以与任何容器(或​​ class 至少支持 begin()end()),甚至作为像

这样的函数调用的一部分
auto pisPosition= std::find( RANGE(myDoubleVector,11,23), std::numbers::pi );

PPS:如果可能,更喜欢 C++20 的 actual 范围库而不是这个可怜人的解决方案。