这篇主要写关于字符串的使用，包括STL中的string，C风格的字符串，还包括Redis's sds，和Facebook的开源的folly中的String，从代码结构上，性能上，平时使用时遇到的坑，和结合具体使用场景(业务)去选择；后三者都可以从Github上下到源码分析。
使用纯C语言编码时，使用到字符串时，没得选择，如char szName[iCount]或char * pName = (char *)malloc(iCount)，那么在使用一些C库函数时，一方面会引起性能问题：如线性时间strlen函数；增加一个字符时，可能引起存储空间的重新分配，字符的移动，原空间的释放[malloc的分配原理挺复杂的]；另一方面是安全问题：如二进制安全，串中不能包括空白结尾符；缓冲区溢出而导致的漏洞等等；
正因为考虑到C字符串的一些问题，使用C编写的Redis自定义了sds数据类型，解决了以上C字符串的一些问题。通过分析sds源码发现，它包含了free，len，buf成员，分别表示buf未使用的字节个数，buf已使用的字节个数，存储数据的buf空间，那么常数时间可以获得字符的个数而不是strlen，通过在buf中存储'\0'空白符是安全的，因为可以通过len决定有没有到串的结尾，通过free视情况重分配去避免缓冲区溢出的问题；每次重分配时可能多分配一些空间，如STL中的string分配问题；删除空间时并不是真正的重新分配更小的内存，而是延缓，保留原内存不变，只更新其他两个成员，防止后来又要更加内存，这样可以减少频繁的malloc，free调用。
而STL中的string，则在某种程度上高效许多，找到头文件中有如下语句：
typedef basic_string
当插入时，内存不够了会自动分配，不用去担心使用C风格字符串的一些问题，但还是无法避免内存的申请与释放，内容的拷贝等等，但是与stl中的vector一样，会去减少内存的分配，在vector的实现中有如下语句：const size_type __len = size() + std::max(size(), __n);即每次扩容时为当前容量的两倍；而在string的实现中有：__capacity = 2 * __old_capacity，也是如此。然而都没有办法自动缩小不用的空间，这里有个办法就是与临时对象交换，像这样：vector
string的一些重载接口使用会有一定的性能影响，比如构造函数：
string( );
string(const string & str );
string(const string & str, size_t pos, size_t n = npos );
string(const char * s, size_t n );
string(const char * s );
string( size_t n, char c );
其中string(const string & str );效率最快的，使用了cow(copy-on-write)，先共享，如果需要更新了再拷贝，也算是种延缓分配资源的做法吧，但在string中使用cow会引起其他问题，如源码中的atomic_add_dispatch实现计数加一，使用原子操作保证操作引用计数的安全，但stl's string本身不是线程安全的，“那需要锁定包含目标地址的一片内存区域，防止其他CPU在此期间的并发访问，从而序列化对同一地址的访问；系统通常会lock住比目标地址更大的一片区域，影响逻辑上不相关的地址访问；lock指令具有”同步“语义，会阻止CPU本身的乱序执行优化”
网上有关于stl的其他实现，如eager copy，short string optimization[陈硕的那本Linux多线程服务端编程有相关的讲解(muduo :))]。
Folly中的string则使用了三层的存储策略（three-tiered storage strategy），根据长度将fbstring分为三类：small/medium/large，分别采取不同的优化措施，以达到最佳性能[没使用过，看源码有点复杂]。
一些引用：
深入剖析linux GCC 4.4的STL string
std::string的Copy-on-Write：不如想象中美好
漫步Facebook开源C++库folly(1)：string类的设计
Is std::string thead-safe with gcc 4.3?
C++ 工程实践(10)：再探std::string