@xionghengheng 尝试撸过，坑了。

具体情况要具体分析。

比如“是不是比参加高考 然后考上一个重本学校更难” 这个得看你在什么地方，上的什么高中hhh

有人说要做游戏引擎，你得先去做游戏。有点道理，因为绝大多数游戏引擎，就是把某类游戏中最常见的东西造成轮子给你用，这一点类似“设计模式”，不去看设计模式的实例，没有在实际中用过设计模式，是很难说理解了设计模式的。

而且游戏引擎同样也是十分工程化的东西，完整的游戏引擎涉及到十分广泛的知识面和巨大的工作量（刚看了一堆UE4半懂不懂头疼死了...），大概就是说为什么“难”

现在有些人一说游戏引擎就是用了什么什么技术，有什么什么硬件滋瓷，渲染上面多么多么吊，造成这个现象背后因素比较复杂，但是游戏引擎所包含的绝不止图形一个部分，在我这 Rendering 仅仅是一般情况下的必要条件之一而已（“一般情况”的对立面如文字冒险游戏）。比如如果就是图个好玩，那么拉个 SFML 过来搞渲染照样能行。
多提两句，SFML 这个东西声称跨平台，跨语言，虽然我仅仅在 Win/Mac 下用 C++ 玩过，但是不得不说确实符合其 “Simple” 的名字。有一些硬伤（有时是不可忽视不可忍受的），但是拿它做最基本的图形轮子算是够了。
另一种观点就比较“互联网”，大概是随着手游和页游的兴起而出现的，就是说游戏引擎要获得市场，就得易用、还要跨各种电脑手机 Web 甚至 Console 平台，然后整一个编辑器傻子都能做游戏，当然产品基本也就一般打飞机游戏的格局，这种游戏拼创意，拼营销。但是终究会被某些单机党和主机党鄙视。
这是两个极端。

说白了不过是不同人口味不同，追求不同，目标市场也不同。
而如果自己要搞的话，道理也是差不多，你的游戏引擎（假设真的要自己撸一个出来的话）定位是什么样子的游戏？各方面的要求大概是怎样的？场景是 2D 还是 3D 的？要不要物理？如果有的话，那是 2D 还是 3D 的？目标平台是什么？场景大概多大？扩展性要求多高？AI 要做哪些内容？

我觉得首要解决的还是这些需求问题。至于剩下的技术，要在特定的方面啃个半吊子，还是很容易的。

只会用别人的物理引擎然后每次都被坑惨的渣渣路过...

Polymer 感觉确实有坑... 特别是推开官方组件库从头重做的...

@meteor2013 我不是做 iOS/Mac 的，所以不知道，不好意思。

表示很反感一说“游戏引擎”上来就说“图形引擎”的。

@lyf 据说 Rust 现在已经比较稳定了？

@regeditms 并没有听说过这个东西，涨姿势了~

回楼主，我一般的方法是点开 Target，然后点 Build Phase，Link Binary with Libraries，点加号就是。

我加过 .a，.dylib，.framework，.o，都可以。

@regeditms 好像是，但并不是所有人用 Xcode 都是做 Apple 那套东西。

“避免互联网出现分裂的可能”

“就像电影里说的，神不需要人类来保护，神也不会指定谁是自己的代言人、利用人们的敬畏之心坑蒙拐骗谋取利益，宗教从来都是哲学的一部分，更应该是关于世界观的探讨，让人们带着理性去思考，而不是捐钱保平安，盲从于各种被过分夸大的巧合吧”

说是这么说，但是实际中怎样鬼知道

Coq

https://en.wikipedia.org/wiki/Coq

贵省西电和东华的收分居然这么接近...

@XadillaX 突然发现 repo 里面那几张图里面有棵树特别像 RA2 里面的某个 asset...

@codercai 你也许把“子类实例是子类的父类部分与子类部分所拼接起来的”和这个搞混了
子类和父类实例使用不同的 vtable，其 vptr 的值也相应是不一样的。但是每个实例中只有一个 vptr（对于单继承来说是这样的）。

可以这样说，vtable 不能简单被分为“基类”和“子类”两个部分，一个对象的 vptr 所指 vtable，其中包含了该对象实际类型中所有可以用指针/引用直接调用虚函数（包括父类中未被子类 override 掉的，子类新定义的，和子类 override 掉父类的）。因此任何一个实例，只有一个 vptr 的位置（依然是只针对单继承）。

我个人平常的理解是，这个 vptr 相当于对象的一个“类型信息”或者类型的 ID，据我所知某些动态语言的实现中，对象实际在内存中的大小是不定的，但是每个对象头部的结构是确定的，这个头部中存储了必要的类型信息，据此可推导出对象的具体“类型”，以及该对象究竟符合哪一种布局。

C++ 中一个实例对象的实际类型可能有好几层继承，涉及到若干个基类，但是其类型总是能唯一确定的。

@codercai 另外，之所以基类和派生类不共用同一张虚函数表，我个人认为是因为同一个基类可能会派生出多个子类，并且它们可能会增加、覆盖不同的虚函数。

而在进行虚函数调用的时候，你所拥有的信息只有：一个 vptr 及该 vptr 指向的 vtable；类型定义；指针/引用的类型（不一定是对象实际类型，但是就算不是也一定是其基类）；由类型信息所推导出的，编译器写入可执行代码的一个索引。

这些信息，除了第一项是运行时的，后三项全部是编译时确定的。我觉得如果共用一张 vtable 的话，在以上条件下，是无法处理第一段所描述的复杂情况的。

@codercai 我细节很多地方都忘了，不过这块还是有点记忆的。

无论是基类还是派生类的对象实例，都只会有一个 vptr，占据对象布局中相同的位置。
所不同的只是其指向的虚表。

你想啊，加一个继承层次，就在其所有实例对象上加一个 vptr，这样做，和所有需要 vtable 的实例对象都有且只有一个 vptr，哪个成本低。
况且还有一个关键问题就是，如果子类实例对象有多个 vptr（单继承），当你使用基类指针调用虚函数的时候，是根本没有办法判断该指针所指对象是不是拥有楼主所推断出的“多出来”的那个 vptr 的。

实际情况是，基类和派生类的对象实例，都有且只有一个 vptr，并占据对象布局中相同的位置（当然是有虚函数的时候）。而在不同类型的对象实例中，这个指针指向不同的 vtable。

举个栗子，如果你知道了不同类型对象虚表的地址，在你对 C++ 搞出来的可执行程序做动态汇编调试的时候，找到一个对象的位置，那么在 hex view 里面瞄一眼这个对象的开始几个字节（vptr 的位置），就能知道这个对象是什么类型，我管这个叫人肉 RTTI :)

C++ 运行期多态的精髓，窃以为就在这个虚指针上。另外我个人一般是把这个 vptr 当作一个 data member 来看的。

@Septembers 那个维基的文章不错，谢谢了。

另外我认为有些包含重要信息的请求使用 GET 时，内容至少在客户端 URL 是直接可见的，POST 的话不开 Developer Tools 基本是看不到的。
最直接的影响之一就是我们学校的教务系统，可以直接用 GET 登录，结果就是 URL 放浏览器地址栏上别人过来瞄一眼密码全看见了（不要指望他会有加密...）。

并且如果你要在 HTML 中链接跨域的资源的话，是只能使用 GET 请求的。

高考完之后一段时间对二次元的东西很着迷，当然有很大的个人原因

现在再看反而觉得有些讨厌，与现实太遥远