@FanError 针对原生 M1 的版本确实没出，只能靠转译

Outlook 共享邮箱的详情可见这里：
support.microsoft.com/zh-cn/office/%E5%9C%A8-outlook-%E4%B8%AD%E6%89%93%E5%BC%80%E5%92%8C%E4%BD%BF%E7%94%A8%E5%85%B1%E4%BA%AB%E9%82%AE%E7%AE%B1-d94a8e9e-21f1-4240-808b-de9c9c088afd

不清楚你的环境是怎么样，我在公司内部试过是可以获取发件人，唯一例外的情况是发件人以共享邮箱的身份发邮件

如果是普通的发送方式，是可以正确获取的，就以 find_unread_messages.cpp 为例修改：

原文件的 for (const auto& id : item_ids) 里面的内容，改为

for (const auto& id : item_ids)
{
auto msg = service.get_message(id);
auto mail_address = msg.get_from();
std::cout << mail_address.value() << "\n";
}

如果专指狭义上的 VPN ，那么可以用 OpenVPN
https://openvpn.net/client-connect-vpn-for-mac-os/

如果不想自己搭建而是想一键连接，那么可以买 ExpressVPN 服务

啊，不好意思，mail_attachment 我忘了补全进来。

auto mail_attachment = ews::attachment::from_file(R"(D:\picture.png))", "image/png", "picture.png");

第二个参数可以按照注释的指引，在注册表里面找

如果要发送中文电邮，假设用的是 Visual Studio 做开发环境，那么需要以下更改：

1 、cpp 源代码文件的编码需要设置成 UTF-8 （文件->另存为->“保存”按钮旁边的三角形->编码保存->UTF-8 ）
2 、打开项目属性，按照这个说明改设置：
https://docs.microsoft.com/zh-cn/cpp/build/reference/utf-8-set-source-and-executable-character-sets-to-utf-8

gsoap XML 操控 ews 实在太弯弯绕绕了，而且由于许可证原因（ GPLv2+商业授权），我没法在我所在的公司环境内测试。

我用以下代码在公司环境里发送图片附件，试过了没问题。用的是 ews 自己的测试代码+小修改：

//const auto env = ews::test::environment(); //由于我会指定内部 ews 服务器，所以注释掉 env
auto service = ews::service("https:// *********", "", "",""); // 我所在的公司启用了 SSO ，所以不用输入用户名和密码

auto message = ews::message();
auto mail_subject = "Test mail from application";
message.set_subject(mail_subject);
std::vector<ews::mailbox> recipients;
recipients.push_back(ews::mailbox("[email protected]"));
message.set_to_recipients(recipients);
auto text = ews::body("Welcome!\n\nThis is a test.\n");
message.set_body(text);

auto mail_attachment = ews::attachment::from_file(R"(D:\picture.png))"); // 自己指定文件路径
auto mail_id = service.create_item(message, ews::message_disposition::save_only);
service.create_attachment(mail_id, mail_attachment);
auto search_expression = ews::is_equal_to(ews::item_property_path::has_attachments, true);
ews::distinguished_folder_id drafts = ews::standard_folder::drafts;
auto ids = service.find_item(drafts, search_expression);

for (auto &ids : ids)
{
auto msg = service.get_message(ids);
for (auto &reciver : msg.get_to_recipients())
{
std::cout << reciver.value() << "\n"; // 收件人邮箱逐个显示出来
}
if (msg.get_subject() == mail_subject)
{
service.send_item(id);
break;
}
}

先用纯英文字符的内容去试。

@FrankHB “说人力不够我懂，不过这不就是承认了没充分 review 过而没法解决问题嘛”

对呀，这不正正印证了我说的“就这种窘况”。哪有什么承认不承认呢，这个窘况是活生生的现实，都不需要特意去承认或者否认。对于来自外面的代码，尤其是来自于又长又臭 bug 又多的 freedesktop ，换成是我，我也没那么多动力去好好地 review ，能用就行，多一事不如少一事。说实话，对于各 BSD 基金会而言，基本上都处于有求于人（大白话：看别人脸色）的地位，就连代码管理也不例外。多年前 FreeBSD 、OpenBSD 曾经分别喊穷求救，我也多少有点理解为什么他们对外来代码照单全收。责怪也没用，正经做法是帮他们解决资金问题（这难度……不是一般人能做到）

不过也好，这个提醒让我也看到了 __containerof 挺不错。

上班：大约 三成 C#、三成 C++，剩下的几乎都在 scripting (powershell + cmd bat)
pwsh 这个写得我头大，写完经常就忘

下班后自己的 Github：88% C++，11.5% C#

@cnbatch 澄清：
「这种大背景下跟他们急？得到的只会是“让自己距离高血压又进了一步”」
此处的“他们”是指代“移植 drm 的那群人”

@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 ，这就表明了态度。