@
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 站来自然是为了让更多人看到这一项目,这样才有可能有路过的「这个领域里的」大佬来提出意见,让我有机会修正为你说的「常规用例」。
这是一个社区共建列表,不是一个个人维护项目。我不明白为什么我被一而再、再而三地要求证明我自己的个人水平或项目的「意义」来为列表背书,因为我的个人水平和列表的质量根本不是一码事。
如果你认为列表质量低,请直接说明哪一条低、改成什么项目更好;如果你认为有更好的选择,请直接把选择甩到我脸上让我学习,不必拐弯抹角;如果你压根没点进去看过项目,只是看完我的描述就想找个网友来怼一怼,那我也欢迎。虚无缥缈的指责无益于项目的进步。