
别说 STD 和 C++11+ 了,class, template 都用不了,完全束手束脚的感觉,要怎么适应呢?
1 tool2d 2023 年 6 月 8 日 写 C++代码,然后源码转译到 C 代码。 |
2 zhuangzhuang1988 2023 年 6 月 8 日 学习 libuv mruby libgit2 的代码 |
3 koebehshian 2023 年 6 月 8 日 嵌入式表示,有时连 malloc 都用不了 |
4 duke807 2023 年 6 月 9 日 via Android c 写面向对象没啥问题,参考 linux kernel 的 container_of 方式。 譬如看一下我这个目录的 mcu 代码,其中有好几种驱动,它们都基于同一个子类型: https://github.com/dukelec/cdnet/tree/master/dev template 没啥用,需要的话用宏定义就行,还可以配合 typeof 和新的 _Generic 关键字 |
5 duke807 2023 年 6 月 9 日 via Android @koebehshian 我喜欢把数组转成链表,用来做固定大小的内存分配,不担心实时性和内存碎片 譬如这个文件开头的 init 函数: https://github.com/dukelec/cdcam/blob/master/cam_fw/usr/app_main.c |
6 cnbatch 2023 年 6 月 9 日 @duke807 OP 特意强调“ANSI C”,很大可能性是 C89 ,想用_Generic ?不存在的。搞不好连 for 循环第 1 个分号前的初始化语句都不能声明变量。 如果真的是 C89 ,那就属于是连 Linus 都不得不抛弃的版本。 |
7 cnbatch 2023 年 6 月 9 日 同情 OP 。 说实话,我也很难适应这么老旧的语言标准,无论是 C89 还是 C++98 。 因为我很不爽这两个旧标准,以至于很长时间内我都泡在 C# 生态当中,连 QT 都不想碰。直到后来无意中被所谓的“析构”(Finalizers) “坑”了一把(毕竟写 Dispose 实在嗦)。 恰好,此时 C++11 和 C11 已经发布了,我一看新内容,还好能够接受。于是工作以外的场景就重新入门了。 工作场景仍然是 C# 为主(我没换工作),但工作时的自用工具会尽量用新标准 C++去写(能 C++就 C++,我懒),除非遇到公司的老旧 RHEL 只提供 GCC4.8 那才没办法,还好可以用大部分 C11 特性(其他组淘汰给我们当玩具的,没多久就清理掉了)。 经历过新标准的爽快被迫再退回去几十年前的标准,我很理解 OP 的心情。 换成是我,那就只能先用 C++写一遍具体代码,然后转写成等效同年份 C 代码,再根据编译器的错误提醒,进一步回退到 C89 。 |
8 slowman 2023 年 6 月 9 日 硬着头皮,扛过去就好了。。 |
9 hanxiV2EX 2023 年 6 月 9 日 via Android lua 源码还是 ansi c |
10 ederodan 2023 年 6 月 9 日 往好处想这是是一个提高自己内存管理能力的好机会 |
11 tairan2006 2023 年 6 月 9 日 用 GObject? |
12 cstj0505 2023 年 6 月 9 日 同时在写 java ,c ,sql ,放平心态就好,c 就不要想着快速出活,对自己编码和算法细节的打磨很重要 |
13 yolee599 2023 年 6 月 9 日 via Android C 挺好的,可以慢慢研究 |
14 zhyl 2023 年 6 月 9 日 写 vlang ,然后编译成 c 代码 |
15 aa514758835 2023 年 6 月 9 日 确实不方便,可以在 github 上先正好三方基础库,老外写的纯 c 的基础库很不错的,有脚手架,就好干活了 |
16 minami 2023 年 6 月 9 日 glib 一把梭,除了嗦基本啥都有 |
17 m1a0 2023 年 6 月 9 日 返璞归真, 挺好的, 适应了就好。 |
18 LXGMAX 2023 年 6 月 9 日 自动挡换手动挡自然要熟悉适应 |
19 lovelylain 2023 年 6 月 9 日 via Android 是机器上没有 c++运行库还是项目代码是纯 c ,后者的话用 c++实现功能编译成 so 给 c 调用。 |
20 hpepper 2023 年 6 月 9 日 能否添加个联系方式 我这有个 c++的问题,可以有偿。 |
21 w1lu0bOo OP 感谢那么多回复。 |
22 w1lu0bOo OP 我先理一理…… |
23 koebehshian 2023 年 6 月 10 日 @duke807 我之前也是,喜欢用静态变量,类似于内存池自己管理,但这只适用于业务逻辑比较简单或内存充足的场景。 我碰到业务逻辑复杂且内存少的情况,就必须动态分配了。比如有 10 个功能,用户可能只用1个功能,也可能用2个,不确定,这是由用户动态配置的,编译时是确定不了的。 每个功能涉及到的结构体的长度不同的,如果用联合体就比较浪费,如果分别预先定义最大长度,更加浪费,导致每个功能的最大负荷降低。 |
24 macha 2023 年 6 月 10 日 如果是老项目的话,基本上常用的轮子都有了,学习一下他们的套路就行了。 新项目的话,直接换语言吧。 C 语言实在不适合写业务太复杂的项目。 最适合那种精雕细琢的项目,扣内存,扣 CPU ,扣字节,深扣一切。。。 |
26 w1lu0bOo OP @zhuangzhuang1988 嗯嗯,找一些库学习一下是个好路径 |
30 w1lu0bOo nbsp; OP @tairan2006 嗯,有些建议是用 glib ,不过要拖入一堆依赖,不知道大项目 maintainer 会不会同意 |
32 w1lu0bOo OP @zhyl 感谢信息。 看它官网有一句 "V can be bootstrapped in under a second by compiling its code translated to C with a simple..." 实际使用上转成 C 语言有没有什么局限性呢? |
33 w1lu0bOo OP @aa514758835 嗯嗯,不知道有没有比较广泛使用的替代 C++11/14/17 的高级语法? 大几年没写 C 了。 |
36 w1lu0bOo OP @lovelylain 主要是运行环境( flash )都容不下一个 libstdc++.so 的运行库 。。。。 嗯嗯,C++暴露出 C 接口是一个好路径 |
37 w1lu0bOo OP @koebehshian 那大概率是没有 OS 的场景吧? malloc 都没有 /(ㄒoㄒ)/~~ |
40 cnbatch 2023 年 6 月 12 日 如果能用 C11 ,那么不少特性都能继续保留 比如 std::atomic thread_local static_assert bool 只不过需要加下划线 https://en.cppreference.com/w/c/99 https://en.cppreference.com/w/c/11 |
41 zhyl 2023 年 6 月 13 日 @w1lu0bOo #32 可能内存管理这方面要注意,vlang 的内存管理模式在编译的时候指定,分为自动 gc ,自动插入 free ,以及手动管理。之前尝试的时候内存管理这块还没解决,不知道现在如何了,还会不会在自动 gc 或 free 时有内存泄漏的问题。 |
43 iceheart 2023 年 6 月 28 日 via Android 只是 libstdc++库依赖的问题?可以链接静态库版本啊。 |