首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
您找到你想要的搜索结果了吗?
是的
没有找到

charchar[]、char*、 const char*、string(无效的const char *到XXXX的转化)

自然要附上自己的使用经验了 1、std::string 和QString在网络传输的过程中是不建议配套的,传过去,接到就成乱码了。 我因为这个愚蠢而把我们客户端人员坑惨了。...2、char* 使用时建议手动分配空间,不然你也不会知道它什么是就给你段错误了,那时候想改就麻烦了,集腋成裘。 3、双引号括起来的字符串是属于const的。...4、使用char[]前随手memset,不要因为它是局部的。刚刚又因为没有memset把我们客户端人员坑惨了,可能是局部变量占用空间过大,没来得及释放,将上次调用的内容留下了。...5、将char*变量作为参数传入函数,不用传出来了。 6、不要将局部变量地址作为返回值,没意义。 7、把图片里的strncp_s改成strncp.

1.6K30

string无法取代char*

涉及字符串,C开发人员使用char*,大部分C++开发人员会优先使用string,其实string也不是万能。接下来,我将介绍string无法取代char*的三个场景。...这时如果将一个string对象在不同运行时库之间共享,就会出错,甚至崩溃。 特别是作为SDK导出的接口,字符串使用char*,而不能使用string。...所以,对性能要求特别高,希望对字符串的内存分配进行优化(比如从已分配的大块内存池上分配),就使用char*。...string只能返回const char*,不适合调用带有char*参数API的场景 string通过c_str()接口,返回const char*,适用于大部分C接口的场景,但是如果C接口是char*...虽然有些场景只能用char*,但是string的优点是非常明显的,开发人员无需担心内存管理的问题,对字符串的操作也很方便。所以,如果不存在性能和第三方接口对接问题,强烈建议使用string

82030

char *转换为string的陷阱:char*中包含较多的0

首先是单步把解密流程过了一遍,发现解密没有问题,能正常的解密,但解密出来的长度就是不对,分析才发现加密后的数据的长度也不正常,所以考虑是加密源数据的问题,通过分析,才发现一个二进制的源数据经过转换为字符串对象string...后使用openssl的接口完成的加密处理,导致string对象比原来的字节数组长度要短,短的原因是字节数组中包括了'\0'结束符,原以为是openssl的接口实现存在这样的问题,建议使用方将加密的字节数组将...0字符都过滤一遍,但想来还是不正确,原来char*的数组转换为string存在一个陷阱:见“https://blog.csdn.net/b876144622/article/details/79972498...”;所以还是转换的不合适,修改前后的代码如下:   //原来的代码   #if 0   char *temp = (char *)malloc(length + 1);   if (temp == NULL... inputStr = temp;   FREE(temp);   #else   //修改的代码   string inputStr ;//= temp;   //convert temp to string

39520
领券