实际的 c++26
本文使用 macbook pro m4 + vscode 编写, 编译器是 g++-15 + glibc++, 键盘是 ibm model m 的 ssk 版本但是使用了自己打印的主板和 cherry 青轴.
本文讲了实际的 c++26 和 我希望的 c++26 之间的关系.
我非常反对的 iso c++26 提案特性
如果所有语言都在使劲浑身解数想要变成 rust, 那设计这个语言本来的目的是什么呢?
java 是为了替代 c++, 而 java 发明了一次编译到处运行的 jvm.
go 是为了替代 c++, 而 go 有通讯和可以比肩 python 的标准库.
rust 是为了替代 c++, 而 rust 搞出的是借用和可变借用.
我从来没说过 rust 不好, 我承认我用 rust 写过 opengl.
java 没有被 rust 同质化, java 依然到处都是空引用.
go 也没有被 rust 同质化, go 依然在用 java 发明的垃圾回收.
如果 c++ 变成了用 c 语法写的 rust, 那么 c++ 还有什么存在的意义吗? 难道是为了让 c 程序员过渡到 rust 中间有个缓冲吗?
我不是说 k&r 的设计优秀, 但我觉得作为包括了 java 和 go 甚至 c# 和 python 在内的 c like 语言, 危险当然是有危险的价值的.
可以是速度, 可以是自由度, 可以是任何东西, 重要的是危险本身可以带来价值.
hazard 指针
从提案设计来看, 很显然是 son of graydon.
upd: c++26 给这玩意留下了, 那好吧, 我不用就好了.
[[unsafe]]
无论无论如何, 你认为的危险操作可能是我需要的.
而且这会导致使用了这些危险操作的 c++23 代码无法通过 c++26 的编译, 这违背了 c++ 的 较新的 c++ 标准应尽量兼容较旧标准的合法代码 原则.
另外, [[unsafe]] 的含义是 "除了这里之外都是安全的", 但实际上 c++ 语言本身应该全是 unsafe, 所以应该加 [[safe]] 来表示 "除了这里之外都是危险的", 所以 [[unsafe]] 是 graydon 的政变.
upd: c++26 真的给它删了.
我想要额外加入的
bjarne 提出的 profile
我坚决支持 bjarne 提出的所有思想, bjarne 是为了避免 ub 那我跟.
消除 ub 是消除 ub, 不是变的安全. 消除 ub 不会变的安全, 消除 ub 也能提高开发效率和运行效率. 我始终认为 c++ 是个危险的语言, 但是总有办法能写出来安全的代码.
upd: c++26 没加这个, /ll
contracts
本来是在 c++26 提案里的, 听说即将被删除了, 希望能加入吧.
使用编译指令 -fcontract-semantic=quick_enforce 可以让代码 fail fast.
fail fast: 见 lil_tea c++ style guide.
upd: c++26 通过了这个, 可喜可贺.
restrict
restrict 是个优秀的设计, 你向编译器承诺 我发誓我不会传入两个相同的东西, 这样编译器就可以放心的优化了.
我要说的是, 我想要 restrict 支持任何的除了传值之外的传参方式.
比如说, 我这样写:
cpp
void mul(matrix &s, const matrix &x, const matrix &y) {
// 假装我在这里实现了矩阵乘法
}那么如果 s 和 x 是同一个对象 (很正常的 \(s *= y\) 语义), 那么这里是会导致错误的 (x 一边被 s 修改, 一边还要用乘积给 s 赋值, 简直就是胡闹).
所以我加上这个:
cpp
void mul(matrix &restrict s, const matrix &restrict x, const matrix &restrict y) {
// 假装我在这里实现了矩阵乘法
}然后让编译器帮我检查, 如果对象重叠就直接报错.
同样的, 也可以支持 stl 和迭代器, 也可以支持智能指针, 只要重叠就让编译器报错.
当然了, 这很明显是违背了最初的含义是用于优化代码, 但这确实可以让代码更加安全, 优化与否我确实不在意, 因为我相信
-O2的优化能力.
其实contracts能完整满足restrict的要求, 只是运行时和编译时的区别而已, 而且还支持更多的判断方式.
int main(const std::span<const std::string_view> &args)
这个的含义是非常显然的, 就是 java 学来的 public static void main(String[] args), 用了 c++ 写法.
在继续允许 int main(int argv, char **argv) 和 int main(void) 的情况下, 再有一个现代化的版本也是非常优秀的.
注意: java 的 args[0] 已经是参数, 而我们根据 c 惯例让 args[0] 表示调用路径, 后面的 args[1] 到 args[args.size() - 1] 才是参数.
超级基类
有一个类, 我不想让它被实例化, 也不想让它被用于传参 (包括不允许引用和指针), 但有很多类都要继承它, 那么我就把这个类写成超级基类. 超级基类可以有虚函数, 可以有纯虚函数, 也可以没有虚函数, 可以继承一个超级基类, 只要不实例化且不做参数就行.
cpp
baseclass entity {
std::vector<double> pos_;
public:
entity(std::size_t d)
: pos_(d) {}
std::expected<void, std::string> move(const std::vector<double> &velocity, long time) {
if (velocity.size() != pos_.size())
std::unexpected<std::string>("纬度错误");
if (time < 0)
std::unexpected<std::string>("时间错误");
for (std::size_t x : std::views::iota(0uz, pos_.size()))
pos_[x] += velocity[x] * time;
}
const std::vector<double>& where(void) const {
return pos_;
}
};
class player : entity;
class zombie : entity;
baseclass npc : entity;
class merchant : npc;额外的, 如果你让一个超级基类继承一个普通类, 那我不会拦着你, 但你应该想清楚你要做什么再开始敲键盘, think twice, code once.