@GeruzoniAnsasu 谢谢 确实我比较偏激 结论上也有问题 你说的 3 点 2,3 我没反对的 看到未初始化的地方 然后我表达的就跑题了 对于非 POD 类型 拷贝构造函数 是不会额外的对整体做零初始化的 默认生成的 还是自定义的 结果一样的 所以就是你说的 第二点这个问题 我前面表达的 主要还是针对 gid1 未初始化的情况 不太清楚 OP 的 MyType 是否是 POD 类型 如果是 POD 类型 那么 GID 也就是 POD 类型了 这种情况 就是我前面的例子出现的结果了 在 clang -Os 优化下 问题就表现出来了 这时候 gid1 跟 gid2 都是未知数据 同时 gid2 跟 gid1 也不同 应该就是优化情况下 啥都没干. 此时如果显式的对 gid1 做零初始化 就比如 GID gid1{}; 这个情况下 gcc 跟 clang 的表现就都相同了 clang 下的反汇编 如果 GID 位数不多 gid1 跟 gid2 同时直接就是几条指令 清零了 如果是结构体较大 就转变为 memset 清零 .

@jim9606 op 的举例 不是比较函数能解决的 本身就是未初始化的变量 得到的结果本身就是未知的 就算挨个成员比较还是错误的 虽然-O0 debug 模式下可以得到想要的结果 但是在 -Os 优化模式下 语义上的错误就表现出来了 你看看我前面的例子
例子得到的结果很明显 这里是 -Os 模式下 gcc clang 是有明显差异的 本身就是未初始化的未知数据 看这也没意义的 不过 gcc 跟 clang 的 拷贝的行为是有差异的 但是如果 对 a 做了显式的零初始化 a 跟 b 的值 g++ clang++下得到的结果都一样了
前面 gcc 跟 clang 拷贝结果上的差异 本质上还是 -Os 优化导致的 但是这在语言标准层面 是没有影响的 因为本身就是未初始化的语法 所以结果就是未知的 如果非要使用未知的数据 肯定是错误的...

接下来 切换的-O0 debug 模式下编译 得到的结果是 这次 b 拷贝的 a g++ 跟原来一样 a b 内存是相同的 clang++ 内存也完全一致了

同时 做了另一个测试 就是对 A 主动添加个构造函数 两个测试是 一个添加一个空构造函数 AA(){} 不做任何操作 另一个个 添加个构造函数 AA(): ...(0){} 对所有成员 或个别成员做初始化 结果是 在-O0 debug 模式下的 结果 g++ clang++ 同前面一样 在-Os 模式下 结果就是 空构造函数的结果 g++ 同样 同前面一样 clang++ 照样是 a b 都是随机的 但是对任意成员初始化后的例子 clang++ 下 虽然 a 内存结构 未初始化成员 跟填充区域 都是随机 但是 b 拷贝 a 后的内存数据 同 a 是完全一致的.

造成这种结果 最根本的原因 就是-Os 的优化 在 a 未初始化的情况下 优化器可以认为数据本身就是未知的 无意义的 可以做更大程度上的优化 所以 clang++ 优化后得到的结果就是随机的 跳过了认为无意义的初始化等. 但是 做初始话后的情况 clang++ 保证逻辑上的正确性 具体看反汇编会清楚很多 不过也没啥必要了 本身不做初始化 语言层面结果肯定就是未知的 虽然 debug 模式 或者特定编译器下 得到想要的结果 但是这也就是编译器做的特殊处理 导致的瞎猫碰上了死耗子.. 但是到-Os 优化下 错误就体现出来了

OP 所说的 拷贝构造 函数 对填充区域的的差异问题 我这里倒是没见到 只要对对象做好初始化后 拷贝后的 是相同的 但是如果只声明 不做主动初始化 在-Os 模式下 clang++ 得到的结果就是未知的 不清楚 op 的编译器啥版本 我这里 gcc 8.3.0 clang vcpkg 编译 last 版本


自己说了这么多 其实讨论这些 着实没啥意义 本身就是未初始化的 错误使用 结果就是未知的 先抛开各个编译器的特殊语法 实现等.. 如果正确的按照语言标准层面的 流程做的话 就算是-Os 优化 得到的结果也不应该有差异的 如果真有差异 那就属于编译器的 bug 了

