1907 条评论

友人C 4 个月前
此条为私密说说，仅发布者可见
 2 发自Mac OSX

友人C 5 个月前
C++Tips 一个“暴论”：大部分的c++业务代码里使用模版或者宏除了炫技和增加阅读成本外没有任何好处。
 0 发自Mac OSX

友人C 10 个月前
C++Tips
一个可能会被搞错的运算符例子，下面这个代码输出的结果不是true，而是false
true || false? false:true;
三目运算符简洁但是非常容易出错。这里的代码等价如下，有的时候可能被直觉搞错
(true || false)? false:true;
 0 发自Mac OSX

友人C 11 个月前
C++Tips Google C++ Style 关于输出参数在2020年5月20号 以及之前推荐使用指针：
Input parameters are usually values or const references, while output and input/output parameters will be pointers to non-const.
而在之后，则修改规范推荐使用了引用：
Input parameters should usually be values or const references, while required (non-nullable) output and input/output parameters should usually be references
个人认为指针作为输出参数更明确语意，如果使用引用参数，程序员可能漏写了const，从而输入参数被误认为是输出参数。
但是可能这不是一个好的理由，因为这是程序员自身的错误，同时传递指针需要内部判空使用有些麻烦。
 0 发自Mac OSX

友人C 11 个月前
💼 工作记录
    std::string origin_response_body = "test_content";
    const int body_len = origin_response_body.length();
    std::unique_ptr<char[]> response_body(new char[body_len]);
    memcpy(response_body.get(), origin_response_body.c_str(), body_len);
    std::string body = response_body.get(); 
这段代码是有隐患的，但是却比较难发现。因为如果这个数组中最后一位不是\0 结束符，构造string的过程中就会一直按照地址递增访问内存直到找到结束符为止，这个过程会导致内存异常访问等问题
但在真实环境中，可能不一定会导致崩溃，因为当我们new[body_len] 申请一段内存的时候，由于内存对齐以及操作系统的差异性，分配的大小会大于申请的大小，因此在body_len 位置的内存很可能就是结束符。 C++Tips
 1 发自Mac OSX

胖哥 11 个月前
1:
std::unique_ptr<char[]> response_body(new char[body_len + 1]); // 分配空间 这种非常重要 且常见
memcpy(response_body.get(), origin_response_body.c_str(), body_len + 1); // 拷贝完整字符串
2：动态分配 在设计、开发阶段是要被严格管控的， 至少做到1、在详细设计阶段就要体现在文档里。2、边界检查 3、测试覆盖
 0 发自Windows 10

胖哥 11 个月前
好像发的不对，检查了下，基本没有临时的动态分配、
 0 发自Windows 10

友人C 11 个月前
我这里简化了，memcpy的逻辑是另一个函数的事情，函数参数就是char*，所以外部必须传入一个分配好空间的字符指针进去
这个是sdk的代码，个人觉得c++项目而且没有那么高的性能要求下，尽量可以不用char*指针，同时这个sdk内部保存的就是string，但是函数参数是char*导致string->char*->string 这样诡异的逻辑出现
 0 发自Mac OSX

友人C 2023 年 08 月 12 日
周五下午 本来是团建 我没去 开开心心回家了 本来准备享受者加长版周末，下午就有一个崩溃问题抛过来要查，而且看上去很高优的样子。是访问map中的一个空指针或者野指针问题。 从日志上看 每次添加元素到map以及从map中移除的日志都是对应的。怎么也想不通为什么会崩溃。而且复现路径要配置环境 很麻烦。一下午看了日志 没有任何头绪。晚上把环境配好，加日志 断点调试。前前后后又折腾了四个小时 最终定位到原因是 map中移除元素 进入了这个元素的析构函数，而这个元素的析构函数又操作了这个map中元素， map erase的时候这个元素在map中会变成空的指针，因此就崩溃了…. 这个问题其实很容易犯，并且很难查。因此从map中移除一个unique ptr元素，最好先把这个unique ptr从map元素中移除，然后再销毁指针. C++Tips
 6 发自微信公众号

胖哥 2023 年 08 月 15 日
可能我们的系统比较小，遇到卡死或者小概率崩溃最先想到的就是严格条件扫一遍UT，从野指针警告中筛选新提代码涉及的，大概率就是了。
 0 发自Windows 10

胖哥 2023 年 08 月 15 日
这种问题白盒测试不会发现吗？按理说这种空指针问题在单元测试中很容易被扫出来吧。
 0 发自Windows 10

友人C 2023 年 08 月 19 日
很多业务代码没有单测，团队目前也在做单测建设了，更重要的是这个场景之前没想到，是新需求引入的问题
 0 发自Mac OSX

dsadsa 2023 年 10 月 09 日
jsdajdkaj在
 0 发自Windows 10