小编Ali*_*ice的帖子

我正在尝试在Openshift上重新加载我的应用程序并遇到一些问题.如果运行rhc app restart或rhc app reload重新启动/重新加载应用程序无关紧要,我的环境变量不会重新加载.

然后,为了解决问题,我被迫停止并启动应用程序.

PS:Cartridge:python-2.7框架:Django

在开始时,有C.
和C有结构,表达和功能来打包它们.这很好.
但是C也有goto和switch case掉线和随后使用的语法,所以可能不那么好.

它也有指针,从别名和指针算术中引起大量咬牙切齿!
但它也有函数指针,允许运行时调度,并随后欢喜.
现在,数据可以指示代码,以及指示数据的代码,并且都是头等(或接近).
对于任何可以指出的东西,可以用同一个指针指出:圣洁的空虚*.

它的荣耀都是平等的.

然后C++来了,并将数据和代码绑定到Object中.
而且,这只是语法糖,因为函数和方法没有那么不同,
(无论Sun或Oracle可能告诉你什么).

Obj-> Foo(int val)与Foo(Obj*this,int val)相同(大约),它们
在神圣的空隙*下仍然相等.

然后,继承,冲突,因为外部Derived类可能会添加到内部Base.
但是,在这些简单的时代,我们找到了一个解决方案:在Derived之前放入每个Base.
然后,使用相同的指针,我们可以指向孩子和父亲.

而且,任何可以指出的东西,都可以指向圣洁的空虚*.

随着虚拟,我们失去了我们的简单,并徘徊了很长时间.
想知道,如何处理钻石,或者不是椭圆形的圆圈.
但是,即使我们抛弃了C的旧租户,每个指令都简化为简单的asm,
我们也接受了,有些东西应该看起来很简单(即使它们很复杂).

因此,我们查看了出现并认为"足够好"的秘密VTables.
在我们引入隐藏数据的同时,我们降低了复杂性.
现在,通过虚拟机进行的任何呼叫都通过VTable重定向.
由于一个类的所有子对象都可以通过单个指针指向,这就足够了.

但即使调度方法发生了变化,我们仍然可以指出所有事情,圣洁无效*.

但后来有人提出,目前很多人都认为这是一个严重的错误:多重继承.
并且一个指针不再足够!两位基础父亲如何才能在一开始？
那么,VTable就不再足够了,因为我们怎么知道要指向哪个子对象!
而现在,钻石的问题比以前更糟糕,没有明显的解决方案,而我们之前的钻石需要现有的代码来应对未来的前景!

因此,必须在每次虚拟呼叫时进行指针调整.
因为Base类可能真的是伪装的MI Derived类,需要进行调整.
因此,对于使用MI的Choice Few的支持,我们都付出了代价.

突然之间,圣洁的空虚*再也无法储存那些简单的糖.
处理这种复杂性的原因是可怕的成员函数指针.

野兽需要它自己的语法,因为其他人都不够.
而且这种语法很少使用,它的优先级如此之低,以至于每次使用都需要parans.
虽然在神圣的标准中,邪恶的议会决定允许这些可怜的东西被投射,
但是当从类型转换为类型时,不调用而不调用行为最不明确!

然而,在语法和贪婪方面颓废,他们是胖子,无法适应无效*.
作为了解要指向的对象的唯一方法是进行调整,
深入嵌入指针,并使用每个VTable查找进行检查.

但兄弟们,这不是必须的.
这种实施的复杂性来自于一种最特殊的决策.

class Base1
{
public:
    virtual void foo();
};

class Base2
{
public:
    virtual void bar();
};

class Derived: public Base1, public Base2
{
public:
    void unrelated();
}

如此处所示,在调用foo()或bar()时必须调整Derived*; 它不能同时指向Base1和Base2,就像简单单继承的情况一样.实际上,从基类调用时,确实无法正确预测需要多少偏移,这就是为什么大多数都有某种机制将其添加到vtable中.

然而: …