这是一个创建于 935 天前的主题，其中的信息可能已经有所发展或是发生改变。
自己一些粗浅的使用体验，欢迎大家批评指正。
 |
1
d16uga1l 2022-05-01 16:42:17 +08:00
真棒
|
 |
2
cmdOptionKana 2022-05-01 16:51:28 +08:00
干货满满呀
|
 |
3
icyalala 2022-05-01 16:59:41 +08:00  4
用 GNU extension 特性要慎重，这会让你代码可移植性变差。。
|
 |
5
dongcidaci 2022-05-01 18:21:39 +08:00
Linux 内核也开始支持 c11 了，想想有点小激动
|
|
6
dongcidaci 2022-05-01 18:30:42 +08:00 via Android
错误处理那一节感觉没太看懂，前后处理方式有什么区别呢，就是把错误码封装到了结构体里面吗
|
 |
7
xiri 2022-05-01 18:41:46 +08:00 via Android
@dongcidaci 前一个做法是 return 错误码，函数处理结果通过入参的指针带出，这样链式调用的话后一个函数只能拿到前一个函数返回的错误码，而没法用它的处理结果作为自己的输入；后一种做法将错误码和处理结果封装在一起 return ，可以避免这种问题
|
|
8
xiri 2022-05-01 18:46:15 +08:00 via Android
@icyalala 但是 container_of （其中用到的 typeof 关键字是 GNU C 扩展的）是真的香，将我从各种重复的链表操作中解放了出来😂
|
 |
9
Frytea 2022-05-01 19:14:52 +08:00
@dongcidaci 准确说应该是 Linux 5.18 开始采用 C11 标准，我理解是使用新标准来编译和实现，对标准的支持应该是编译器的工作呀
|
 |
10
12101111 2022-05-01 19:28:34 +08:00
cleanup 扩展 clang 没有，intel 的 iwd 用了这玩意，我移植了几次之后懒得管了，直接删了用回 wpa_supplicant
（只安装了 clang 的 Gentoo 系统） |
 |
11
codefever 2022-05-01 20:31:56 +08:00
下次如果能直接复制到帖子里就更好了
|
 |
12
secondwtq 2022-05-01 20:49:19 +08:00
虽然拿一堆 extension 来说“Modern C”有些呃呃，不过 Clang 好像老早就支持了 cleanup 啊 ...
|
|
13
secondwtq 2022-05-01 20:50:43 +08:00
另外 Clang 一直在试图和 GCC 保持兼容，社区里面好像有不止一股力量想要用这玩意编译 Kernel （ which 强依赖各种 GCC 扩展
|
 |
14
wheeler 2022-05-01 21:26:50 +08:00 via iPhone
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2391r0.pdf
typeof 看样子能进标准啊，c23 增加了不少特性。 https://en.cppreference.com/w/c/23 |
 |
15
Buges 2022-05-01 22:06:13 +08:00 via Android
C 演进的实在太慢了，zig 才能叫 modern C ，它们之间的 interoperability 近似于 Java 和 kotlin ，是真正有希望取代 C 的。
|
 |
16
lcj2class OP @12101111 #10 是不是版本比较低，clang 是支持 cleanup 的，我 macOS 上的的 clang 一直用的很好
|
|
17
12101111 2022-05-01 22:55:54 +08:00 1
@secondwtq
@lcj2class 抱歉，记错了，iwd 是 cleanup 和 gcc 的另一个扩展一起用了 https://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html 这个 gcc 扩展 clang 不支持，不过据说也有可能进 c23 |
 |
19
LotusChuan 2022-05-02 00:42:55 +08:00 3
指针那块有个很简单的区分数组指针和指针数组的方式，就是看优先级：[ ]的优先级比*高，所以 int *arr[100]是指针数组； int (*ptr)[100]是数组指针。感觉你写得有点复杂了。
|
 |
20
ecnelises 2022-05-02 00:50:46 +08:00 1
GCC 的主要扩展 Clang 都支持，其余的 Clang 处在一个随缘状态：不保证一定支持，但你要实现也没什么人反对。
滥用编译器扩展的确会影响可移植性，但两害相权取其轻，GCC 扩展的可移植性比起内联汇编和各种指令集 /操作系统强相关的自带函数还是好多了。Mac 迁移到 ARM 算是在这方面敲醒了一些人。只要把这些特定编译器的扩展封到宏 /函数里，然后对不支持的编译器加上#error ，问题不大。 |
 |
21
hronro 2022-05-02 01:16:04 +08:00
我还是更看好 Zig
|
 |
