Skywind Inside

说起文本模式界面库，也许有人听过 Turbo Vision 2.0，这货是当年 Borland C++ 3.1 （不是 Turbo C 2.0）背后的商用界面库 TV2 的开源版，经过多年迭代，如今是一款支持 unicode 和现代 C++ 跨平台的 TUI 库了：

项目地址：https://github.com/magiblot/tvision

主要特性：

• 跨平台：Windows，Linux，macOS，DOS，FreeBSD
• 支持鼠标，支持 unicode，正常显示中文；
• 多窗口：窗口可以自由拖拽移动，扩大缩小，全屏，互相覆盖（overlap）
• 控件多：主菜单，对话框，checkbox, radiobox，dropdown list，文件选择器，进度条，阴影
• 文本编辑：语法高亮，自动 indent，鼠标选中，shift+方向键选中，CTRL+C/CTRL+V
• 支持真彩：原来老的 Borland 版本的 TV2 只支持 16 色。

Linux 下大部分 TUI 程序都是平铺窗口，无法重叠，更无法自由拖动，而 Turbo Vision 2.0 完全像用图形界面程序一样，鼠标操作这些窗口自由移动，扩大缩小，全屏化：

Continue reading →

Rust 并不适合开发游戏，它更擅长有明确定义，边界清晰的项目，这样你类型体操一遍做完问题不大，比如重构个已经十年没变过的 C 模块，但游戏领域并没有明确的定义，策划案不停修改，你的代码不但要求快速迭代还要求不停重构，那么类型体操在这过程中就变成锁死你的紧箍咒。

参考文章：3 年写了 10 万行代码开发者吐槽：当初用 Rust 是被忽悠了

这里解释一下，为什么当项目没有明确定义时，rust 为啥会显得笨拙？因为此时不但需求会随时间变来变去，更要命的是你没有一份十年没变过的 C 代码做参考，对项目整体实现缺乏全局的认识，只有自底向上的方法不断尝试和修正自己，不段反思和改进中上层代码，才能像盲人摸象那样逐步认清楚整个世界因该是啥样。

而此时类型体操会在这时勒得你喘不过气来，一个之前需要横着用的变量现在需要竖着用了，你思来想去发现你完全没办像其他语言那样改成法竖着用了，于是你只有引入更大范围的重写才能解决问题，你觉得这样很难受，去 rust 社区寻求帮助，但发现他们并不会帮助你真的解决语言问题，只会一个劲的指责你 “你觉得痛苦正是因为你对 rust 不熟悉导致的” 或者 “rust 逼迫你更大范围重写正是逼你尽早写出更好的代码”，他们这么说在定义清晰的项目里的确没问题，越早重构越好，但在定义不清晰的项目上里存在大量中间设计，你今天改成这样，八成不是最终形态，隔几天可能还要改，而此时 rust 却逼迫你每次都提前费精力进行更大范围的重写，即使这时完全没必要的，过两天就不需要的，他也不许你像其他语言那样用快速实现的方式应对新的中间状态，等需求稳定了，技术方案也收敛的情况下再进行迭代和完善，然后你就抓狂了！

网友 FENG DONG：项目没有明确定义时候，需要设计 cost function，然后让代码沿着 gradient 演进。但 Rust 不是一种可微的语言。

网友 Aaltonen：游戏开发是 “巨型可变状态球” （giant balls of mutable state），需求像 gradient descent 一样逐步演进，但 Rust 的借用检查器（borrow checker）和所有权模型强制你 “一次性想好”，导致小改动引发大重构。

那么 Rust 适合开发游戏引擎么？我只能说 depends，主要到了现在也没啥 rust 开发游戏引擎的成功例子啊，一天到晚到处搞营销的 rust 游戏引擎 bevy 基本上类似个玩具，到现在都没啥靠谱的商业游戏案例，顶多几个独立小游戏之类，而且它要求用 rust 来写业务逻辑，这个上面已经论述过，它并不适合开发游戏业务逻辑；

Continue reading →

说实话，编译器是否该利用 Undefined Behavior 进行优化目前都还是一个争议话题，主要是 gcc 开了个坏头，不予余力的在默认参数下利用 UB 来优化，举个例子，C 语言里带符号整数溢出是未定义行为，编译器应该假设它实际上以某种方式定义了：

int foo(unsigned char c) {
    int value = 2147483600;
    value += c;
    if (value < 2147483600) 
        bar();
    return value;
}

但利用这个 UB 进行优化的编译器会认为，既然 x 不会是负数，那么 value < 2147483600 就永远不会发生，所以整个 if 语句以及后面的 bar() 调用将可以被忽略，变成：

int foo(unsigned char c) {
    int value = 2147483600;
    value += c;
    return value;
}

这其实是一种很危险的做法，因为 C 语言可以跨越各种 CPU 架构编程，当年标准定义时，CPU 架构的差异比今天还大，在处理上面这类问题时，即便在今天，不同的架构结果并不一定相同，比如有的平台用补码表示负数，所以溢出了就会变成 -2147483648，而碰到反码或者原码表示负数的架构下，溢出了可能就变成 0 或者其它，所以一些事情根本就没法具体定义，必须留给具体编译器具体平台去处理。

Undefined Behavior 并不是说代码这么写是错的，相反他们都是语法正确的代码，真是错的应该就编译错误了，而是标准留个编译器实现者以自由，不去做限制，让他们根据实际平台，根据自己实现情况自行选择实现方式，而某些编译器实现选择利用它来进行优化了，那么如果本来就想利用特定平台的特性完成某些特定功能时，所以这类代码将没法写了。

关于这个问题，有个 X 友说的很准确，这里贴下译文（原文贴后面）：

亲爱的 C 程序员们，既然你们似乎无法阅读关于你们编程语言的文档，让我为你们解释一下什么是未定义行为，更重要的是它不是什么。

引用 C 标准：

未定义行为：本国际标准未做任何强制要求的行为。（Undefined behavior: behavior for which this International Standard imposes no requirements）

这意味着标准并没有规定某些表达式该如何表现，编译器的创造者们可以自由选择他们想要的行为，例如：

• 使编译失败
• 删除有问题的表达式并继续编译
• 发送给你的前任一条“我想你了”的消息
• 将你的票投给一个 XX 主义政党
• 甚至定义该行为（以平台特定的方式或非特定方式）

即，编译器的职责是合理处理未定义行为的情况。C 标准并没有对编译器作者提出挑战，这不是 “尽情发挥，给我惊喜”，它仅仅是对某些表达式没有施加限制，因为给予编译器作者自由选择其解决方案是合情合理的，因为这可能依赖于平台。

未定义行为并不是关于“被禁止的表达式”，它仅仅是语法上正确的 C 代码，而 C 标准对此并不关心。

到目前为止，这一切都是合理的。

在处理未定义行为时，编译器作者有多种选择：

• 偏向一致的语义
• 偏向性能
• 偏向实现的简单性
• …

正确的答案总是 “默认优先语义而非性能”。可以有破坏语义的优化，但这些优化应该通过适当的编译选项来启用，以便那些知道自己在做什么的人（或至少在继续破坏代码之前，编译器会得到明确的同意）使用。

（点击 more/continue 继续阅读）

Continue reading →