这个新界面简洁是简洁，但菜单栏可以手动重新调出来吗？

顺便说说我用 cpp 的原因。非常简单，跟内存无关，单纯就是看中“实时”的 RAII 和模板（仅限简单的通用模板，黑科技骚操作我也写不来）。一般来说用 C++的依然需要跟 C 打交道，就算用到 C++23 照样如此，如果经常需要跟底层打交道（前提是“经常”），那么这方面的理解能力也不会差的。

为什么要给 RAII 加上“实时”两个字呢，因为十年前我被 C# 的垃圾回收坑过。C# 也有 RAII ，也有析构函数，但由于垃圾回收的存在，作用域结束后并不保证立即执行析构操作。而 C++ 保证立即执行。

C# 虽然真的很顺手，但析构函数这一块我是被坑怕了。不知道现在最新的 C# 能不能保证立即执行，只是我已经不敢再用 C# 的析构了。至于为什么不完全转向 rust ，那是因为我从 C# 跑到 C++ 的时候，rust 才发布没多久。

@pastor 主要是楼层盖到那么多以后，想要认真看完每一层楼、每一段代码实在太费神了，这种情况下扫一眼后觉得思路顺眼就点赞，其实不算奇怪。毕竟对于这种容易造成吵架的主题帖，越到后面就越是磨掉看贴人的耐心。
让我意外的是，第一页中后段语言律师洋洋洒洒连续写了 4 贴长文字，实属罕见。

@pastor 其他人就不知道了。

就说我自己吧，上面那么多回复我还没有全都看完，我个人关注点全在 FreeBSD 和 Linux 对 container_of 的态度区别。

auto p = list_head(&head);
右边的 & 符号是取址，一直以来都没变化，到了 C++20 依然还是取址（不考虑运算符重载）

也没有什么“转换成左值引用”这种说法吧，只听过“转换成右值引用”，没见谁说过“转换成左值引用”。你提到的“左值引用”的是指 int &re = other 这种吧，这种就是 C++98 以来的常规引用，不需要也没人会讲“转换成左值引用”。

区分很简单，单个 & 的语义从 C++98 以来都没变化。两个 & 的时候才是跟右值引用有关。左值引用跟右值引用的区分直接看 & 的数量就行。

先试试把路由器拨号 Mac 地址弄成跟原先光猫的一样，看看“Mac 地址欺骗”法能不能改善

@FrankHB 我后来也想起({})也是扩展，显然一旦长时间习惯 GNU 扩展的坏处，就是连眼睛看见后都忘了“这是扩展”。这确实不是什么好事。

另外关于 FreeBSD 的 container_of ，实际上 FreeBSD 自己并不用这种东西，它里面使用到 container_of 的只有极个别驱动（其中一些或许是从 Linux 版本移植过来的，例如 nvidia tegra 的驱动，当然了我没同步对比过，所以只能讲“或许”），以及 Linux 相关的东西（比如 Linux 兼容层、OpenZFS 跟 Linux 共用的部分文件）。

由于 FreeBSD 自己不用 container_of ，因此它也没必要专门弄一个 container_of 文件。但既然外来的代码要用，那就只能局部使用，不能让 container_of“污染”整个 FreeBSD 内核树。

其实不难理解他们为什么不喜欢用 GNU 的扩展，FreeBSD 早在十年前就把默认编译器从 GCC 换成了 Clang ，这就表明了态度。

@cnbatch #63 我还是一时大意了，实际上新版 container_of 写法仍然还是用了 GCC 内置扩展 __same_type

@iamzuoxinyu 需要强制检查的时候，FreeBSD 部分地方仍然提供了依赖扩展功能 typeof 的的版本

https://github.com/freebsd/freebsd-src/blob/main/sys/dev/drm2/drm_os_freebsd.h

#define container_of(ptr, type, member) ({ \
__typeof( ((type *)0)->member ) *__mptr = (ptr); \
(type *)( (char *)__mptr - offsetof(type,member) );})

两者的差异就在于是否想彻底实施 C 语言的“哲学”：相信程序员

既然有人提到了 container_of ，刚好几个星期前在另一个帖子就聊过，我觉得可以再把例子拿出来说一次。

先来看看 Linux 最经典的用了 GCC 内置扩展的写法：

#define container_of(ptr, type, member) ({ \
const typeof(((type *)0)->member) * __mptr = (ptr); \
(type *)((char *)__mptr - offsetof(type, member)); })

来源： https://github.com/torvalds/linux/blob/master/tools/include/linux/kernel.h


