std::string，以下简称string，最突出的缺点就是不考虑字符编码，或者更确切地说，就是unicode编码好了。字符串类型怎么可以没有编码信息呢？很多字符串的操作运算，都离不开字符编码的参与，现在好了，既然字符串本身就缺乏编码信息，自然也就没法对这些字符串函数做文章了，因此string的功能就弱得可怜了。
1.StringPiece
什么是StringPiece？
Astring-likeobjectthatpointstoasizedpieceofmemory
说白了就是string的只读视图，为了便于解释，直接来看代码吧：
const限定了函数func没法修改入参str，但是如果给传递的参数是char*或者constchar*，那么将构造一个临时的std::string，并且产生了字符串的拷贝，但是显然这次拷贝并没有必要。StringPiece就是在这种情况去替换std::string，可以避免字符串拷贝，因为StringPiece只是简单接管一下指针，看一下StringPiece的简单实现就知道了，这里以leveldb中的Slice为例子，看一下其构造函数就明白了
其次，string的配套设施很孱弱，作为一个被QString宠坏的人，我想说stdstring几个缺点：
1.缺少完备设施。例如split，starstWith等函数，这个好办，自己封装一套。生成新的字符串，比如格式化，比如其他类型的变量转化为字符串，……；
2.缺少编码信息。stdstring是一个charvector，它保存的是自己本身，因此对于ascii字节和宽字节，它需要不同的容器去实现。反观QString，它可以容纳不同类型的字符，并且可以以bytearray的形式返回齐Utf8和以字节形式返回utf16，实在是很方便。（当然，如果用它直接去接一个中文字符串，那么输出出来很有可能是乱码。）从字符串中提取内容，比如split，比如字符串转换为其他类型，……；
3.效率可能不够高。之所以说可能，是因为标准库没有严格规定string的优化。有些string可能实现了copy-on-write，有些可能没有。如果你去看QString代码，一个字符串类有几万行（包括注释），里面有大量周边设施和对它的优化，几乎适应对于工程中所有的情况。字符串的输入输出，输出到控制台，输出到日志文件，输出为json、xml，不同编码的互相转换。
stdstring说到头只是一个轻量级的字节数组容器，在一般简单的情况下用它也够了。这三大块应用，标准库除了iostream这个垃圾战斗机之外，就再也没有其他可用之物了。必须通过boost之类的第三方库来提供
而第三方库的最大问题在于，虽然很大程度上弥补了配套设施的严重不足，但是都其各自为政，api的设计不够系统化，造成各种各样奇奇怪怪的调用风格，很不统一当然，由于string在字符编码上的漫不经心，所以在为其设计相关配套函数，其实也很麻烦。假如，string支持以下的使用代码，想必用起来就会很方便总会有tradeoff。有人强调的std::string的memorylayout缺点（或优点），恰恰是其它人认为的优点（或缺点）。有人说std::string缺少built-in功能，但也有人说现行std::string如此臃肿，本身就是一个设计缺陷。但若是把具体的string设计为policy接口（无论静态还是动态），既认为string是具体的，又认为它是general-purpose的，那迟早会觉察到公共语义下的string本身就是一个童话（接口不稳定）
缺陷讲完了，不过我觉得这些问题基本上不会困扰一般的c++用户，平时最重要的还是不要为了这些“缺陷”去做一些奇怪的优化，以后bug更多，维护代价也高。fb内部之前是把string换成fbstring了
不过一直为此要维护一个分开的libc++，非常累，前几个月发现现在std::string做的足够好了，是由一个perftradeoff，但是还是用回了std::string。用这个小故事用来告诉大家不要天天想着这些缺陷搞太多猛如虎的操作，还不如多搬两块砖。