正在重构 Qt 官方的一个示例，顺便学习一点音频信号生成和 C++ Qt 开发。

这个等式就应该重构，为什么我们不先算每个 channel 的 byte length，再求总共的积？那样不是更符合正常思路吗？

void repeat(unsigned n, void(*op)(unsigned) ) {
for (unsigned i=0; i<n; i++) op(i);
}

不喜欢 C++

我数学不好，但还是了解了音频的 format、int channel、sample rate、sample size 什么的

不愧是 C++ 呢，各种 const noexcept override 让人感觉莫名其妙，stl 各种可以用的烂代码，保持傲慢与偏见，我从来不写没有用的代码，一个字符也不。
一个字符都不多写，刚刚好够用、明确就足够，C++ 新建抽象太麻烦，根本比不上 Kotlin 的安逸。
不是像大部分人，一个字符的解释也不多给、一条使用模型总结也不弄，只有自己写出来了就足够，也是刚刚好。

STL，是是，设计和算法非常好，但就是代码风格不能让正常人看，我不知道 _M_name 对人类可读性来说有什么好的，看起来什么东西都往一个文件放，不加任何解释和 brief，很 UNIX。

我都不知道同时弄什么客户 header 啊、实现啊，它给逻辑抽提制造的麻烦与那一点点『实现无关性』『简洁性』相比是熟轻熟重，看起来好像 header 和 preprocessor 这两个不得了的东西比程序员对代码维护的便利性还重要，C++ 就是不让你重构的，一开始就想好了嘛。

UNIX 和 C 就是一大堆意义不明的下划线，尤其是几个下划线连在一起的最为邪门，每天晚上 make 的时候啥玩意像 int 几个字节宽都重新检查一遍，就像那个啥每个项目的 automake.m4 都复制一遍，美其名曰 repeatable，一个小项目编译三分钟，真是妙不可言，尤其是令打包者心悦诚服。

程序员只应该考虑一件事情，就是脑子，就是要实现最重要的事情，最终对应到各种各样的抽象模型——时序、高阶流程控制、状态机、文件树、列表处理、数学计算、图形控件、2D画布，不是说七国语言精通各种运行环境和奇技淫巧，如果有，就让少数人解决、多数人享受解决方案。伺候什么构建系统啊？构建系统和依赖关系就该由工具解决，可工具偏偏还足够有『扩展性』弄得描述个软件包依赖都那么麻烦，什么 node_modules 啊、automake.m4、configure.ac 啊。

说白了就是 (rate * size) * channel 还是 rate * (size * channel) 的区别。
之前没那么弄是因为它有一个特别蹩脚的生成循环，我不得不尝试抽提出 SoundBuffer。

我还以为可以有很多 QApplication 实例呢，原来这都是静态方法啊，还好 clang-tidy 指出了这一点。

真的搞不懂如此混淆，只为写短点是有什么好处，那么多本来是 unsigned type 的东西非得用 int，还不统一，真是让人费解，Rust 是解决了这一点。

还是 clang 开发者懂得如何编程，至少比那一群只会算法的工程师代码风格强。

就命名而言，我还是觉得 byte short int long 这样的命名方式好一些的，唯一的例外是 Rust 那样 i8 u32 的命名方式，CLR 和 Qt 这种 uint8 真的会让非英语母语的人很困扰的。

C++ 不能随便 extension 真心累，Kotlin 里用惯了的。

我讨厌把非关键的东西写长，一个字符也不行，所以我用 C++ 的 using(typedef) 给 Qt 的 core primitives 都起了 Rust 式别名

这些写 sample 的程序员脑子很聪明，就是差点编程习惯……

像这个，的确不应该是手动解决，之前 drakeet 那个也算是发现问题，可是解决方案太难受了。

写完了 #Kotlin

利用 shuf 弄混这些项目：

#include <QTimer>
#include <QIODevice>
#include <QScopedPointer>
#include <QByteArray>
#include <QLabel>
#include <QSlider>
#include <QAudioOutput>
#include <QMainWindow>
#include <QPushButton>
#include <QComboBox>
#include <QObject>

解析器不成熟，所以不能有空行。真是浪费时间

换了赛扬，编译器死慢死慢，几乎不能用。

it >= a && it < b，我我明白了，原来 1 不在 (0 until 1) 的区间里。