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