浅谈[#include]读取顺序及继承逻辑

九千天华

在Ares时代总有人提到[]:[]继承失效和include无效的问题，往往是因为用户自身对include规则不了解所致

[B]:[A]式的继承A必须在B前被读取才能够得到继承，而include也是最后读取的覆盖前面的，因此include顺序关联了继承的前后，也就影响了继承的成功与否


那么Ares引擎中的include逻辑是按什么顺序读取的呢？




上面的图已经拆分了读取层次，最后输出[Section]Key=E


一种典型的错误逻辑是觉得按上面的A include B,D 然后B include C，那么C应当插入到B和D中间
然而很可惜这东西就不是插入式读取的，而是分层顺序读取的
按照插入式的逻辑，上图应该读取为ABCEDFG，而最后实际输出了Key=E显然证明这个顺序是错误的

实际上A后面先读自己include的B和D
然后读B的include C，然后读D的include FG
再读 C include 的E
最后顺序为ABDCFGE

简单概括实际读取规则就是：读完一层再读下一层

==其他==
[B]:[A]式继承不能用于子ini中第一个Section，如果保持第一个Section为注册表或者计划单之类的习惯估计都遇不到这个问题

继Westwood原版INI文件最后一行无法正常读取后，Phobos的$Include引入了子ini第一行不读取的问题

由于[B]:[A]式的Ares继承只会读取自己前面的内容，所以如果[A]在B的前面和后面各出现一次，B只会读取前面的A
如果你认为这是个Bug那么请用Phobos新增的$Inherits继承
基于这样的规则，你可以在B之后编辑A而不影响B正常继承原本的A，在只需要创建2个单位对照时，这样的写法效率奇佳并且非常简洁（多组那肯定就没必要了）

1. ;某子ini中
   
2. [MTNK]
   
3. ……
   
4. [YDUM]:[MTNK]
   
5. Speed=0
   
6. Passengers=5
   
7. PipScale=Passengers
   
8. InitialPayload.Types=QG
   
9. ……
   
10. [MTNK]
    
11. Secondary=HoverMissile
    
12. Turret=false
    
13. Explodes=true
    
14. ……
    

复制代码

如上所示，最终的MTNK与YDUM组成基于原有MTNK发展的两个不同结果，没有新注册任何单位，就算一直挂在UnitDelivery的Deliver.Types里也没影响
（YDUM是YR下[VehicleTypes]已注册的不存在对象，你自己有一个预先注册好但没有使用的同Type单位即可，此处仅为便于举例）

==多继承==
Ares 原生是不支持 [A]:[B]:[C] 这种写法的，但结合上面关于读取顺序的基础知识，我们可以使用下面的写法来实现相同的效果

1. [A]:[C]
   
2. [A]:[B]

复制代码

A 首先继承自 C，然后又从 B 继承，由于从 B 继承的部分更靠后，因此可以形成 A←B←C 的逻辑关系链条
既然有了多继承，那么对单个单位的功能性拆分就自由发挥了
注：两个同名节的写法仅在子 ini 中才能稳定工作，在主 ini（例如 rulesmd.ini）中使用这种写法风险自负。


==特注==
Ares 的 #include 最多 10 层

地球online玩家

好强喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵

双杀步枪

这才是一图流

航味麻酱

good

笨030504

WW原版INI最后一行无法正常读取这个bug在EC里面已经修了（
WWSB把判定文件结束写在了getline的后面，导致了getline到最后一行之后认为文件已经结束而break走人了

白羽鸽

写c++的人表示很熟悉，大佬讲的很仔细