众所周知,相对于 Python 、Java 、Go 、JavaScript 等语言,C 语言有一个非常精简的标准库。这就使得在使用时往往有许多标准库完成不了的需求:国际化、JSON 解析、HTTP 请求、异步 I/O……
其实 Rust 等语言也有这样的问题。但偏偏糟糕的是,C 没有一个良好的包管理器和集中的包仓库(尽管 conan 、vcpkg 、CPM 在努力了,但想用它们一览所有包还是不现实),这使得寻找需要的库变得异常艰难。尽管存在 awesome-c 这样的列表,但从浩如烟海的列表中找出一个稳定性、流行度、维护良好、文档完善的库无异于大海捞针。一个例证是很多 C 项目最终会选择直接自己实现一些功能模块。
关于此现象,受到 blessed.rs 这个项目的启发,我创建了一个名为 Blessed C 的项目。它本质上是一种精心遴选的 Awesome List:将库以用例分类,选出每个类别中维护最积极、最流行甚至已成为事实标准的一个库(理想情况下)或几个库。
blessed.rs 的副标题是「一个非官方的 Rust 生态指南」,我也大言不惭地叫它「现代 C 生态系统使用指南」了,哈哈。
这样,当一个 C 新手询问你「 XXX 功能用什么库」的时候,你就可以把链接甩给 Ta ,告诉 Ta 不要自己造轮子了。
链接在这里,目前暂时部署在我的 GitHub Pages 上:https://w568w.github.io/blessed-c/。
ps:我不是专业的 C 程序员,其中一些我也不了解的领域则是从 awesome-c 等项目中人工挑选或是利用 Google 等搜索引擎搜索得到的。如果你认为有更好的库或者有的选择明显存在我的个人偏见,欢迎在本帖下回复介绍或者直接 GitHub 上提 issues 。
我的仓库地址:https://github.com/w568w/blessed-c/。欢迎 star 。
1
tool2d 306 天前 1
github 上的项目,C 语言应该是存量最多的,想找什么直接搜关键词,大概率能找到合适的。
这种推荐,大神不会去参考,小白也不会去用。普通人看到茫茫多的 C 代码,也只能劝退。 C 的爱好者,一般都是希望了解底层运行原理,但是你不自己造一个轮子出来,又怎么能了解原理呢。 |
2
w568w OP @tool2d
> github 上的项目,C 语言应该是存量最多的 问题就在于存量是最多的。多并非是好事,反而会将那些真正有用的库稀释了,查找起来会更困难。而且大量库(例如 GNU )几乎不在 GitHub 上发布,而是自建服务或者使用其他版本管理服务。 > 想找什么直接搜关键词,大概率能找到合适的 就我使用的体验,想找到有用的库很难。C 早期库的特点是很多不能注重模块化,因为类型和接口高度耦合,为了性能必须把一簇功能放在一起发布,例如 Glib 、gnulib 等。就「跨平台 Socket 库」这个需求,我初用 C 时好一顿找,Google 「 portable socket library for c 」翻个底朝天都没找出需要的。最后发现 libuv 的介绍是「 Cross-platform asynchronous I/O 」……汗颜,水平不够是真的没法精准描述自己需要的东西的。 > 这种推荐,大神不会去参考,小白也不会去用 大神不会参考我理解,「小白也不会去用」何出此言? > 普通人看到茫茫多的 C 代码,也只能劝退。 哪里有茫茫多的 C 代码?我这应该是个 curated list 类型的项目吧。只有标题、简介和链接啊。 > C 的爱好者,一般都是希望了解底层运行原理,但是你不自己造一个轮子出来,又怎么能了解原理呢。 语言有两个目的:使用和学习。使用自不必说,学习时先找到一个好的项目作参考,也不冲突。我猜想你的意思应该不包含「学语言必须闭门造车,不要参考任何项目」这一层观点吧? |
3
liprais 306 天前
我比别人聪明系列
|
4
w568w OP @liprais 你对于推荐的项目或者我的态度有什么建议吗?我反复读了一遍主贴,没有看到任何高高在上或者试图表明「我随手一推荐的都是对的,你们用的都是错的」的观点。相反,我一直在反复强调「我不是专业的 C 程序员」「其中一些领域我也不了解」「人工挑选或是利用 Google 等搜索引擎搜索得到的」。
至于我给楼上的回复,我也没有看出试图证明「我比你聪明」的意思。你是对哪一句不满意呢? 如果你认为自己比我聪明,欢迎提出理由。仅仅甩一句阴阳的话不能证明任何观点,除了你的戾气。我不认为你是来这里寻开心的。 |
5
liprais 306 天前
@w568w "ps:我不是专业的 C 程序员,其中一些我也不了解的领域则是从 awesome-c 等项目中人工挑选或是利用 Google 等搜索引擎搜索得到的。"
你自己看看你写的啥 |
6
w568w OP @liprais #5 我实在没有理解这句有什么问题,表达了我怎样的自命不凡。烦请高抬贵手指出。总不是指我用 Google 或者自称不专业吧。
如果你是说「在自己不了解的领域,还好意思挑选出来推荐给别人」的话,我在挑选中参考的都是客观指标( Star 数、维护频次、文档、可移植性、相关搜索数……),尽量不掺杂个人情感;另外,就像我下一句说的,「有的选择可能明显存在我的个人偏见」。事实上这个列表今天在和其他人交流中已经修改很多次了,原先自主主张添加的一些完全不了解的库基本已经轮替一轮。 |
7
tool2d 306 天前
"我初用 C 时好一顿找,Google 「 portable socket library for c 」翻个底朝天都没找出需要的"
现在有了 GPT4 ,需要找啥库问它,十有八九错不了。 上面提到的小白不会用,指的是新人很少有用 C 语言写项目的,产出和学习周期太长了。都是老人在用 C ,他们写的代码,基准在线,很糟糕的 C 代码项目极少。 |
8
w568w OP @tool2d #7
> 现在有了 GPT4 ,需要找啥库问它,十有八九错不了。 本着谁主张谁举证的原则,请证明这句话。不然全成我一人在说道了,有偏袒自己之嫌。 如果一定要我举证:(1) GPT-4 不是每个人都在用或者有能力用;(2) 我当然问过这个问题,GPT-4 回复的均是一些年久失修或者在某些 StackOverflow 中回答过的冷门库,反复增加条件好几次才慢吞吞给出 libuv ,而且还是同列在五六项不能用的库之中的。这恰好是我想避免的;(3) 小小滑坡一下,如果 GPT-4 就能解决所有问题,那 GitHub 上所有同类项目都应该不需要存在了。事实是这样吗?我个人从 GPT-4 处获得的回答,有一半都是错误的。 再强调一次,举证责任不在我。如果你想就这点讨论,请先给出任何一点自己的依据。 > 小白不会用,指的是新人很少有用 C 语言写项目的 要么我理解错你的意思,要么你在偷换概念。我们讨论的「小白」就是「学习 C 语言项目的小白」而不是「初次接触编程的小白」吧?怎么这部分人又变成「很少有用 C 语言写项目」呢? > 产出和学习周期太长了。都是老人在用 C ,他们写的代码,基准在线,很糟糕的 C 代码项目极少。 这些是客观事实。我认为,「产出和学习周期太长」的一个(不是全部)重要因素正是 C 语言生态差,各种配套设施杂七杂八得多,而且质量参差不齐。那么提出一个 curated list 我认为是有益的。 若因此不做,不又陷入「生态差->没人学->生态差」的循环了?而且预想一个完美的庞大「老人」群体(而这部分人很可能没有你说的那么多。看看 GitHub 上 C 库的代码质量就知道了),然后争论他们如何懂,这和项目是否有意义,我认为是关系不大的。总是有人要学习的,我的项目哪怕帮不到别人,能帮到我自己也是好的。 |
9
tool2d 306 天前
"看看 GitHub 上 C 库的代码质量就知道了", 我并没觉得代码质量差,新人一般都写一些练手 C 项目,谈不上写库给别人用。一般来说,能写一个 C 库给别人用的作者,基本上也有十年经验了。
而且我也没觉得非要比一个高低上下,代码代表着作者的思维模式,比如 ffmpeg 团队分裂事件,是因为新人共享的代码不好吗?并不是,只是大家的编程理念不相同罢了。 一句句反驳没必要,我给你贡献 star 就是了。 |
10
masterclock 306 天前
这个项目与 awesome-c 、搜索 有什么区别?
如果是全面的推荐,那么就是 awesome-c ,搜索。 如果是精选的,那么以 C 的生态,必定是 bias 、opinionated 的,这种模式下,仅仅只是一个条目、一句介绍显得过于单薄了。同时 OP 应该是 专业的 C 程序员,应该在某个领域具有比较深的积累,否者怎么知道推荐的某个条目是不是这个领域里的常规用例。 |
11
w568w OP @masterclock
> 这个项目与 awesome-c 、搜索 有什么区别? ( 1 ) awesome-c 并非记录了所有库;(2) awesome-c 没有给出任何有关库的详细信息,且其中 80% 的库都是属于「年久失修」的类型,搜索起来非常费时。 > 如果是精选的,以 C 的生态,必定是 bias 、opinionated 的 何出此言? > 仅仅只是一个条目、一句介绍显得过于单薄了 是的,所以我在介绍时非常强调对比性。如果列出了多条项目,一定要找到其差异的地方:是否更全面/紧凑?是否兼容特定 C 标准?性能是否有明显差异?是否维护良好?有关这一点,可以在列表中任意查找验证。 > 同时 OP 应该是专业的 C 程序员,应该在某个领域具有比较深的积累 「我不是专业的 C 程序员」里的「专业」是指「以写 C 为职业」,不「专业」 != 啥都不会… 要是啥都不了解就来写这种项目,我不是给自己找不痛快嘛。 至于你说的「某个领域具有比较深的积累」,我做 Linux 内核驱动和嵌入式比较多,不过都不是公开项目。这一点也可以从列表中验证:网络、JSON 解析部分的库改动是最勤快的,因为这一方面我确实了解不深。 > 否则怎么知道推荐的某个条目是不是这个领域里的常规用例 谢谢你的建议。正如我反复强调的,目前的评选标准是维护最积极、最流行甚至已成为事实标准(当然还包括可移植性、性能等),我认为这些都是客观的评判方式:如果某个领域最流行的库在 GitHub 上只有几个 star ,很「不常规」的用例反而有几千 star ,或者在 StackOverflow 上根本无人问津,那反倒是一桩怪事了。 最后,我发到 V 站来自然是为了让更多人看到这一项目,这样才有可能有路过的「这个领域里的」大佬来提出意见,让我有机会修正为你说的「常规用例」。 这是一个社区共建列表,不是一个个人维护项目。我不明白为什么我被一而再、再而三地要求证明我自己的个人水平或项目的「意义」来为列表背书,因为我的个人水平和列表的质量根本不是一码事。 如果你认为列表质量低,请直接说明哪一条低、改成什么项目更好;如果你认为有更好的选择,请直接把选择甩到我脸上让我学习,不必拐弯抹角;如果你压根没点进去看过项目,只是看完我的描述就想找个网友来怼一怼,那我也欢迎。虚无缥缈的指责无益于项目的进步。 |
12
masterclock 306 天前
1. 我看完了链接才回来评论的
2. 我没有拐弯抹角,就是在批评,没有达到我的预期,我希望能够更深入地介绍、对比一下库 2. C 我只用在 MCU 嵌入式上,所以列表中的很多我不了解 2. 相同的功能,我有时也会有不同的需求,有时要求尺寸、有时要求速度、有时要求某个特性,比如完全不用 malloc 、单文件、跨平台,这些是不是也可以加到列表上? 2. blessed.rs 我也觉得不好 2. 我不是打击,我是批评 2. 我鼓励你把这个做好,你花时间来方便你我他,我为什么要否定呢? 另外,我看到很多库的构建变成了 meson ,在列表上跟 autotools 、cmake 等对比一下? scons 还有人用吗?除了 rt-thread. |
13
HongyuGao 305 天前
以下说法仅仅是个人感觉,可能不正确,也并没有想否定楼上的任何一种说法,我觉得大家说的都有道理,只是个人情况不同,所以才有不同的理解。只是看到大家似乎都不怎么支持 op ,不过我觉得这 list 挺好的,所以支持一下。
个人感觉还是有些意义的吧,如果一个懂一些 C 但说不上精通的朋友,现在需要用 C 去完成一部分工作,这部分工作可能并不属于他特别熟悉的领域,list 可以让他用尽可能少的时间代价找到一个相关的、能用的库,快速写出点东西来,即便这个库并非最优选择。 就我个人的感受来说,初次接触一个领域感觉比较困难的地方在于各类信息纷繁复杂,并不是找不到信息而是找到的太多,需要花费时间去逐一甄别。 我理解 awesome-c 的特点应该是全面,使命是为开发者提供一个字典,它并不需要考虑这些库是否是维护比较积极的,是否是更流行的。就像是汉语词典,它会包含很多生僻字,能用的机会很少,但是不能因为用的少就不包含这些字。而这一 list 则是出于对实用性的考量。 当然楼上的朋友所说的建议也都在理,例如可以添加对库的特性的一些描述,以便可以更快找到适合的库。这些可以慢慢靠大家逐渐添加上来,op 加油。 |
14
icyalala 290 天前
我在列表里看到了我维护的库,所以顺道过来回复一下。
我感觉 C 在各种领域都有应用,不同领域之间的习俗偏好差距还是挺大的。 比如我主要做移动开发,一些必备的音视频库比如 ffmpeg ,常见的压缩库 lz4/brotli/zstd 等都没列进去。 有些库的描述也略有些不准确,所以还是建议找一些不同领域的专业人员共同维护。 |