liujiacai.net/blog/2022/04/30/modern-c/

自己一些粗浅的使用体验，欢迎大家批评指正。

真棒

干货满满呀

用 GNU extension 特性要慎重，这会让你代码可移植性变差。。

同意，我在 Mac 上直接 clang ，extension 就❌了

Linux 内核也开始支持 c11 了，想想有点小激动

错误处理那一节感觉没太看懂，前后处理方式有什么区别呢，就是把错误码封装到了结构体里面吗

前一个做法是 return 错误码，函数处理结果通过入参的指针带出，这样链式调用的话后一个函数只能拿到前一个函数返回的错误码，而没法用它的处理结果作为自己的输入；后一种做法将错误码和处理结果封装在一起 return ，可以避免这种问题

但是 container_of （其中用到的 typeof 关键字是 GNU C 扩展的）是真的香，将我从各种重复的链表操作中解放了出来😂

准确说应该是 Linux 5.18 开始采用 C11 标准，我理解是使用新标准来编译和实现，对标准的支持应该是编译器的工作呀

cleanup 扩展 clang 没有，intel 的 iwd 用了这玩意，我移植了几次之后懒得管了，直接删了用回 wpa_supplicant

（只安装了 clang 的 Gentoo 系统）

下次如果能直接复制到帖子里就更好了

虽然拿一堆 extension 来说“Modern C”有些呃呃，不过 Clang 好像老早就支持了 cleanup 啊 ...

另外 Clang 一直在试图和 GCC 保持兼容，社区里面好像有不止一股力量想要用这玩意编译 Kernel （ which 强依赖各种 GCC 扩展

www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2391r0.pdf

typeof 看样子能进标准啊，c23 增加了不少特性。

en.cppreference.com/w/c/23

C 演进的实在太慢了，zig 才能叫 modern C ，它们之间的 interoperability 近似于 Java 和 kotlin ，是真正有希望取代 C 的。

＃10 是不是版本比较低，clang 是支持 cleanup 的，我 macOS 上的的 clang 一直用的很好

抱歉，记错了，iwd 是 cleanup 和 gcc 的另一个扩展一起用了 gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html

这个 gcc 扩展 clang 不支持，不过据说也有可能进 c23

＃15 慢不是坏事，慢工出细活。C++ 倒是演进得快， 但发展到现在已经太臃肿了。

指针那块有个很简单的区分数组指针和指针数组的方式，就是看优先级：[ ]的优先级比高，所以 int arr[100]是指针数组； int (*ptr)[100]是数组指针。感觉你写得有点复杂了。

GCC 的主要扩展 Clang 都支持，其余的 Clang 处在一个随缘状态：不保证一定支持，但你要实现也没什么人反对。

滥用编译器扩展的确会影响可移植性，但两害相权取其轻，GCC 扩展的可移植性比起内联汇编和各种指令集 /操作系统强相关的自带函数还是好多了。Mac 迁移到 ARM 算是在这方面敲醒了一些人。只要把这些特定编译器的扩展封到宏 /函数里，然后对不支持的编译器加上＃error ，问题不大。

我还是更看好 Zig

这玩意你还能写那么多，我觉得一点都不现代。

真要现代，应该能直接把易语言、Python 之类的源码，现场编译成高优化的可执行文件，然后执行，并且跨平台，还支持浏览器。

写的很好，赞

"在 Go 中，会选择同一大版本下，最大的小版本"

go 选择的是最小的小版本，你看你这图里选择的是 B1.2 不是 B1.3

有介绍 zig 的吗，有啥优点

zig 跟 rust 比有什么有什么优点吗

＃24 B 没有冲突，有冲突的是 C ，Go 选择的是 C1.4 ，而不是 C1.3

＃27 假如有个 C1.5 呢，go 会选 C1.4 还是 C1.5 ？应该是 C1.4 吧

选“会选择同一大版本下，最大的小版本”就是 C1.5 ，“会选择同一大版本下，最小的小版本”就是 C1.4

＃27 而且 C 依赖也没有冲突 - -

＃28 哦我明白你的意思了，你这句话的范围是 gomod 里面写的版本号，不是 pkg 发布的版本号

你说的是未来，不是现代。

已经实现的，才叫现代；你说的目前还没有实现，未来才能实现。

我司禁止使用 gcc 扩展，只能写一些 clean c code 。

zig 的开发进度实在是太慢了，之前看开发团队说预计 1.0 要到 2025 年🤨直接就丧失兴趣了

不太喜欢用编译器扩展

包管理直接用 xmake 就行了。

很棒的文章，学到了很多之前不了解的东西

定位不一样，rust 是 modern C++，追求安全、抽象，zig 是 modern C ，追求简单、直接。
详细了解直接去官网看 ziglang.org/

＃26 ziglang.org/learn/why_zig_rust_d_cpp

感谢 OP 的 SICP 库

楼主也是这篇文章的作者吧 mp.weixin.qq.com/s/zrxDgBjutbdvROQRYa3zrQ

其实 container_of 不使用 typeof 也可以实现，FreeBSD 的源码就有：
github.com/freebsd/freebsd-src/blob/main/sys/dev/cxgb/cxgb_adapter.h

代码是：
＃define container_of(p, stype, field) ((stype )(((uint8_t )(p)) - offsetof(stype, field)))

有意思的是，Linux 源码当中也有不用 typeof 来 define 的，而且似乎是唯一一处：
github.com/torvalds/linux/blob/master/tools/lib/bpf/bpf_helpers.h

＃define container_of(ptr, type, member) \
({ \
void __mptr = (void )(ptr); \
((type *)(__mptr - offsetof(type, member))); \
})
＃endif

稍微追溯了下提交历史，这是两年前新增的：
github.com/torvalds/linux/blob/5fbc220862fc7a53a0455ccd2d96c82141e222d4/tools/lib/bpf/bpf_helpers.h

仔细一看，原来是 BPF ，也是跟 BSD 有关的东西，或许这种写法属于“BSD-style”吧。但是跟 BSD 版本相比，bpf_helpers.h 的写法仍然更加接近于 Linux 的 typeof 版本。

＃41 linux 内核源码的 container_of 没有使用 typeof 吧，全部都是三个参数的

/**

• container_of - cast a member of a structure out to the containing structure
• : the pointer to the member.
• : the type of the container struct this is embedded in.
• : the name of the member within the struct.
  *
  */

＃define container_of(ptr, type, member) ({ \
void __mptr = (void )(ptr); \
((type *)(__mptr - offsetof(type, member))); })

＃41 较早的内核代码用了 typeof , 新的去掉了

重新下载了新的内核代码树看了下，确实是这样。很久以前看的时候他还是 typeof ，搞得我以为现在还是。原来现在甚至还有专门的 container_of.h ，方便了不少

现在的 container_of 去掉了 typeof ，但我想不到风格还是跟原来的差不多，依旧是先来一个变量赋值，下一行再做减法，并且仍然需要大括号。
虽然终于不再依赖 typeof ，但相比之下，我仍然更喜欢 BSD 的那种。同样的效果，却更加简洁、易懂。
按道理，GPL 代码照抄 BSD 是完全可以的。

和 C 一起出生的人 我叫 IC

zig 也不少年头了，影响力太小了