string无法取代char*

涉及字符串，C开发人员使用char*，大部分C++开发人员会优先使用string，其实string也不是万能。接下来，我将介绍string无法取代char*的三个场景。

string依赖运行时库，不适合在不同运行时库间使用

string属于C++标准库，Windows是将其实现在C++运行时库内，不同的Visual Studio版本使用的运行时库是不同，string在不同的运行时库内实现也有所差异，可以验证下VC6下的sizeof(string)与Visual Studio 2013下的sizeof(string)的值不一样。这时如果将一个string对象在不同运行时库之间共享，就会出错，甚至崩溃。

特别是作为SDK导出的接口，字符串使用char*，而不能使用string。因为SDK的使用方使用的Visual Studio版本不确定，存在与SDK开发的Visual Studio版本不同。为了更好兼容性，再次强调导出接口给别人使用的时候，不要使用string。

string封装了内存的分配，不适合对内存管理需要完全控制的场景

string封装了内存的分配与释放，开发人员不需要担心内存问题。但是，string是在堆上分配内存，会产生内存分片。对string进行更改操作(如插入、替换)导致string的长度变长，string内部的内存都会重新分配，对性能也存在影响。所以，对性能要求特别高，希望对字符串的内存分配进行优化（比如从已分配的大块内存池上分配），就使用char*。

string只能返回const char*，不适合调用带有char*参数API的场景

string通过c_str()接口，返回const char*，适用于大部分C接口的场景，但是如果C接口是char*，就无法调用。有些读者可能会想用const_cast<>强行转化，但这不符合string的设计。string不允许外部直接修改字符串，而是要通过string提供的接口（如replace、insert），如果外部直接修改字符串的内存，将会导致string内部某些状态不一致，出现错误，甚至崩溃。

虽然有些场景只能用char*，但是string的优点是非常明显的，开发人员无需担心内存管理的问题，对字符串的操作也很方便。所以，如果不存在性能和第三方接口对接问题，强烈建议使用string。