戴森不是主要靠风速的吗 温度只是为了不冷吧 (:狗头

先搞清楚自己的延迟 真是硬件配置造成的内网延迟 还是自己的科学线路延迟的问题 还有就是 能有线就有线 无线虽方便 但有代价 再高端的无线设备 也只是减小这些 也没有有线来的实在 稳定

全局软路由的话 很多时候问题也挺多的的 特别是分流配置啥的 很麻烦 而且很多时候也有不同的需求 就 op 说的 平常其实也就 tv 用用 其他设备反倒可以各自的客户端 其实这种情况 用旁路由挺合适的 正常情况都是统一的国内网 tv 上 单独设置路由为旁路由 dns 也设置好 也不会影响其他设备

@jim9606 这种比较方法的使用在大部分情况下是有问题的 这是可以确认的
最终原因就未初始化的结果 是未知的 op 也贴了问题所在 这种隐式的默认行为编译器也有差异问题 之所以 debug 模式下没问题 归根就是编译器的特殊处理的结果 其实也没必要讨论的 明显就是用错了 C4700 的警告 最新的 vc++下是视为错误的 g++ clang++ 倒是没错 但是这本身就是未知的行为 所以实现也有各自的差异 但是把个别编译器对这种未知行为的默认实现 当作标准来用就带来的 现在的问题
```c++
#include <iostream>
#pragma pack(8)
struct AA
{
bool m;
int k;
bool d;
};

int main()
{
AA a;

AA b =a;

for (int i = 0; i < sizeof(a); i++)
{
std::cout << std::hex << (unsigned int)(((unsigned char*)&a)[i]) << ",";
}
std::cout << std::endl;

for (int i = 0; i < sizeof(a); i++)
{
std::cout << std::hex << (unsigned int)(((unsigned char*)&b)[i]) << ",";
}
std::cout << std::endl;

return 0;
}
```
a 未初始化结果
g++ -Os main.cpp
0,0,0,0,0,0,0,0,80,22,2,91,
0,0,0,0,0,0,0,0,80,22,2,91,

clang++ -Os main.cpp
b4,34,e2,4b,ff,7f,0,0,0,0,0,0,
c0,12,40,0,0,0,0,0,d0,10,40,0,

如果把 a 做零初始化后 AA a{}; AA b=a;
g++ -Os main.cpp
0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,

clang++ -Os main.cpp
0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,

初始化后的结果是一样的

也不是说必须要主动的做零初始化 毕竟很多时候 做零初始化是多余的 不过就是很多时候是依赖编译器优化 还是自己主动优化 自己手动优化就要注意更多的细节

总结就是 对结构跟类用 memcmp 做比较是存在问题的
对未初始化的变量的使用上 是要注意的 不要依赖编译器对这种未知行为的实现 因为本身就是未知的行为 不是语言标准的规定 所以编译器实现上也没有必要的统一实现 结果上不同正常的 但是不要把对这种未知行为的实现 当成语言的标准来使用 (除非限定使用前提 ) 比如 此代码 必须在 g++ 甚至指定版本 指定 debug 下运行....

最关键的问题 不是模式问题 跟 memcmp 也没太大关系 (虽然用来这样比较两个结构存在非常大的问题,正常情况自己做操作符重载)
关键在于 初始化的问题 主要原因 c++ 隐式的行为太多了 这次的问题 属于开发工具 为了 debug 模式下 查找问题容易些 在 c++标准之外做了额外的处理 导致了 本来未知行为的代码(也就是错误) 变成了固定行为(也就是 memcmp 比较的内存相等 )
https://en.cppreference.com/w/cpp/language/default_initialization#:~:text=otherwise%2C%20no%20initialization%20is%20performed%3A%20the%20objects%20with%20automatic%20storage%20duration%20(and%20their%20subobjects)%20contain%20indeterminate%20values.

https://en.cppreference.com/w/cpp/language/value_initialization

https://en.cppreference.com/w/cpp/language/zero_initialization

很多时候都会说 声明变量的时候 就做主动初始化的操作 就比如 T{} T (...)等 这也是个好的习惯 但是很多时候 这种也是属于多余的操作 这就要看自己对代码的把控了
反正就是 切勿对未知的内存做操作就行了 更多的情况 不要关注 debug 模式下可以 release 模式下又不可以 再比如 gcc 下可以 msvc 下又不可以...... 只以标准规定的来做

c++标准这东西 还是多写代码吧 做的多了 就慢慢熟悉了 不过嘛 平常一定按照标准规定的流程做 总没错的
虽然其他的方法也能解决问题 但是也容易带来很多问题
总结就是 该初始化就初始化 把控好 c++的各种隐式的默认行为 能使用明确的 就不要依赖隐式默认的

@bpazy 脚本做好 很方便 不过就是 环境的依赖配置不强的 或者同步配置备份配置做的好的 就行 如果不是 也是折腾 这种情况就还是配置好做备份来的方便

别管什么心理作用 还是真的有用 对自己有好的效果 就是有用

强迫症 难 我已经病入膏肓 举个例子 我经常性甚至会因为几个方法的设计 明眼的思路就在哪里 能达到目的 但是潜意思里感觉不合理 就会被放大 最终导致整体性的停滞不前 甚至跑偏思考更底层的轮子....
其实吧 还是需要自己给自己总结一套能让自己接受的 简单的规范 这样会好很多 当意识出现的时候 就按照这套规范走. 就大大减少选择困难了...
就好比好多人的房间 看上去很乱 但是相对上很规矩 就是一套自己固定的分类流程 找东西也很方便

反正我是没找到办法 但是区分也只能个人来区分吧 仔细想想太多也没法定性 更多的不喜欢是有自己的主观意愿在里面 人跟人的还都不同呢...
反正我总结下来的就是 看到反感的 直接屏蔽频道没二话 偶尔选不喜欢 然后平常陌生的内容 很多都使用无账号的无痕模式来看 然后就是 只在自己账号下面 看自己喜欢的类型 频道 陌生的东西 从不主动在自己账号下出现 哪怕搜索.
然后这样下来的结果就是 推荐的内容 就多是自己看的类型了 比如我经常看外区 mv 中文的推荐内容看到都屏蔽了 现在也很少出现了 反正不好的地方就是 自己最近看啥 推荐的全是啥...

https://en.cppreference.com/w/cpp/language/copy_constructor#:~:text=T%20has%20a%20user%2Ddefined%20move%20constructor%20or%20move%20assignment%20operator%20(this%20condition%20only%20causes%20the%20implicitly%2Ddeclared%2C%20not%20the%20defaulted%2C%20copy%20constructor%20to%20be%20deleted).

说的很清楚

换个思路 自己接入 ssh 库呢

确实像二楼说的 放内存盘里 还是有 4 楼说的 读文件上优化下(不需要全读 只读新增的 日志一般也都是往后追加的嘛) 结合处理下 应该还好吧

测试代码 用最干净的测试 或者自己有对齐要求的 就主动 push 设置 然后在 pop 你无法保证加进来的其他代码是否改变了默认值
不要因为未知的或可能的设置 来得出自认为有问题的结论

@360511404 我小杠一下 不要侮辱精神病患者!!!! 虽然我知道你想表达的 但是这样 很不妥..

安装位置这方面 永远是痛 当然按照这种方式 不分盘 当适应了用起来应该也挺舒服的.. 不过还是挺无奈的 有的装在这 有的装在那 有的 分几个位置 有的...

没用过 我有个疑问 安装位置在哪里 默认的 C 盘 是否可改 如果改了 是否会有问题...

现在自用的方案 hyper-v 跑个 win 几个 linux(大部分直接 wsl2 容器了) 然后 vmware 跑了黑果(编译用 正常用太卡) 如果用 linux 桌面的 同样用 vmware (显卡支持问题) 貌似新系统支持 wsl 显卡直通啥的 不过嘛 六年前的机子了 新系统装不了 不折腾了
然后 hyper-v 的 win 直接用的 rdp 就像前面楼上说的 全屏 直接一个虚拟桌面 真的无缝使用了
一套流程下来 还算挺舒服的...