深度探索C++对象模型/传世经典书丛

作者简介

内容简介

Member Function的实例化行为（Member Function Instantiation）对于template的支持，最困难的莫过于template function的实例化（instantiation）。目前的编译器提供了两个策略：一个是编译时期策略，程序代码必须在program text file中备妥可用； 另一个是链接时期策略，有一些meta.compilation工具可以导引编译器的实例化行为（instantiation）。 　　下面是编译器设计者必须回答的三个主要问题： 　　1.编译器如何找出函数的定义？ 　　答案之一是包含template program text file，就好像它是一个header文件一样。 　　Borland编译器就遵循这个策略。另一种方法是要求一个文件命名规则，例如，我们可以要求，在Point.h文件中发现的函数声明，其template program text一定要放置于文件Point.C或Point.cpp中，依此类推。cfront就遵循这个策略。Edison DesignGroup编译器对这两种策略都支持。 　　2.编译器如何能够只实例化程序中用到的member functions？ 　　解决办法之一就是，根本忽略这项要求，把一个已经实例化的class的所有member functions都产生出来。Borland就是这么做的——虽然它也提供#pragmas让你压制（或实例化）特定实例。另一种策略就是模拟链接操作，检测看看哪一个函数真正需要，然后只为它（们）产生实例。cfront就是这么做的。Edison DesignGroup编译器对这两种策略都支持。 　　3.编译器如何阻止member definitions在多个.o文件中都被实例化呢？ 　　解决办法之一就是产生多个实例，然后从链接器中提供支持，只留下其中一个实例，其余都忽略。另一个办法就是由使用者来导引“模拟链接阶段”的实例化策略，决定哪些实例（instances）才是所需求的。 　　目前，不论是编译时期还是链接时期的实例化（instantiation）策略，均存在以下弱点：当template实例被产生出来时，有时候会大量增加编译时间。很显然，这将是template functions第一次实例化时的必要条件。然而当那些函数被非必要地再次实例化，或是当“决定那些函数是否需要再实例化”所花的代价太大时，编译器的表现令人失望！ 　　C++支持template的原始意图可以想见是一个由使用者导引的自动实例化机制（use—directed automatic instantiation mechanism），既不需要使用者的介入，也不需要相同文件有多次的实例化行为。但是这已被证明是非常难以达成的任务，比任何人此刻所能想象的还要难（请参考[S7ROUP94]）。ptlink，随着cfront 3.0版所附的原始实例化工具，提供了一个由使用者驱动的自动实例化机制（use—drivenautomatic instantiation mechanism），但它实在太复杂了，即使是久经世故的人也没法一下子了解。 　　……