cnbatch 最近的时间轴更新 cnbatch 最近的时间轴更新 |
cnbatchV2EX 第 576172 号会员，加入于 2022-03-20 22:20:14 +08:00 |
cnbatch 最近回复了
2 天前 回复了 jim9606 创建的主题 › C++ › 似乎在 C 的领域，让一个新程序“为未来准备好”是一件很麻烦的事 |
2038 问题由工具链兜底实在是强人所难了，毕竟作用很有限。即使工具链给了 64 位 time_t 在内部做转换，到了 OS 层面给出的时间直接就是错的，工具链再怎么兜底都没用。这就好比寄信人提供的门牌号直接就是错的，就算印门牌号的纸足够容纳都没用。
MinGW 那边可以认为是没人搞，长期以来进度缓慢，无解
这个有折中做法，chcp 65001 即可解决。也可以主动调用 SetConsoleCP 和 SetConsoleOutputCP 。
Android 的事情，老实说，那得看 Google 的脸色了。编译器开发者或许能够解决二进制文件生成的支持，但 SDK 的更新就无能为力了。若 Google 决定停止向旧版系统提供新版 SDK （无论 C/C++还是 Java/Kotlin ），无论给多少钱都不行，那也不可能拿起武器对准 Google 大楼要求他们继续更新的吧。这个责任，不是某一个编程语言能够承担的。除了 Google 自己，其他人拿它没办法。顶多只能靠开源社区自己打 patch 做更新。
打个比方，这就相当于要求在 Linux 4.x 使用 io_uring 的 API ，编译时发现不存在然后责怪编程语言和工具链，属于怪错对象了。想要用不是不行，这得有人愿意做 backport ，但这显然不是编程语言和工具链的责任了。
MinGW 那边可以认为是没人搞，长期以来进度缓慢，无解
这个有折中做法，chcp 65001 即可解决。也可以主动调用 SetConsoleCP 和 SetConsoleOutputCP 。
Android 的事情，老实说，那得看 Google 的脸色了。编译器开发者或许能够解决二进制文件生成的支持，但 SDK 的更新就无能为力了。若 Google 决定停止向旧版系统提供新版 SDK （无论 C/C++还是 Java/Kotlin ），无论给多少钱都不行，那也不可能拿起武器对准 Google 大楼要求他们继续更新的吧。这个责任，不是某一个编程语言能够承担的。除了 Google 自己，其他人拿它没办法。顶多只能靠开源社区自己打 patch 做更新。
打个比方，这就相当于要求在 Linux 4.x 使用 io_uring 的 API ，编译时发现不存在然后责怪编程语言和工具链，属于怪错对象了。想要用不是不行，这得有人愿意做 backport ，但这显然不是编程语言和工具链的责任了。
2 天前 回复了 jim9606 创建的主题 › C++ › 似乎在 C 的领域，让一个新程序“为未来准备好”是一件很麻烦的事 |
多说一句，如果换了“其他语言”写程序手动调用 POSIX API ，照样会遇到一模一样的情况
手动调用 Win32 API 同理（例如 rust winrt ）
手动调用 Win32 API 同理（例如 rust winrt ）
3 天前 回复了 jim9606 创建的主题 › C++ › 似乎在 C 的领域，让一个新程序“为未来准备好”是一件很麻烦的事 |
这是 C 的事情，发到 C++板块不怎么妥当吧
前半部分
1 ，这是 MSYS MinGW 的锅，它们没处理好 64 位的适配。Windows 提供了 fseeko64 的替代品 _fseeki64()，中间转换层本该做好映射支持的。
2~6 ，这就是系统 API / SDK 的锅，包括 Android
至于换语言能“解决”这些锅，本质上只是它们在标准库里面帮忙擦屁股而已。
「为什么开发环境就不能默认支持这些情况呢，难道还影响兼容性？」
开发环境当然可以默认支持这些情况，正常 POSIX 环境、正常 MSVC 环境直接写程序调用标准库 API 都没问题。
没做到默认支持，很多时候完全是疏忽 (MSYS MinGW)，或者是怕麻烦、赶进度(Android 5.0~6.0)。
后半部分
1 、若是 OS Level 的限制，编程语言本身能做的事情其实很有限。如果 OS 本身没解决 2038 问题，只要系统关机、重新开机，系统时间直接就是乱的，再完善的编程语言都没办法强行掰回来。
若 OS Level 已经解决了 2038 问题，那么无论是 C 还是 C++，都不需要担心这种事。
2 、纯 POSIX 可以。跨平台跨到 MSYS MinGW 的话，按理说 MSYS MinGW 应当处理好相应转换（像是背后处理编码调用带 W 的 API 、检测目标 Windows 有没有启用 UTF-8 区域选项），但这就不是普通使用者可以强制要求的了。
3 、这就有点霸道了，别说 C 语言、C++，哪怕是 Python 都没法如此保证。
4 、单纯“不拒绝使用”的话，那还是不需要担心。如果想要更高要求达到“表现一致”，那就不太可能了。
Linux 的 IPV6_V6ONLY 默认为 false ，而 BSD 和 macOS 还有 Windows 的 IPV6_V6ONLY 默认是 true 。
OpenBSD 更是搞起了内部限制，无论 IPV6_V6ONLY 设成什么值，它都按照 true 处理。
5 、类似 2
6 、支持近十年出厂的系统很合理。但硬件？？这可不是编程语言可以掌控的吧，这是 OS 和驱动程序的责任啊。
前半部分
1 ，这是 MSYS MinGW 的锅，它们没处理好 64 位的适配。Windows 提供了 fseeko64 的替代品 _fseeki64()，中间转换层本该做好映射支持的。
2~6 ，这就是系统 API / SDK 的锅，包括 Android
至于换语言能“解决”这些锅，本质上只是它们在标准库里面帮忙擦屁股而已。
「为什么开发环境就不能默认支持这些情况呢，难道还影响兼容性？」
开发环境当然可以默认支持这些情况，正常 POSIX 环境、正常 MSVC 环境直接写程序调用标准库 API 都没问题。
没做到默认支持，很多时候完全是疏忽 (MSYS MinGW)，或者是怕麻烦、赶进度(Android 5.0~6.0)。
后半部分
1 、若是 OS Level 的限制，编程语言本身能做的事情其实很有限。如果 OS 本身没解决 2038 问题，只要系统关机、重新开机，系统时间直接就是乱的，再完善的编程语言都没办法强行掰回来。
若 OS Level 已经解决了 2038 问题，那么无论是 C 还是 C++，都不需要担心这种事。
2 、纯 POSIX 可以。跨平台跨到 MSYS MinGW 的话，按理说 MSYS MinGW 应当处理好相应转换（像是背后处理编码调用带 W 的 API 、检测目标 Windows 有没有启用 UTF-8 区域选项），但这就不是普通使用者可以强制要求的了。
3 、这就有点霸道了，别说 C 语言、C++，哪怕是 Python 都没法如此保证。
4 、单纯“不拒绝使用”的话，那还是不需要担心。如果想要更高要求达到“表现一致”，那就不太可能了。
Linux 的 IPV6_V6ONLY 默认为 false ，而 BSD 和 macOS 还有 Windows 的 IPV6_V6ONLY 默认是 true 。
OpenBSD 更是搞起了内部限制，无论 IPV6_V6ONLY 设成什么值，它都按照 true 处理。
5 、类似 2
6 、支持近十年出厂的系统很合理。但硬件？？这可不是编程语言可以掌控的吧，这是 OS 和驱动程序的责任啊。
3 月 4 日 回复了 zhaoziling 创建的主题 › Google › 最近访问 Gemini 老是出现异常流量提示，有什么解决办法么？ |
自己建一个落地机，然后在落地机连接上大品牌的商业 VPN ，让梯子流量从这条 VPN 链路出去
1 月 21 日 回复了 Achao1121 创建的主题 › Windows › win 系统下 现在能双开微信的方法 求助 |
那就试下创建多个本地账户，然后使用 run-as （ Shift+鼠标右键，运行为）
Select Language