Artinna-Lau
string和char是不一样的。char我们更了解他们内存地址。无论是指针还是数组都很了解。对于底层代码用char。逻辑代码用string。我是这么使用的，
罄竹10
在C++中优先使用String是一个良好的习惯。除非是C的死忠者习惯如此，否则应该使用String而不是char。
char是用来处理任何8bit数据类型的，逻辑值、整数、字符ASCII码等都可以。要用来处理字符串需要使用char[]数组，比较麻烦，也不好控制。
String是一个模板类，它是专门用来处理字符串的，封装了很多处理字符串的成员函数。并且它是C++标准库的一部分，是所有C++实现都支持的，也是C++创始人推荐使用的。
术业有专攻，应该用哪一个不难选择吧。
Assault53484432
string 是C++ std里的模板类。 不是MFC 的CString类。C语言根本没有类的概念。
使用string 最大问题是需要运行时库，所以无法运行在无vc++201x的电脑上。CString 与char *都不会出现这种情况。
CString 比string更好用。所以如果你编写MFC程序最好用CString类。
如果使用结构体，必须使用char[],不能用类。特别是网络封包程序。
考虑到程序能在所有电脑运行，不需要额外安装运行库的情况下，只能强制使用char*
轻风扶醉
作为一名一线开发者，下面说说自己的看法。如有不同意见，欢迎留言讨论。
先说下自己的观点，个人不是很看好你们领导这种，坚持用char而不用string。
既然选择了C++，那么为什么不用STL早已为我们封装好的string呢？
string其实现就是一个带有长度的char * ，帮我们省去了自动管理内存的麻烦，都已经0202年了，你还会担心内存不够用吗？
个人猜想：
也许你的领导在某一项目中使用了string过程中被深深的坑了一把，但是却不知道具体原因，所以立下了祖训：禁止使用string！
也许在调用某个厂商提供的动态库时，在接口中使用了std::string而不是char * ，结果遇到了灵异事件，程序莫名的崩溃了，连自己的调试器都没有进入，至此，禁止使用string 这一莫名的结论就一直流传下来了。
那么如果我们真的遇到某些厂商的SDK出现这种奇葩库，怎么破？
答案很简单：用发布那个dll的VC版本，再写个动态库做封装库，把接口转发成char*。
一个程序员的奋斗史
string曾经使用COW优化，变成一个有时是值语义有时是引用语义的怪物。而且当使用引用计数时，早期的有些版本居然没负责线程的竞态条件，因此线程不安全了。早期的版本，小长度的字符串也使用堆内存，是性能的大漏勺。string是技术发展的热点，新技术的试验场，因此实现五花八门，不能用来做DLL。C+++20出现后，string应该以SSO技术为主流了，小长度字符串不会触发malloc操作。再配合string_view,也是很高效的。总之，2020年代，用string还是不错的选择。
Thomas76
C陷阱与缺陷还是程序员的自我修养里面讲过，char*不会被内存缓存，存储隐私数据时要用char*，用string可能会导致隐私数据泄露
猫呢个咪的
看环境和问题，char 和string 有不同的应用场景。不说明情况，谁知道怎么回事？总的来说，最大的可能是你懒不愿意考虑到底要用char（？）几，所有的都用了string，所以领导才强制你用char。另外，数据库定义字段也有char的长度限制，你不过脑都用string等着爆bug吧。真实情况一般都是char用的多也稳定，少部分情况用string。
懒爸爸育儿日记
那就用char[]嘛，然后再封装一下，用起来来和string一样方便。
视频音频通信呼叫中心
你领导说的是对外接口用char不用string，你自己理解偏差吧
hxh0791
在嵌入式上，char一定好用，string就不一定了。
C在开发效率上的确不去C++，但是至今没被淘汰，自然有其独特的优势。
你可以问问这个前辈，很有可能他会告诉你，这样写是为了可移植性。他可能并非不会用string
