编程日志到这里，对象模型的探索就全部结束了，断断续续写了很久才把这些笔记整理出来，其中提到的点很多可能都已经不是现代编译器所采用的策略，不过这并不是作者所想要传达给我们的重点。这本书给我最大的收获就是”站在编译器的角度，如何在实现C++标准的同时在程序运行时、编译时、CPU占用和内存占用之间做出取舍”。重要的不是编译器采用了什么策略，而是采取某些策略时，编译器视角是如何考量的。
编译器对于全局对象的构造和析构的实现？
编译器对于局部静态对象的构造和析构实现？
delete [] ptr_array;时是怎么确定元素个数的？(大多数编译器的实现是在new[]返回的内存前端设置一块内存用来存放元素个数)
临时性对象被摧毁的时机应当是对完整表达式求值过程中的最后一个步骤。该完整表达式造成临时对象的产生。
凡持有表达式执行结果的临时性对象，应该存留到object的初始化操作完成为止。
Name Resolution within a Template:
- scope of the template definition
- scope of the template instantiation
Template中对于一个nonmember name 的决议结果是根据这个name的使用是否与”用以实例化该template的参数类型”有关而决定的。如果其使用互不相关，那么就以”scope of the template definition”来决定name，否则以”scope of the template instantiation”来决定name。
如和做到模板类和模板函数的按需实例化？
多个编译单元里的相同模板实例，如何做到只产生一份(编译时还是链接时)？
一般而言，exception handling 机制需要与编译器所产生的数据结构以及执行期的一个exception library紧密合作。在程序大小和执行速度之间，编译器必须有所抉择。
当一个exception发生时，编译系统必须完成以下事情：
- 校验发生throw的函数
- 决定throw操作是否发生在try区段中
- 若是，编译系统必须把exception type拿来和每一个catch 子句进行比较
- 如果比较后吻合，流程控制交到catch字句
- 如果throw发生并不在try区段中，或没有一个catch字句吻合那么系统必须,a.摧毁所有 active local objects、b.从堆栈中将目前函数unwind掉、c.回退到程序堆栈的上一个函数中去，重复上述2-5步骤
RTTI Runtime Type Identification
这个类型信息是放在那里的？每一个类的类型描述信息都是放在一个类型为typeinfo的class object中。 具有多态性质的类的typeinfo是放在虚表的其中一个slot中，一般来说是第一个。
dynamic_cast 使用在pointer上的时候，若成功则返回非零的地址，若失败则返回零
dynamic_cast 使用在reference上的时候，若成功则正常执行，若失败则抛出bad_cast exception
typeid运算符可以返回一个类型为type_info的const reference。
type_info objects 也适用于内建类型，以及非多态的使用者自定类型。这与多态类型(polymorphic type)的差异在于，这时候type_info object是静态取得，而非执行期取得。并且一般的实现策略是在需要时才产生type_info object，而非程序一开头就产生。