然后是最新的 container_of ，经过多年进化，新版本已经不需要用 GCC 内置扩展：

#define container_of(ptr, type, member) ({ \
void *__mptr = (void *)(ptr); \
static_assert(__same_type(*(ptr), ((type *)0)->member) || \
__same_type(*(ptr), void), \
"pointer type mismatch in container_of()"); \
((type *)(__mptr - offsetof(type, member))); })

来源： https://github.com/torvalds/linux/blob/master/include/linux/container_of.h


相信不少人已经相当熟悉了，它的具体原理没必要再解释。



换换口味，再来看看 FreeBSD 的写法：

#define container_of(p, stype, field) ((stype *)(((uint8_t *)(p)) - offsetof(stype, field)))

来源： https://github.com/freebsd/freebsd-src/blob/main/sys/dev/cxgb/cxgb_adapter.h

一目了然，简洁易懂。


所以说，想要同时兼顾“更易理解”、“更少行数”，总会有办法的，尽管可能需要等很多年。

主题所讲的从教科书到 Linux 手动优化，显然也是教科书的做法出现得最早。所以或许以后会有人想得出更易理解但行数也不多的写法吧。

ge_message(id)之后可以获得每个 message ，而每个 message 可以用 get_body()获取 HTML 内容，或者用 to_xml()获取原始 XML 内容。至于获取后怎么解析，那得自己找 HTML 解析工具。

至于图片，其实每个内嵌图片都是内联附件，messge.get_attachments()可以获取完整附件列表，包括内联附件和普通附件。内联附件用 is_inline()可以判断出来。
只不过 ews-cpp 的兼容性有限，未必能正确读取附件内容。

微软自家 C# 版本 EWS 库兼容性好得多，功能也多得多，只不过它也不能干 HTML parse 的工作，拿到邮件内容后也只能把邮件各部分内容提取出来，步骤也是类似的，顶多提取成功率比 ews-cpp 高得多，API 也多一些。

在 IDE 里面对着各种函数都不妨试一试，只要不是写操作，都不会有什么影响。

看一看路由器有没有双 WAN 功能，有的话就打开，这样就能一个路由器同时用两条宽带了。
没双 WAN 功能的就换个支持双 WAN 的路由器。

如果有 4 口或 6 口的软路由那就更简单。

接口 1 连宽带 A ，接口 2 连内网 A （假设是 192.168.10.0/24 ），设置成内网 A 经过宽带 A 出站
接口 3 连宽带 B ，接口 4 连内网 B （假设是 192.168.20.0/24 ），设置成内网 B 经过宽带 B 出站

正常来说，两个内网这样就可以相互访问，如果不通，软路由配置一下路由表就行。

@w20011025 https://github.com/otris/ews-cpp/blob/master/examples/find_unread_messages.cpp

有现成的库可以用：
https://github.com/otris/ews-cpp

仅仅用于发邮件、收邮件的话，基本够用。

如果是想用在内网环境，例如企业内网 EWS 服务器的话，有可能必须加上预处理宏 EWS_DISABLE_TLS_CERT_VERIFICATION

当然了，这个库跟微软自己的 C# 版的 EWS 库相比，差得远了

想要压榨极限网络性能？那么可以考虑用 io_uring

恭喜塞尔维亚 Gov 又从 Rust 语言相关域名获得收入

@hokori 倒不是说显示屏有问题，而是它很接近我个人偏好但还没有 100%达到，所以一旦选无可选（还在尝试找），索尼基本就是唯一选择

@IslandOwnerHuang 连快充的充电控制都有点问题，去年换电池时发现鼓包的痕迹，基本可以确定是过充造成的，想不到雷蛇手机的过充控制这么差（这么看来它的 USB 充电确实很容易就完蛋）

@Evovil 想不到连输入法都能造成影响😲

感觉 SSH X11 这事有点玄学的味道了

@wangyuescr 当时在谷歌搜索“南京大 TS”（ Tu Sha 的汉字），就会遭到即时的 HTTP Reset ，然后在接下来的几分钟内都打不开谷歌，需要几分钟后才能重新打开。

其实只要搜索词内包含关键字，都会遭到 Reset 。

当年“南京大 TS”导致页面 Reset 这件事被百度水军和部分百度爱好者拿来“证明”谷歌故意屏蔽，不少人还真的信了，而实际上却跟那群人的“证明”相反，是因为“大 TS”刚好是关键词所以遭到阻断。

至于围绕“抗战主力中流砥柱”的地位争论，两岸一直各说各话。“习连会”后稍有缓和，但没多久又恢复各执一词的原状。