子类化代替实例化，获得真正的和谐

instemast

sjinny: Re:子类化代替实例化，获得真正的和谐

汗……别扯那么多，越多我越看不明白……
你就用一句话说明问题的核心，再用一句话说明解决办法的本质……

在编程的时候，我们应该假设我们不是程序员，看看如何开发游戏，注意不是写一些废话，而是用自己的比较精确的语言去描述。
然后看看，我们自己的那套方法，能不能在计算机上实现出来。

图解：

要吃什么 -> 具体要吃什么 -> 烧饭

而不是：

要吃什么 -> 烧饭 -> 具体就吃这些，不行？那再重新烧

sjinny

还是不懂……
你的意图是不是防止多个地方修改同一个变量而产生耦合？

qrli

说白了，就是放弃速度和简单性，而追求逻辑的完美
或者说，放弃关注要实现的目标，而追求手段的完美

instemast

sjinny: Re:子类化代替实例化，获得真正的和谐

还是不懂……
你的意图是不是防止多个地方修改同一个变量而产生耦合？

变量？耦合？
这些东西都是不需要的

instemast

qrli: Re:子类化代替实例化，获得真正的和谐

说白了，就是放弃速度和简单性，而追求逻辑的完美
或者说，放弃关注要实现的目标，而追求手段的完美

我看java虚拟机上的程序，游戏脚本。。。都跑得好得很。

我的方式：数学规律和剧本 --> 机器码

一步到位，因为直接，所以可以获得很多编译优化。


传统方式：数学规律和剧本 --> 过程式代码 --> 机器码

因为多了一步，导致性能也不行。

PS.用GPU做游戏逻辑会非常快，我的工具可以自动生成GPU代码，
而你用CPU编程，累不说，速度还慢

qrli

连int 访问都要变成有虚表对象的虚函数调用，怎么才能快得起来呢

编译过程几乎没有一步到位的，因为那样就很难优化了。使用过程式代码做中间步骤并不会影响优化，何况现在的编译器大多不需要这一步，尽管C++因为历史原因看起来象是有这一步。GPU的工作方式和CPU很不同，条件逻辑密集的程序是不适合在GPU上运行的，因为严重影响性能。所以你的论断只是理论上成立。

instemast

qrli: Re:子类化代替实例化，获得真正的和谐

连int 访问都要变成有虚表对象的虚函数调用，怎么才能快得起来呢

编译过程几乎没有一步到位的，因为那样...

1
太形而上学了！
我把 2 种 书 写 格 式 更换了而已，怎么会速度慢？？
因为这个道理，可以不用虚表。

2
我都说我有10块钱，难道还没有5块钱？

3
我说了，我的语言不是以过程式（执行步骤）为主的，而是数学等式。
一般的游戏中，各个对象都是  并  行  的，用 GPU 实现正好。
（当然剧本的流程控制，状态转换等，用过程式）

instemast

起初我考虑到，instance本质上 == sub-class，换言之，不存在instance

昨天晚上，我意识到：
这就意味着，(因为instance和class是对立统一) class == base-class ，即不存在 class

于是，我100%想通了这么一个问题 ---- 什么是类和实例？

---- 本质上就是base-class和sub-class

这样，base-class, sub-class 这两个概念，在其他很多学科中都通用（数学，生物学，物理学，文学，历史）
比如，人类（按照某分类法）可以有有3个子类： 黑黄白三种人种。

sander_like_kof

什么!!! 连int 访问都要变成有虚表对象的虚函数调用

还好人类的的脑子在处理1+1=2的时候,不需要复杂的过程,不然那还不成为撒瓜才怪,我想起了数据库里表的模式里有最简单的模式,一泛式,任何事物都可以由复杂跌代为简单,最终有个原子性的,你这个是什么东东? 连int 访问都要变成有虚表对象的虚函数调用

sander_like_kof

问题核心：过程式编程 （过程式应该去写剧本和状态机）
解决方法：函数式编程，但剧本和状态机要用过程式（不少C++程序员用函数式写状态机）。

过程和函数的区别是什么啊? 我记得在delphi里过程是不返回的函数,说明过程是一中特殊的函数啊? 你这个怎么理解?