@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”刚好是关键词所以遭到阻断。

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

尴尬，有个地方稍微说得不太完整。

"x11 转发最初不是为图形界面而设计的，所以一旦转发图形界面就会有效率问题。"

这句应该这样讲

"ssh 转发最初不是为图形界面而设计的，所以一旦转发 x11 图形界面就会有效率问题"


我当时只顾着看 PuTTY 的 Connection 各项设置都把自己搞糊涂了。


然后我又意外发现开启 /关闭 SSH 压缩原来也会对图形性能带来影响，估计是因为数据量大并且吃 CPU 性能，如果 CPU 太忙，或者 CPU 单核性能不太好的话，一压一解双重负担造成 X11 转发性能下降。

以快速刷页面甚至看视频为例，开启压缩的表现是，幻灯片滚动得比较快一点，但键鼠操作会有一点迟滞感，同时 CPU 风扇转得挺厉害；关闭压缩后的表现是，依然还是幻灯片，但出现了窗帘效应（画面刷新从上往下滚），键鼠响应是快了点但没什么用，我按个右键时，菜单上部确实很快就出现了，但接下来的画面却是幻灯片式刷出来……

我是用公司给的旧电脑（ X260 ，i5-6300U + 16G RAM ）连接 4K 显示器做试验的，Win10 20H1 。
（要不是我工作用的台式机才 8G RAM ，肯定不会去领取这种电脑。对，公司够抠门的，我自己家的电脑再烂都不会这样）
今天已经退了回去，重新申请在公司服务器上给我开个 Linux 虚拟机。

进一步证实 SSH 确实不适合转发图形界面。

@LotusChuan 不止语言宗教战争，还有框架宗教战争、IDE 宗教战争、操作系统宗教战争、许可证宗教战争。

v 站稍微好一点，只是用户自发聊起来。

某个 O 开头的开源资讯站(同时也是国内 git 托管公司)那边就不一样了，是由内部员工亲自发起这类宗教大战，不止发布开源软件新闻、行业新闻时会有意无意地这样做，甚至会以编辑部的名义亲自撰写这类大战文章，生怕没人吵架带不来流量。我原本打算单独发贴说 oschina 的事情的，结果刚发出来没多久就被一个疑似 o 站的员工 at 了下站长，要站长转水。于是我索性自己移到“水”算了，免得以后被人搞针对。接下来我特意搜了下，原来 o 站在这里有专门的官方号，不知道是不是相互有合作，所以不让说。

@zxxufo008 不是指边框，而是指显示屏本身

我专门翻过 Xperia 1 的各种测评文章，他们都有真机实拍图，特意观察过 Xperia 1 的显示屏四角看起来像纯直角，但其实还是圆的

机身边框四角圆不圆我并不介意的，介意的是显示屏