从一系列字符构造一个string_view

问题描述

虽然span可以从一个范围构造，但是string_view不能从一个字符范围构造。

因此，例如，以下代码是必需的：

// assume chars_span is a span of chars
std::cout << std::string_view(chars_span.data(),chars_span.size());
// or:
std::cout << std::string_view(chars_span.begin(),chars_span.end());

代替了不受支持的更简单的范围语法：

std::cout << std::string_view(chars_span);

是否有理由没有为string_view提供一个接受一定范围字符的构造函数，还是只是被忽略或认为不够重要？

解决方法

P1391r3提出了这个建议，尽管最终在C ++ 20最终采用的版本中删除了该建议：P1391r4。不幸的是，纸张上完全没有该纸张掉落的原因（实际上，该纸张甚至没有提到它已被丢弃）。

但是，后续论文P1989R0提出了这样的问题：如果我们使用这样的类型（我稍微修改了示例），会发生什么：

struct buffer {
    buffer() {};
    char const* begin() const { return data; }
    char const* end() const { return data + 42; }
    operator string_view() const {
        return string_view(data,data + 2);
    }
private:
    char data[42];
};

此处，buffer可转换为string_view。但是将其转换为string_view的方式与string_view的范围构造器执行此操作的方式不同（前者给您两个字符，后者给您42个字符）。据我所知，实际上没有人指出这种类型的存在。

尽管如此，方向是确保这些类型继续有效，因此新论文针对该特定构造函数具有一组更为复杂的约束。

---

一个更有趣的例子是：

using ci_string = std::basic_string<char,case_insensitive_traits>;

ci_string value = "Hello";
std::string_view sv = value;

任何一种简单的基于范围的推理都将允许从ci_string到std::string的转换。 ci_string是char的一个很好的连续范围，没有像以前的buffer类型那样的怪异转换问题。但是，尽管ci_string应该可以转换为basic_string_view<char,case_insensitive_traits>，但我们可能不想避免将其转换为普通的string_view。这不太可能实现，因此我们需要对此加以防范。

与buffer案例相比，此案例对我而言更具激励作用。