大家好，今天来为大家分享c网站可以下载源码分享的一些知识点，和哪些网站可以下载源代码的问题解析，大家要是都明白，那么可以忽略，如果不太清楚的话可以看看本篇文章，相信很大概率可以解决您的问题，接下来我们就一起来看看吧！
摘要：这一次，Zig要彻底告别C++了。
链接：https://ziglang.org/news/goodbye-cpp/
声明：本文为CSDN翻译，未经允许禁止转载。
作者|AndrewKelley译者|弯月责编|郑丽媛出品|CSDN（ID：CSDNnews）
在此次变更之前，Zig代码库由两个编译器组成：
旧编译器：总共包含8万行C++代码，加上新编译器共享Zig代码。
新编译器：总共包含25万行Zig代码。
新编译器的速度更快，使用的内存更少，并得到了积极的维护和增强。同时，没有人想碰旧编译器，但是通过源代码构建新编译器时需要用到旧编译器。
这意味着，新的Zig语言特性必须实现两次：在新代码库中实现一次，然后在旧代码库中再实现一次——这是一个巨大的痛点，尤其这两个编译器的设计早已大相径庭。
此外，用C++实现的Zig最初使用的策略与D编译器相同：在进程退出之前不释放任何内存。但随着编译时执行代码成为该语言的标志性功能之一，加之使用同一个编译单元来处理一切，项目的规模越来越大，这个设计决策就有点不合时宜了。
解决方案
这个问题很有趣，有很多解决方案，但每一种都有一定的弊端。在搞清楚问题之后，我们就各种可能性展开了快速的头脑风暴会议，每个提议都有自己的优缺点。
放弃自我编译
Odin就采用了这种方法。
这个方法可以解决整个问题，但缺点是我们必须放弃Zig，转而使用C。我不同意，因为Zig带来的改进太诱人了，我不想放弃：例如，我们使用的一些面向数据的设计技术无法通过C/C++实现。
使用旧版本的编译器
这是Rust和许多其他语言采用的方法。
这种方法的一大缺点是，根据源代码构建任何提交都需要经过复杂的操作。例如，假设你尝试执行gitbisect，有时git会检出一个旧版本的提交，但脚本无法利用这些源代码构建，因为构建编译器的二进制文件不是正确版本。当然，这个问题并不是无法解决，但势必会给开发人员带来许多不必要的麻烦。
此外，构建编译器也会受到目标平台上已有二进制文件的限制。例如，假设没有riscv64版的编译器，就无法在riscv64硬件上利用源代码构建。
因此关键问题在于，这种方法无法充分支持能够在任何系统上构建任何提交的需求。
将编译器编译成C代码
这是Nim采用的方法。
与前面的策略相比，这种方法的好处是可以将生成的C代码提交至源代码控制，比较方便，但如果这些C代码只能用于特定平台，实际效果也是一样的。
我不太清楚怎样才能生成不依赖于平台的C代码（像Nim那样），但我看到他们的描述中说：“支持的CPU/OS组合比旧的csources代码库更多”。这意味着，尽管他们的代码可以在许多CPU/OS的组合上编译，但这并不一定表示这些C代码具有可移植性。此外，这些代码与主编译器分别保存在不同的代码库中，所以并不能解决前一种策略遇到的问题。
我探索了这种可能性，发现生成的C代码不仅只能用于特定平台，而且代码量非常大。我们的编译器会生成一个80MiB的C文件。虽然我们可以通过C后端增强来改进，但与其接受如此大规模的扩张，还不如直接将二进制文件提交到Git代码库。
将编译器编译成C代码，之后直接维护C代码
这种方法我从多年前就想试试，最近终于开始研究了一下。很明显的一大缺点是，清理自动生成的C代码非常困难，而且依然需要维护两种编译器实现，容易打击贡献者的积极性——谁会愿意用Zig和C重复两次相同的工作？
将编译器编译成简单的虚拟机
有一次，在讨论编译器自举时，DrewDeVault提到了OCaml的策略。于是我有了一个想法：可以建立一个自举专用的后端。
不过我认为Zig和OCaml之间还有一些差异。Zig只有一个虚拟机平台，它是跨平台的，可以通过LLVM进行优化——这就是WebAssembly，使用WASI作为操作系统抽象层。
探索思路
主要思路是，利用一个非常小的wasm二进制作为stage1内核，提交到源代码控制，这样就可以用它来编译源代码中的任何提交。我们提供了一个C编写的WASI解释器，然后用它将Zig编译器代码编译成C代码。之后用系统的C编译器对C代码进行编译和连接，生成stage2二进制文件。接着，stage2二进制文件就可以通过反复的zipbuild从源代码进行构建。
wasm二进制文件是通过zigbuildupdate-zig1生成的，后者使用了LLVM后端来生成一个针对wasm32-wasi平台、generic+bulk_memoryCPU的ReleaseSmall二进制文件。该二进制文件中C之外的所有后端都是禁用的，这样产生的文件仅有2.6MiB。然后再通过wasm-opt-Oz–enable-bulk-memory进行优化，压缩到2.4MiB。最后，用zstd进一步压缩至637KB。其中还包括了zstd解码器（用C实现），但这是值得的，因为zstd的实现基本不会改变，而且它每次都能给wasm二进制文件节省下1.8MiB。
因此，我们用4千行可移植的C代码替换了原本8万行的C++代码。这些代码仅使用了标准libc函数，且不依赖于任何POSIX的头文件，也不依赖于windows.h。操作系统互操作层完全抽象到了几个WASI函数中，由WASI解释器负责实现：
(import”wasi_snapshot_preview1″”args_sizes_get”(func(;0;)(type3)))(import”wasi_snapshot_preview1″”args_get”(func(;1;)(type3)))(import”wasi_snapshot_preview1″”fd_prestat_get”(func(;2;)(type3)))(import”wasi_snapshot_preview1″”fd_prestat_dir_name”(func(;3;)(type6)))(import”wasi_snapshot_preview1″”proc_exit”(func(;4;)(type11)))(import”wasi_snapshot_preview1″”fd_close”(func(;5;)(type8)))(import”wasi_snapshot_preview1″”path_create_directory”(func(;6;)(type6)))(import”wasi_snapshot_preview1″”fd_read”(func(;7;)(type5)))(import”wasi_snapshot_preview1″”fd_filestat_get”(func(;8;)(type3)))(import”wasi_snapshot_preview1″”path_rename”(func(;9;)(type9)))(import”wasi_snapshot_preview1″”fd_filestat_set_size”(func(;10;)(type36)))(import”wasi_snapshot_preview1″”fd_pwrite”(func(;11;)(type28)))(import”wasi_snapshot_preview1″”random_get”(func(;12;)(type3)))(import”wasi_snapshot_preview1″”fd_filestat_set_times”(func(;13;)(type51)))(import”wasi_snapshot_preview1″”path_filestat_get”(func(;14;)(type12)))(import”wasi_snapshot_preview1″”fd_fdstat_get”(func(;15;)(type3)))(import”wasi_snapshot_preview1″”fd_readdir”(func(;16;)(type28)))(import”wasi_snapshot_preview1″”fd_write”(func(;17;)(type5)))(import”wasi_snapshot_preview1″”path_open”(func(;18;)(type52)))(import”wasi_snapshot_preview1″”clock_time_get”(func(;19;)(type53)))(import”wasi_snapshot_preview1″”path_remove_directory”(func(;20;)(type6)))(import”wasi_snapshot_preview1″”path_unlink_file”(func(;21;)(type6)))(import”wasi_snapshot_preview1″”fd_pread”(func(;22;)(type28)))
为了让Zig编译器把自己编译成C，只需要使用这些系统调用。
JacobYoung和我一起，在andrewrk/zig-wasi的基础上完成了这个WebAssembly/WASI解释器。我用Zig建立了初版，借助Zig丰富的标准库和安全机制探索了这个思路。这个解释器不会提前解码wasm模块，而是直接使用文件偏移量作为程序计数器。虽然它能正常工作，但太慢了，对编译器进行解释执行需要好几个小时，而用原生机器码只需大约5秒钟。
因此，Jacob改善了该项目，引入了另一个指令集和更多的优化，还有一些其他技巧，将性能提升到了可接受的程度。同时，我将Zig代码转成了纯C。
我们一起努力了大约两个星期，互相将对方的代码合并到自己的分支中，交流心得、分享成功的喜悦。我非常感谢Jacob在这个项目上的努力，特别是他一丝不苟地改进Zig的C后端，才让这个项目得以成功。
在概念得到证实后，Jacob意识到，将WebAssembly转成C，要比直接解释执行更快。这实际上就是JIT编译，但更大的好消息是，我们的自举工具实际上是系统的C编译器。
WebAssemblyBinaryToolkit项目里有一个wasm2c工具，但我们并没有移植或分叉——Jacob从零开始创建了一个wasm2c的实现。这个实现没有考虑通用性，只包含了在编译器编译自己时需要调用的系统调用。
所以，这个版本的wasm2c只有4千行代码，也不依赖C++，采用了更简洁的方式，没有实现任何沙盒、安全特性等。
新的构建过程
下面是新的构建过程：
BuildingCXXobjectCMakeFiles/zigcpp.dir/src/zig_llvm.cpp.oBuildingCXXobjectCMakeFiles/zigcpp.dir/src/zig_llvm-ar.cpp.oBuildingCXXobjectCMakeFiles/zigcpp.dir/src/zig_clang.cpp.oBuildingCXXobjectCMakeFiles/zigcpp.dir/src/zig_clang_driver.cpp.oBuildingCXXobjectCMakeFiles/zigcpp.dir/src/zig_clang_cc1_main.cpp.oBuildingCXXobjectCMakeFiles/zigcpp.dir/src/zig_clang_cc1as_main.cpp.oBuildingCXXobjectCMakeFiles/zigcpp.dir/src/windows_sdk.cpp.oLinkingCXXstaticlibraryzigcpp/libzigcpp.aBuilttargetzigcppBuildingCobjectCMakeFiles/zig-wasm2c.dir/stage1/wasm2c.c.oBuildingCobjectCMakeFiles/zig-wasm2c.dir/stage1/zstd/lib/decompress/huf_decompress.c.oBuildingCobjectCMakeFiles/zig-wasm2c.dir/stage1/zstd/lib/decompress/zstd_ddict.c.oBuildingCobjectCMakeFiles/zig-wasm2c.dir/stage1/zstd/lib/decompress/zstd_decompress.c.oBuildingCobjectCMakeFiles/zig-wasm2c.dir/stage1/zstd/lib/decompress/zstd_decompress_block.c.oBuildingCobjectCMakeFiles/zig-wasm2c.dir/stage1/zstd/lib/common/entropy_common.c.oBuildingCobjectCMakeFiles/zig-wasm2c.dir/stage1/zstd/lib/common/error_private.c.oBuildingCobjectCMakeFiles/zig-wasm2c.dir/stage1/zstd/lib/common/fse_decompress.c.oBuildingCobjectCMakeFiles/zig-wasm2c.dir/stage1/zstd/lib/common/pool.c.oBuildingCobjectCMakeFiles/zig-wasm2c.dir/stage1/zstd/lib/common/xxhash.c.oBuildingCobjectCMakeFiles/zig-wasm2c.dir/stage1/zstd/lib/common/zstd_common.c.oLinkingCexecutablezig-wasm2cBuilttargetzig-wasm2cConverting../stage1/zig1.wasm.zsttozig1.cBuildingCobjectCMakeFiles/zig1.dir/zig1.c.oBuildingCobjectCMakeFiles/zig1.dir/stage1/wasi.c.oLinkingCexecutablezig1Builttargetzig1Runningzig1.wasmtoproducezig2.cRunningzig1.wasmtoproducecompiler_rt.cBuildingCobjectCMakeFiles/zig2.dir/zig2.c.oBuildingCobjectCMakeFiles/zig2.dir/compiler_rt.c.oLinkingCXXexecutablezig2Builttargetzig2Buildingstage3
总结：
使用系统C编译器编译zig-wasm2.c；
使用zig-wasm2.c将zig1.wasm.zst转换成zig1.c；
使用系统C编译器编译zig1.c；
a.注意zig1只启用了C后端。
使用zig1将Zig编译器编译成zig2.c；
使用系统C编译器编译zig2.c；
a.这个编译器的逻辑是正确的，但它的机器码是由系统C编译器优化的，而不是它自己优化的。所以我们继续进行第六步，得到一个自我编译后的性能特性。
zig2build（使用旧版本Zig编译Zig的标准构建流程）；
如果用最后一步产生的结果再次编译Zig，会得到同样的字节码。也就是说，zig3、zig4是完全相同的。所以整个过程结束，最后得到的二进制文件可以去掉后缀，直接命名为zig。
wasm二进制的更新仅限于有重大更新，或新功能影响到编译器构建自身的时候。例如，编译器中的bug修复不会影响编译器编译自身，因此可以忽略。但如果Zig编译自身时必须修复该bug，那么就需要更新wasm二进制。与之相似，当语言改变、编译器需要使用新功能来编译自身时，就要更新wasm二进制文件。
更新stage1/zig1.wasm.zst的方法如下：
zigbuildupdate-zig1
性能
我收集了两个性能数据：
数据2：使用ninjainstall从源代码编译，配置为-DCMAKE_BUILD_TYPE=Release：
old:13m20swith10.3GiBpeakRSSnew:10m53swith3.2GiBpeakRSS
其中最关键的是构建时内存的需求量。一个只有4～8GiB的RAM能否编译Zig是非常重要的，这决定了是否可以用GitHub认证的Action。
未来的计划
有一点我要承认，尽管此次改动大获全胜，但还是有一个地方退步了，即能否在固定次数内实现Zig的自举。
在这之前，从源代码开始的构建过程没有涉及任何二进制块，除了系统的C/C++编译器之外。但此次改动之后，它使用了WebAssembly的二进制，这并不是源代码，而是一个构建结果，有些人可能非常看重这一点。
这是需要付出的代价，但我认为这些代价是值得的。考虑到官方语言规格以及Zig越来越受欢迎的现状，我们会看到更多的第三方项目开始用C来实现Zig。
我愿把此次改动之前的版本标记为1.0，且此次改动也并不在Zig软件基金会的计划内。当然，事情可能会改变，这只是目前的计划。
此外，此次改动还去掉了-fstage1标志，这个标志可以让Zig用户选择旧版本编译器来代替新版本——这是使用异步函数的唯一方法，而异步函数功能在新的编译器中还没有实现。
我建议需要使用-fstage1标志的用户继续使用0.10.0，当0.10.1发布后进行升级，最终升级到0.11.0，该版本将会支持异步函数。注意Zig采用语义版本号，因此本文中所说的一切都不会进入0.10.1发布，。0.10.1只会包含master分支上的bug修复。
语言的发展
从更积极的方面来看，此次改动意味着所有计划中的语言改动都可以更快地进行。当我们脱离了旧代码的束缚，Zig0.11.0的发布迭代会更快。
有了这个改动，我们就可以像试用标准库那样，立即试用语言上的新改动。
在这个改动合并到主分支时，标签“stage1”下已经有650个问题，而这些问题所针对的代码都可以删掉了！所以，理论上我们可以立即关闭这些问题，不过我要求关闭这些问题时必须编写相应的测试用例，或者证明相应的部分已经有测试覆盖了。也许这需要付出更多的努力，但这正是我们当前的工作。
好了，关于c网站可以下载源码分享和哪些网站可以下载源代码的问题到这里结束啦，希望可以解决您的问题哈！