22
documentzhangx66 2022-05-02 02:10:57 +08:00
这玩意你还能写那么多，我觉得一点都不现代。
真要现代，应该能直接把易语言、Python 之类的源码，现场编译成高优化的可执行文件，然后执行，并且跨平台，还支持浏览器。 |
 |
23
zengmingyang96 2022-05-02 02:14:23 +08:00
写的很好，赞
|
 |
24
Trim21 2022-05-02 03:02:56 +08:00
"在 Go 中，会选择同一大版本下，最大的小版本"
go 选择的是最小的小版本，你看你这图里选择的是 B1.2 不是 B1.3 |
 |
25
XhstormR02 2022-05-02 08:00:41 +08:00 via Android
有介绍 zig 的吗，有啥优点
|
|
26
XhstormR02 2022-05-02 08:02:00 +08:00 via Android
|
|
28
Trim21 2022-05-02 09:59:20 +08:00
@lcj2class #27 假如有个 C1.5 呢，go 会选 C1.4 还是 C1.5 ？应该是 C1.4 吧
选“会选择同一大版本下，最大的小版本”就是 C1.5 ，“会选择同一大版本下，最小的小版本”就是 C1.4 |
|
31
cmdOptionKana 2022-05-02 10:13:14 +08:00
|
 |
32
52coder 2022-05-02 10:40:53 +08:00
我司禁止使用 gcc 扩展，只能写一些 clean c code 。
|
 |
33
zacharyjia 2022-05-02 10:42:29 +08:00
|
 |
34
Nasei 2022-05-02 12:18:36 +08:00
不太喜欢用编译器扩展
|
 |
35
waruqi 2022-05-02 12:33:40 +08:00
包管理直接用 xmake 就行了。
|
 |
36
keith1126 2022-05-02 13:04:50 +08:00
很棒的文章，学到了很多之前不了解的东西
|
|
37
Buges 2022-05-02 14:50:38 +08:00 via Android
|
|
38
hronro 2022-05-02 16:49:35 +08:00
|
 |
39
gowk 2022-05-02 17:38:22 +08:00
感谢 OP 的 SICP 库
|
 |
40
fantastM 2022-05-03 01:43:42 +08:00
楼主也是这篇文章的作者吧 https://mp.weixin.qq.com/s/zrxDgBjutbdvROQRYa3zrQ
|
 |
41
cnbatch 2022-05-03 04:53:43 +08:00
@xiri 其实 container_of 不使用 typeof 也可以实现，FreeBSD 的源码就有：
https://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 的，而且似乎是唯一一处： https://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 稍微追溯了下提交历史，这是两年前新增的： https://github.com/torvalds/linux/blob/5fbc220862fc7a53a0455ccd2d96c82141e222d4/tools/lib/bpf/bpf_helpers.h 仔细一看，原来是 BPF ，也是跟 BSD 有关的东西，或许这种写法属于“BSD-style”吧。但是跟 BSD 版本相比，bpf_helpers.h 的写法仍然更加接近于 Linux 的 typeof 版本。 |
 |
42
Bbird 2022-05-03 08:57:51 +08:00
@cnbatch #41 linux 内核源码的 container_of 没有使用 typeof 吧，全部都是三个参数的
/** * container_of - cast a member of a structure out to the containing structure * @ptr: the pointer to the member. * @type: the type of the container struct this is embedded in. * @member: the name of the member within the struct. * */ #define container_of(ptr, type, member) ({ \ void *__mptr = (void *)(ptr); \ ((type *)(__mptr - offsetof(type, member))); }) |
|
44
cnbatch 2022-05-03 13:54:10 +08:00
@Bbird 重新下载了新的内核代码树看了下，确实是这样。很久以前看的时候他还是 typeof ，搞得我以为现在还是。原来现在甚至还有专门的 container_of.h ，方便了不少
|
|
45
cnbatch 2022-05-03 14:01:53 +08:00
@Bbird 现在的 container_of 去掉了 typeof ，但我想不到风格还是跟原来的差不多，依旧是先来一个变量赋值，下一行再做减法，并且仍然需要大括号。
虽然终于不再依赖 typeof ，但相比之下，我仍然更喜欢 BSD 的那种。同样的效果，却更加简洁、易懂。 按道理，GPL 代码照抄 BSD 是完全可以的。 |
 |
46
iClass 2022-05-03 17:56:31 +08:00 via Android
和 C 一起出生的人 我叫 IC
|
 |
48
lijiangang886 2022-05-06 08:05:21 +08:00
取代 C 这种伟大的事业，一听就是没可能做到的样子
|
Select Language