@FrankHB
原因很简单，container_of 一开始就靠 GCC 的私有扩展，并且长期以来都依赖于 GCC 私有扩展，而 FreeBSD 又有 GPLv3/GCC 洁癖，这种情况下 container_of 再流行，他们也不会愿意全局地加进去的。除非 container_of 能够转正变成标准的一部分，那他们就会迅速采用。

相反的案例也有，NetBSD 就没有 GPLv3/GCC 洁癖，核心代码树里面大量使用 container_of 。


“更应该自己做”
不得不说，这有点站着说话不腰疼的味道。
FreeBSD 团队当然想自己做，问题是论人力规模、资金支持，他们都没有 Linux 那么丰富。须知道，正是因为人少钱少，FreeBSD 连 WiFi 5 (802.11ac)的支持都不完善，直到去年才请来了专人（并且只有 1 人）完善 WiFi 5 的支持。WiFi 6 就更不用说了。

就这种窘况，真敢“多拆个文件吧”？先不管会不会惹毛移植 drm 的那群人，整理文件也是需要额外的时间精力，刚刚说了，人手本来就不多。
如果站在 FreeBSD 团队的角度来看，以大白话来说那就是：反正是别人给的，烂就烂吧。

对于来自 freedesktop 的外来物，我觉得这种处理方式既然无可厚非，也无可奈何。反正 freedesktop 已经不是第一次被人说烂 /摆烂的了，早期 wayland 的“烂”连 V2EX 都有人吐槽（ https://v2ex.com/t/430734 ），更不用说 wayland 到现在依然还没完成 FreeBSD 的移植。
这种大背景下跟他们急？得到的只会是“让自己距离高血压又进了一步”。

至于这个 drm 为什么会出现在 man page ，这又是一个历史遗留，比如 Arch Linux 还保留了这个痕迹：
https://man.archlinux.org/man/drm.7.en

为什么不单独拆出来放到在 Freebsd 自己的 wiki 里面呢？那就又回到刚才说过的——人少。


FreeBSD 在代码管理、用户需求管理方面的各种“妥协”，真追究起来都可以发现是指向同一个源头：钱少。


至对于我为什么从 C# 转向 C++ 那个表述，不好意思，我所讲的“实时”并不是指 real-time operating system 的那个实时。也许我当时用“接着就立即”可以让你不会误解吧。

@FrankHB container_of 对于 FreeBSD 来说还真的不是“通用代码”，那当然是只能丢在“具体业务模块里面”。

FreeBSD 的这个 drm 文件，实际上它来自于 freedesktop.org ，显然这个文件是移植过来给 FreeBSD 做适配。
https://www.freebsd.org/cgi/man.cgi?query=drm&sektion=7&manpath=freebsd-release-ports
连他们自己的帮助页面都说得很清楚，遇到 bug 就找 freedesktop ，不关 FreeBSD 团队的事。

源码全文原封不动照搬肯定不可能，毕竟不少 API 都是各家特有的，那肯定要根据目标系统去改。然而给 drm 做移植的那些人当然是能省事就省事，来自 Linux 的代码和习惯看得出能搬就搬，显然他们很想用 container_of 。但是 FreeBSD 自己不用 container_of ，更别说公共头文件了。所以这样只能单独提供在 drm 项目文件里面。其他类似的“Linux 提供了但 FreeBSD”的 #define 同理。Linux 虽然很流行，但也不能强行要求其他开源系统全盘提供 Linux 的“公共文件”呀。

如果因为这种文件存在于官方代码树里面就认为是 FreeBSD 自己的人来写，那还是不要觉得理所当然，“外部团队专门给 FreeBSD 移植或定制”的代码可不少，他们写完后都是合并到 FreeBSD 官方代码树里面的。

至于里面合并进来的代码各种版面问题，FreeBSD 团队不可能具备 Linus 那样的脾气苛责贡献者。能有第三方驱动合并进来就谢天谢地了，哪有脾气苛责驱动贡献者？过于苛责的后果可以看 OpenBSD ，驱动支持比 FreeBSD 更少。
（站在外部贡献者立场说“大白话”就是：我能给你写驱动都算你走运了，你要是把我惹烦的话，以后我就不理你）


回到 container_of 本身，就以“肥宅快乐水”来打比方。

Linux 就好比：
大家几乎都喜欢喝肥宅快乐水，于是就主动在公共区域放置了汽水柜，想要的就去拿。极少数人喜欢不同口味或品牌的，就在自己桌子上单独放其他种类的。

FreeBSD 就好比：
大家都不爱喝肥宅快乐水，所以公共区域就不会放置汽水柜。有个别外包的驻场团队喜欢喝，那就在只放在他们自己的桌子上，没必要放在公共区域。至于因此造成部分团队桌面过于杂乱，那就是这些团队自己的事情了。





至于“左值引用”……我就是因为知道它已经很传统了所以特意表明“没谁会特意这样提”，如果你真要强调的话……我觉得其实你是想跟前面的那位用户讲，要不单独隔个楼然后直接 at 一下给对方？

我可不想一边重新解释汉字语言表达、一边处理编程语言历史时间线。如果你很还想提的话，欢迎另起一层单独讲，没必要 at 我。

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

顺便说说我用 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 充电确实很容易就完蛋）