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