粒子管理器的 C++ 封装
这篇接着上一篇 粒子系统的设计。
TL;DR 在花了一整个晚上用 C++ 完成了这一块的功能后，我陷入了自我怀疑中。到底花这么多精力做这么一小块功能有意义么？强调类型安全无非是为了减少与之关联的代码的缺陷，提高质量；但代码不那么浅显易懂却降低了质量。
我们用 C 实现了一个基于 ECS 结构的粒子系统的管理器，代码 psystem_manager.h 在这里。
先来回顾一下设计：在这个粒子系统中，我期望把粒子对象的不同属性分开管理。
即：传统的面向对象的数据结构中，一个对象 particle 可以有很多属性 a,b,c 。通常是用一个结构体（或类）静态定义出来的，这些属性也可以看作是 a b c 组件，它们构成了粒子对象。而在 ECS 结构中，我们在每个时间点，并非去处理一个对象的多个属性，而是处理同一个属性的多个对象。所以，我们最好按属性分类将多个对象的同一属性聚合起来，而不是按对象，把同一对象的不同属性聚合在一起。
这是因为，在处理单个属性时，往往并不关心别的属性。比如，我们在递减生命期，处理生命期结束的对象时，关心的仅仅是生命期这个属性；在处理粒子受到的重力或其它力的影响时，我们只关心当前的加速度和速度；在计算粒子的空间位置时，只关心上一次的位置和瞬间速度；而在渲染时候，无论是生命期、加速度、速度，这些均不关心。
当数据按属性聚合，代码在批量处理数据时，连续内存对 cache 友好，即使属性只有一个字节，也不会因为对齐问题浪费内存。同一属性的数据尺寸完全相同，处理起来更简单。而且粒子对象相互不受影响，我们只是把同一个操作作用在很多组数据上，次序不敏感。非常适合并行处理。
更重要的是，不同类型的粒子需要自由的根据需要组合属性和行为。有的粒子有物理信息参与刚体碰撞运算，有的则只需要显示不需要这个信息；有的粒子有颜色信息，有的不需要有；有的粒子是一个面片，有的却是一个模型，拥有不同的材质。这导致粒子对象包含的信息量是不同的。及时拥有同一属性，作用在上面的行为也可能不同：例如同样是物理形状信息，可能用于刚体碰撞，改变运动轨迹，也可能只是为了触发一下碰撞事件。
在传统的面向对象的方式中，常用多态（C++ 的虚函数）来实现，或者有大量的 if else switch case 。
如果能按组件和行为聚合，那么就能减少大量的分支。每个粒子的功能组合（打开某个特性关闭某个特性）也方便在运行时决定，而不用生成大量的静态类。
