背景
在日常的c/c++编程中，我经常需要传递数据，比如传递常量字符数据给函数，为了减少不必要的内存拷贝，c*系列编程中我们惯用方法是传递指针过去，如果非’\0’结尾的数据，我需要额外传递数据的长度给函数。
在c++17之前，为了解决上述问题，如leveldb封装了slice，其他项目封装了stringpice，stringslice， ngx_string_t等等，本质上，他们有共同的特点，通过保存指针和数据长度，在传递中使用这种数据结构避免数据拷贝，并通过封装相应的api，简化c风格字符串的操作。
c++17统一了以上的这些概念，将其命名为string_view,在标准库中提供。
abel基础库是以c++11作为运行基础的，提供了兼容c++17的string_view。
abel string_view
看下面一个例子
std::string string_cat(const std::string &a, const std::string &b);
std::string string_cat(const std::string &a, const char* b);
std::string string_cat(const char* a, const char* b);
std::string string_cat(const char* a, const std::string b);
在c++17以前，链接两个字符串，需要写四个函数完成上述操作。到具体的函数实现，难免要从const char* 转换到std::string，进而产生不不要的内存复制。
abel 推荐是用abel::string_view来接受和传递参数。使用abel::string_view形式如下：
std::string string_cat(abel::string_view a, abel::string_view b);
string_view可以从const char和const string&隐式构造而成。又因为string_view不会复制字符串，构造string_view不会有O(n)的内存代价。以const string&构造string_view时，构造函数时间复杂度为O(1)。以const char构造string_view时，构造函数会自动调用strlen()（或者你可以用双参形式的string_view构造函数）。
void AlreadyHasString(const string& s, const char* b) {
string_cat(s, b); // 没有显式类型转换；方便！
}
因为string_view不拥有其指向的数据，所以string_view（就像const char*）指向的字符串需要有超出该string_view的生存期。这意味着存储string_view总是需要问个问题：你得证明string_view指向的数据的生存期超出string_view的生存期
如果你的API只需要在单次函数调用中使用字符串数据，且不需要修改该字符串数据，（让函数（译者注））接收一个string_view就足够了。如果你需要修改数据或在以后访问数据，那么你需要用string(my_string_view)将string_view显式转换为C++字符串。
向现有代码库中添加string_view并不总是正确的事：如果在函数内需要将字符串以string或以NULL结尾的const char*传给下一级函数，那么将本级函数参数改为string_view可能会是低效的。对于string_view，推荐先在工具代码中采用，进而逐步向其调用端推广；或者在全新项目中统一使用string_view。
特别说明
与其他字符串类型不同，string_view应该像int或double那样按值传递（相对于按引用、指针传递，译者注），因为string_view对象本身只占用很小的内存。
-
string_view指向的字符串未必以NULL字符结尾。因此，如下的写法是不安全的：
printf("%s\n", sv.data()); // 别这样写
然而，如下写法是可以的：
printf("%.*s\n", static_cast<int>(sv.size()), sv.data());
- 你可以像打印string或const char*一样直接打印string_view：
std::cout << "Took '" << s << "'";
- 在大部分情况下，你可以安全地将现有函数的const string&或NULL结尾的const char*类型的形参直接转换为string_view。我们见过的唯一例外是，如果将函数地址赋值给某函数指针，那么会遇到“函数指针类型不匹配”的编译错误。
