培基光笔C 是一门底层的系统编程语言，几乎没有对内存的抽象，所以内存管理全靠你自己，对汇编的抽象也很少，但足以支持一些如类型系统等通用概念。它也是一门适应性非常强的编程语言。如果编写得当，即使你的厨房烤箱具有一些奇特的架构，它也可以在上面运行。

　　C 语言的设计特点使其非常适合用于底层系统编程。然而，这并不意味着其设计决策在今天的标准下无懈可击。在这篇博客中，我们将讨论一些 C 语言存在的问题。这些问题导致人们多次试图创建用于取代 C 语言的备选语言。

　　Zig 编程语言作为一种新的系统编程语言，定位自身为改进版的 C 语言，引起了相当多的关注。Zig 是如何实现这一目标的呢？在这篇博客中，我们的目标是研究一些与 C 语言相关的问题，并探讨 Zig 是如何解决这些问题的。

　　使用预处理器在源代码中替换文本并非C 语言特有。这在 C 语言诞生之前就已经存在，早在 IBM 704 计算机的 SAP 汇编器中就有类似的例子。以下是一个 AMD64 汇编片段的例子，它定义了一个 pushr 宏，并根据其参数将其替换为 push 或 pushf：

　　C 语言作为汇编的最小抽象，采用了同样的方法来支持宏，但这很容易引发问题。以下是一个小例子：

　　C 语言不会容忍这种错误，也不会友善地提醒你这些错误。错误仍然可能会在程序的其他位置，甚至是在后续的输入中出现。

　　然而，Zig 采用了一种更直观的方法来处理此类任务，引入了 comptime 参数和函数。这使我们能够在编译时执行函数，而不是运行时。以下是 Zig 中的 C SQUARE 宏：

　　Zig 编译器的另一个优点是能对输入进行类型检查，即使它是 anytype。当在 Zig 中调用 square 函数时，如果使用了不支持 * 操作符的类型，将导致编译时类型错误：

　　这个 Zig 程序定义了一个 fibonacci 函数，然后在编译时调用该函数设置 foo 的值。在运行时没有调用 fibonacci。

　　有着巨大的力量，也伴随着巨大的责任。在像 C 这样的手动内存管理语言中，如果管理不善，可能会带来严重的安全问题。最好的情况可能只会导致服务拒绝，而最糟糕的情况可能会让攻击者执行任意的代码。许多语言试图通过施加编码限制或者使用垃圾收集器来避免这个问题。然而，Zig 采取了不同的方式。

　　没有隐藏的分配：没有任何东西会在堆上分配，除非你知道并允许它这么做。Zig 使用 Allocator 类型来实现这一点。任何在堆上分配的函数都会接收一个 Allocator 作为参数。任何不这样做的都不会在堆上分配，这是有保证的。

　　Zig 不会像 Rust 那样限制你的编码方式，帮助你保持安全，避免泄漏，但仍然让你可以像在 C 中那样随心所欲。我个人认为这可能是一个方便的折衷。

　　这段 C 代码会突然崩溃，除了一个 SIGSEGV，什么线索都没有，让你不知所措：

　　Zig 没有任何 null 引用。它有可选类型，用问号在前表示。你只能把 null 分配给可选类型，并且只有在你检查了它们不是 null 的情况下才能引用它们，使用 orelse 关键字或者简单的 if 表达式就可以。否则，将会导致编译错误。

　　在 C 语言中，地址是用一个数值来表示的，这允许开发者对指针进行算术运算。这个特性使得 C 语言开发者能够通过操作地址来访问和修改任意内存位置。

　　指针算术常用于诸如操作或访问数组的特定部分或高效地遍历动态分配的内存块等任务，而无需进行复制。然而，由于 C 语言的不宽容性，指针算术很容易导致诸如段错误或未定义行为等问题，使得调试成为一种真正的痛苦。

　　大多数这类问题可以用 Slice 来解决。Slice 提供了一种更安全、更直观的方式来操作和访问数组或内存区域：

　　每种类型都有一个对齐数，它定义了该类型的合法内存地址。对齐是以字节为单位，它保证了变量的起始地址能被对齐值整除。例如：

　　u16 类型的自然对齐值为 2，意味着它只能存在于内存地址能被 2 整除的位置，比如 0, 2, 4, 6, 8 等...

　　u32 类型的自然对齐值为 4，意味着它只能存在于内存地址能被 4 整除的位置，比如 0, 4, 8, 12, 16 等...

　　CPU 强制执行这些对齐要求。如果一个变量的类型没有正确对齐，它可能导致程序崩溃，比如段错误或者 illegal instruction 错误。

　　现在我们故意在下面的代码中创建一个未对齐的 unsigned int 指针。这段代码在大多数 CPU 上运行时会崩溃：

　　使用低级语言会带来一些挑战，比如管理内存的对齐。如果出错了，可能会导致崩溃，而 C 不会帮你检查。那么 Zig 呢？

　　即使你试图用一个显式的 @alignCast 来欺骗 Zig，Zig 在安全构建模式下也会在生成的代码中添加一个指针对齐安全检查，以确保指针按照承诺的方式对齐。所以如果运行时对齐错误，它会用一条信息和一个追踪来告诉你问题出在哪里。

　　许多 C 语言的 API 有错误码的概念，即函数的返回值表示成功状态或者一个指示具体错误的整数。Zig 也使用同样的方法来处理错误，但是在类型系统中对这个概念进行了更有用和更富表现力的改进。Zig 中的错误集合就像一个枚举。但是，整个编译过程中的每个错误名都会被分配一个大于 0 的无符号整数。一个错误集合类型和一个普通类型可以用 ! 运算符组合成一个错误联合类型（例如：FileOpenError!u16）。这种类型的值可能是一个错误值，或者是普通类型的值。

　　每个代码块都可以有一个标签，比如 :blk，并且可以用 break blk: 从该代码块中跳出并返回一个值。

　　这声明了 bar 为一个常量指针，指向一个包含 5 个指针的数组，这些指针指向一个函数（int），返回一个常量指针，指向 char。不管这是什么意思。

　　当然，也有一些工具工具，比如可以帮助你阅读 C 类型，并用人类容易理解的语言对其进行解释。我相当确定对于实际的 C 开发者来说，处理这样的类型可能并没有那么困难。有些人天生就有能力阅读复杂语言。但对于像我这样喜欢简单明了的普通人来说，Zig 类型更容易阅读和维护。

　　在这篇博客文章中，我们讨论了一些 C 语言存在的问题，这些问题促使人们寻求或创造替代方案。

　　你使用 C  语言时是否也遇到过这些问题？有没有哪些问题文中没有提到？你是否已经尝试过使用 Zig？如果有，你觉得它的哪些特性最有用？欢迎在评论区分享你的经验。