北京
想象一个场景：你正在用Python、Java或C#做开发，需要一个核心工具库来处理复杂的数学运算或文件解析。你会希望这个库用什么语言来写？用你正在使用的语言当然最方便，但现实是，大多数编程语言本身并不够稳定——十年前写的Python库，如果没人持续维护，很难直接在你现在的Python版本上跑起来。你还需要它跑得快，那么编译型语言会更合适。C++和Rust同样面临向后兼容问题，还需要专门的工具链，从别的语言调用它们也得额外写绑定代码。于是答案逐渐清晰：你最想要的，是一个用C写的库。
用C写，意味着它速度快、够简单、到处都能跑，而且大多数程序员至少能看懂代码。但关键问题来了：这个库应该用什么样的C来写？真正可依赖的选择，是那种最朴素、最干净的C——不需要任何语言扩展，不依赖特定的编译器设置，也不绑定任何复杂的构建步骤。无论你的平台提供什么样的工具链，它都应该能直接编译，不挑编译器实现，也不挑语言版本。
这就是"Dependable C"这个概念试图去规范的东西。它不花哨，也不是那种所谓"现代"C风格，但它总是能工作，而且速度够快。代码最重要的特性，是你能让它成功编译，并按预期运行——Dependable C优先追求的就是这一点。它不是优先照顾程序员的编写体验，而是优先确保使用这套代码的人，能在自己的环境中真正依赖它跑起来。一个略显讽刺的现实是：很少有人愿意亲手写Dependable C，但几乎每个人都希望别人的代码是用这种风格来写的。
反观C语言标准本身，从C23到即将到来的C2Y，语言版本正变得越来越复杂，新增了大量关键字和流程控制结构，连标准委员会的任务章程都已经和"经典C"时代不太一样了。而在数百种C语言实现中，最新版本标准往往只被其中两种主流实现所支持。从ANSI C到C2Y的变化幅度，可能比从ANSI C到C++第一版之间的距离还要大。这对那些想开发具备广泛可移植性和标准合规性的经典C软件的人来说，最新的ISO C标准已经不是一份好用的指南了。去查阅更早的标准版本也不够，因为那些旧标准里既不会列出后来被废弃的特性，也不会告诉你哪些部分在实际编译器支持中一直存在问题。
这正是Dependable C要解决的方向——它试图提供一份指南，帮助开发者写出能被普遍接受的C代码。C语言仍然是当今可移植性最强、实现最广泛的编程语言，曾被称为计算领域的通用语。用C解决的问题，在可预见的未来会一直保持已解决的状态。操作系统、计算环境或者硬件的变化，几乎不可能让一段编写得当的C实现彻底失效。而一个用C写成的库，能够被几乎所有语言调用。关键在于，你需要用那种真正能让别人依赖起来的方式去写。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
