假设我们需要编写一个应用程序可以向多家不同的公司发送消息。消息可以以加密或明文未加密的形式发送。如果在编译期间我们有足够的信息来确定哪些消息将发送给哪些公司那么我们可以采用基于模板的解决方案这原本可以正常工作但假设我们有时希望在每次发送消息时记录一些信息。派生类可以很容易地添加这一功能而下面这种方式似乎很合理注意派生类中的消息发送函数与基类中的函数名称不同派生类中叫 sendClearMsg基类中叫 sendClear。这是好的设计因为它绕开了隐藏继承名称的问题参见条款33也避免了重新定义继承来的非虚函数所固有的问题参见条款36。但上面的代码无法编译至少对于符合标准的编译器来说是如此。这类编译器会抱怨 sendClear 不存在。我们能看到 sendClear 在基类中但编译器不会去那里查找。我们需要理解为什么。问题在于当编译器遇到类模板 LoggingMsgSender 的定义时它们不知道它继承自什么类。当然它是MsgSenderCompany但 Company 是一个模板参数要到后来当 LoggingMsgSender 被实例化时才能知道。在不知道 Company 是什么的情况下就没有办法知道MsgSenderCompany这个类长什么样。特别地也就无法知道它是否有一个 sendClear 函数。为了让问题具体化假设我们有一个坚持加密通信的 CompanyZ 类通用的 MsgSender 模板不适用于 CompanyZ因为该模板提供了一个对 CompanyZ 对象毫无意义的 sendClear 函数。为了纠正这个问题我们可以为 CompanyZ 创建一个 MsgSender 的特化版本注意这个类定义开头的template 语法。它表示这既不是一个模板也不是一个独立的类。相反它是 MsgSender 模板的一个特化版本当模板实参为 CompanyZ 时使用。这被称为全模板特化total template specialization即模板 MsgSender 针对类型 CompanyZ 进行了特化而且这个特化是全的——一旦类型参数被定义为 CompanyZ模板的其他参数就不可能再有任何变化了。鉴于 MsgSender 已经针对 CompanyZ 进行了特化再来看一下派生类 LoggingMsgSender正如注释所述当基类是MsgSenderCompanyZ时这段代码毫无意义因为那个类没有提供 sendClear 函数。这就是 C 拒绝该调用的原因它认识到基类模板可能会被特化而且这类特化可能不提供与通用模板相同的接口。因此它通常拒绝在模板化的基类中查找继承来的名称。从某种意义上说当我们从面向对象的 C 跨越到模板 C参见条款1时继承就失效了。要重新启用它我们必须以某种方式禁用 C 的“不要在模板化基类中查找”行为。有三种方法可以做到这一点。第一种你可以在调用基类函数时加上this-前缀第二种方法是使用 using 声明。如果你读过条款33这个解决方案应该会让你感到熟悉。条款33解释了 using 声明如何将隐藏的基类名称引入派生类的作用域。因此我们可以这样写 sendClearMsg虽然 using 声明在这里和条款33中都能用但所解决的问题是不同的。这里的情况并不是基类名称被派生类名称隐藏而是编译器不会去搜索基类作用域除非我们告诉它们这样做。第三种让代码编译的方法是显式指定被调用的函数在基类中这种做法通常是最不可取的方式因为如果被调用的函数是虚函数显式限定会关闭虚函数的动态绑定行为。从名称可见性的角度来看这三种做法效果相同它们都向编译器承诺基类模板的任何后续特化都会支持通用模板所提供的接口。当编译器解析像 LoggingMsgSender 这样的派生类模板时它们只需要这个承诺就足够了。但如果这个承诺最终不成立真相会在后续编译中暴露出来。例如如果源码后面出现这样一段对 sendClearMsg 的调用将无法编译因为在此时编译器已经知道基类是模板特化MsgSenderCompanyZ并且知道该类没有提供 sendClearMsg 试图调用的 sendClear 函数。从根本上说问题在于编译器是更早地诊断出对基类成员的错误引用在解析派生类模板定义时还是更晚在用特定模板实参实例化这些模板时。C 的策略是倾向于早期诊断这就是为什么它假定自己对从模板实例化出的基类内容一无所知。切记1.在派生类模板中通过 this- 前缀、using 声明或显式基类限定来引用基类模板中的名称。