1
leighton 2022-11-26 17:18:23 +08:00
追求 100%兼容 cpp 我会等 carbon 。但是都不如直接抛弃历史包袱用 rust 来得爽
|
2
SMGdcAt4kPPQ 2022-11-26 17:28:49 +08:00 via Android
不看好,需要先编译到 cpp 再编译,无法解决 cpp 编译速度慢的问题。需要有一种编程语言能像 cpp 导入 c 头文件一样能直接导入 cpp 头文件,同时编译速度快,那么这语言就成了
|
3
tinkerer 2022-11-26 21:42:38 +08:00
rust 库 cxx 不知道你有没有把玩过。
|
4
neoblackcap 2022-11-27 01:24:01 +08:00
战胜对手,一般都不是在对手的战场作战。nginx 不会突然替代已经在用 Apache 的项目,但是它的确会在新的项目中替代 Apache 。
同理 Rust 不会一下子,但是在可以用 Rust 以及可以用 Cpp 的场合,人们很有可能会选用 Rust 。Cpp 模板写个类型约束都累得慌,得熟悉各种现代 Cpp 用法,还得知道 SFINAE 。Rust 就是入门就能写好约束。 |
5
agagega 2022-11-27 15:30:27 +08:00 1
Google 那个 Carbon 没想明白是要干啥,不上不下的,既不能 cppfront 一样和 C++源码级兼容,也不如 Rust 直接另起炉灶。
cppfront 是一个探索,值得鼓励,C++总得要改变的,现在很多人就是单纯像只用过 iPad 的人看不惯 Mac 一样看不惯 C++而已,改进多了要说「哎呀我 C++11 都还没学完」,改进少了又说「这帮老头子不思进取」。 不过在一个力图像当年 C++兼容 C 一样的预处理器里加太多语法改动没啥意义,重点还应该在改变很多因为兼容性导致的默认行为。现在 Clang 和 GCC 都在加可选的 attribute 以让 C++开启类似 Rust 的检查,cppfront 和他们配合一下,变成一个语言级别的 GSL 的话还不错。 业界现有的 C++代码库是非常庞大的,而且还在活跃开发中。这种不破坏兼容性的渐进式改进会带来很多帮助。 |
6
LaTero OP @agagega 确实,我看 core guidelines 的时候就在想,很多守则本就应该让编译器来检查
|
7
L4Linux 2022-11-27 17:00:30 +08:00 via Android
@ComputerIdiot 你找的是不是 C++ module ,GCC 的 module 勉强已经能用了。
|