@ch2 具体自己可以搜搜 javascript 拦截请求啥的 核心就是做 hook 那些 添加自定义请求头啥 添加 token 啥的 也都是 hook 直接来做的 统一处理就很方便了

@ch2 #11 服务端其实能做的也就这么多了（针对现在特定要求的情况下） 剩下的就是客户端再做优化了 库不支持并行没有关系 客户端现有代码不变 加上一层 拦截请求 自己来做并行缓存下来就可以了

webrtc 不太现实 这个要同时使用相同资源多的...
m3u8 没啥问题啊 自己通过域名做下负载 然后再把 m3u8 做成动态接口 自己服务器间用算法再做一下动态的负载 就是一个 m3u8 N 个切片 做个规则 把切片动态的分布在不同的子域名下(服务器间闲忙状态维护下) 均匀的分布下 也就可以了吧...

...多说一句 现在那种小站 不都是 套了一层 cf 本站就维护了 html... 什么图片 切片 统统都是薅的羊毛 分布在各个不同的免费站 或 上传漏洞上....

哈哈 没注意过 刚试了下 方便很多 其实吧 很多情况 根本的解决方案 就是在选择复制的时候 能临时的禁止掉 原有的点击响应就好了 去复制个地方 动不动 就是整个超链接点进去了 然后选择拖动吧 自动的来回跳 动不动就给你全选了 ..

@leeyuzhe 不应该是 手机上 还是只有一个 chrome 但是自己清净了很多 更多有用的东西呈现出来了么...

感觉是连入 wifi 的问题 原来也经常遇到的就是 路由器多个 wifi 连接 连 5G 的 跟有线或其他 就识别不到一起

win10 下 我用的 pin 而且当错误次数超过十来次的时候 接受的就不再是 pin 或密码了 必须输入 A0B2C3(好像是这样) 才能继续恢复

关键还是看自己吧 反正报班主要就两个方面 一个是环境(只要能让自己静下心来学习的环境都行) 另一个就是主流的相关技术整理了 .. 好的班 对相关技术的整理 能避免不少弯路 环境也不错 ... 但是深入源码相关的 也就是靠自己去啃了吧 别人教的 不管报班 还是自己找资料 也都是系统的用法 主要的原理 最终的深入 还是自己去啃了

反正我现在国产软件少用 用到的时候就虚拟机去呆着的打架去 也不用担心啥了 现在的配置 虚拟机都挺流畅的...

反正我现在国产软件少用 用到的时候就虚拟机去呆着的打架去 也不用担心啥了 现在的配置 虚拟都挺流畅的...

反正我是感觉 gitlab 团队使用比较适合了 本身自带的 ci/cd 也是可以的 虽然跟其他相比 各有优劣 不过 就是哪个合适就用哪个 到时候也可以针对项目使用 drone jenkins 等
其实吧 对于私有部署的 不管哪个 git 也都大同小异 功能上的差异问题 有些为了精简 像 gitlab 更注重的功能 各自取舍吧
自己私有部署 先就新的小项目 搭起来 选一个 选多个 各自测试下 都跑下流程 踩踩坑 看看是否适合自己的需求 然后再定吧 慢慢熟悉功能 慢慢积累 或者是再找比较精通的运维来把新环境搭起来 一定得比较熟悉的能处理未知问题的
比较关键的还是看公司运维方面的问题.

弱弱的提醒下 OP 新环境测试 一定要多备份 多备份!!!!!! 毕竟出了问题 很多时候 不需要费时找问题所在 直接重搭 恢复备份 也是比较快捷的方案

看公司情况 如果能接受云的话 其实付费的 私有仓库 云上的 DevOps 也是很好的选择啊 毕竟这方面运维方面的问题就不用太担心了 功能上也不需要担心 肯定更丰富

@datiewang 哈哈 比如有个道具转职卡~~~

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