C++ 更常用 string 还是 char* 呢？

整理了一些想法，抛砖引玉。

经验大多基于 C++17，工作中不需要对 C 暴露接口，偶尔会使用 C 库或者 C 风格的接口，在与 C 交互上是半吊子水平。

std::string_view 仅在 C++17 后才可用，对于没有条件的项目，可以考虑使用 Abseil 等三房库提供的 string_view 实现，但要留意第三方的实现和 std::string_view可能并不保证完全可互换。

字符串常量

首先是避免使用 std::string 定义常量，在我的工作环境甚至会被扫描工具拦截。不使用原因包括：

std::string 会引发堆内存分配；
std::string析构函数非平凡，全局对象销毁顺序难以预测，存在生命周期结束后被访问的风险（例如该 std::string 被其他全局对象引用）等。

近期搞的一些代码，大家习惯是使用 constexpr char[]：

constexpr char kMyConstString[] = "hello world";

使用 constexpr char[]本身没任何问题，只是很容易在调用中退化为 const char*，导致取字符串长度的复杂度变为 O(n)。为了避免计算长度的开销，调用参数需要一路都额外带一个 int 或者 size_t 的长度。

也见过一些其他代码使用 std::string_view：

constexpr std::string_view kMyConstString = "hello world";
constexpr auto kMyConstString = "hello world"sv;  // using namespace std::literals

std::string_view自带很多方法，自然比 constexpr char[]好用很多，也有 O(1) 的方法获取长度。

通过字面量字符串创建的 std::string_view 其内部数据是 NUL 结尾的，但是 NUL 字符在其 size() 之外，略有点怪怪的。但是一般意义上的 std::string_view 不保证是 NUL 结尾的，导致用起来总需要多留个心眼。这种区别可能会导致开发时拿到一个 std::string_view 后不知道该不该信任它有个 NUL 字符而会脑裂，同时也会给 reviewer 带来负担。

函数参数

遵循以下原则：

自底向上扩散
最底没有要求或必然无法自底一致时，优先考虑 std::string_view
若无特殊必要，避免 (const) char*，通常都可以使用 std::string_view替代

自底向上扩散，是指使用最底层第一个不可变（e.g. 别人的库）的调用参数作为参数类型传递。如果调用链靠下的部分是 const std::string& 这样的参数类型，那么直接保持 const std::string& 到你负责的最外层即可。底层决定了参数必然需要转换成为 std::string，假如调用链中间混进了 std::string_view，就会导致需要从 std::string_view转换 std::string，产生不必要的拷贝。

一个常见例子是，如果我的一个函数是查询一个 std::map<std::string, Foo>，这就决定了其查询 key 必然是 std::string 类型，查询的 find()函数接收 const std::string&，遵循 “自底向上扩散“ 原则，一路都应该是 const std::string&。也就不难发现，所有查 std::string 为 key 的关联容器的函数，其参数最好都是 const std::string&。如果是调用别人的接口，接口使用了 const std::string&，则也是同理。

有一个例外是，如果底层的 std::string 参数是值传递（而非引用、指针传递）的，例如：

void Foo(std::string s);

那么无论如何也都会拷贝一次，此时也可以用 std::string_view 做调用链传递。（但是，这种情况还是建议先看看是不是 Foo 的参数应该改成 const std::string& 才对的，我见过的九成是从其他语言转来的新手不知道引用，只有一成是函数内部计算过程中要修改输入作为临时状态，于是干脆用值参数来做零时变量的拷贝。）

在 std::string_view 和 const char* 之间，鉴于：

【const char*数据 + int/size_t长度】的组合可以和 std::string_view 低成本互转，不用担心发生数长度、拷贝；
std::string_view 可以低成本转 const char* ；
单独的 const char* 无法低成本转 std::string_view，需要数一次长度。

考虑到 std::string_view 用起来方便很多，通常在调用链上使用 std::string_view 是更好的。

只有一种特殊情况，如果调用链底层的接口比较奇特，只接收单独的 const char* （可能是写死了在内部数长度），并且调用参数来源也是个 const char* 不知为何也不带长度，那么遵循 “自底向上扩散” 原则效能最佳，调用链过程中避免多数一次长度。

（非静态）类成员变量

std::string 与 std::string_view 的最本质区别是，前者持有字符串数据所在内存的所有权，并负责管理其生命周期，而后置只是对内存中已有数据的引用。因而，仅在被引用字符串能够保证生命周期足够，且生命周期内不会被修改时，可以通过使用 std::string_view 保存其引用或其片段的引用。

由于类（或者说对象）通常都是各自管理自己的成员，会发现，上述使用 std::string_view 的条件在类成员变量中很难满足，就算见到，与其烧脑子梳理生命周期担心以后会不会别人改崩，还是在遇到性能瓶颈之前先用 std::string 是更保险的做法，不要用正确性换取性能。相比其他场合，类成员变量使用 std::string_view 通常风险高出很多。如果是我，甚至宁愿会优先考虑共享语义，例如 std::shared_ptr<std::string>，并在可能并发读写场合再加个锁。

临时变量

思路类似于（非静态）类成员变量，但类/对象通常承载了生命周期，而一个函数中的临时变量通常没有这种职责，因此相比之下，临时变量有更多的场合适合使用 std::string_view。

具体来说，如果函数调用，要么是同步无并发的，要么有只读并发且能保证被引用数据生命周期的，就可以使用 std::string_view 来引用数据。我倾向于仅在同步无并发的环境使用——并发环境冷不丁某一天可能就不是只读并发，或者生命周期有变化了。

在一些需要对字符串做算法处理的场合，例如很多字符串算法题，需要对字符串的字串进行递归操作，若使用 std::string 作为参数进行递归，不可避免有大量拷贝。屏幕前的看官可以翻翻 LeetCode提交记录，如果有使用 std::string 的递归，可以试着改成 std::string_view，对比一下运算时间和内存，通常优势是比较明显的。