我们需要一个程序，传送信息到不同的公司去。信息要不译成密码，要不就是未加工的文字。如果编译期间我们有足够信息来决定哪一个信息传至那一家公司，就可以采用基于template的解法：
class CompanyA{
public:
void sendCleartext(const std::string& msg);
void sendEncrypted(const std::string& msg);
};
class CompanyB{
public:
void sendCleartext(const std::string& msg);
void sendEncrypted(const std::string& msg);
};
... //针对其他公司设计的classes
class MsgInfo{...}; //这个class用来保存信息，以备将来产生信息
template<typename Company>
class MsgSender{
public:
void sendClear(const MsgInfo& info)
{
std::string msg;
根据info产生信息；
Company c;
c.sendCleartext(msg);
}
void sendSecret(const MsgInfo& info)
{
...;//调用c.sendEncrypted，类似sendClear
}
};这个做法行的通。但假设我们有时候想要在每次发送出信息的时候志记（log）某些信息。derived class可以轻易加上这样的行为，那似乎是个合情理的解法：
template<typename Company>
class LoggingMsgSender: public MsgSender<Company>{
public:
void sendClearMsg(const MsgInfo& info)
{
将传送前信息写至log；
sendClear(info);
}
};sendClearMsg 避免遮掩“继承而得的名称”（条款33），避免重新定义一个继承而得的non-virtual函数（条款36）。但上述代码无法通过编译，编译器看不到sendClear。为什么？
问题在于，编译器遇到class template LoggingMsgSender定义式时，并不知道它继承什么样的class。因为MsgSender<Company>中的Company是个template参数，不到后来（当LoggingMsgSender被具现化）无法确切知道它是什么。而如果不知道Company是什么，就无法知道class MsgSender<Company>看起来是个什么样----更明确的说是没办法知道它是否有个sendClear函数。
为了让问题具体化，假设有个class CompanyZ只是用加密通信：
class CompanyZ{
public:
void sendEncrypted(const std::string& msg);
};一般性的MsgSender template对CompanyZ并不合适，因为那个template提供了一个sendClear函数（其中针对其类型参数Company调用了sendCleartext函数），而这对CompanyZ对象并不合理。与纠正这个问题，我们可以针对CompanyZ产生一个MsgSender特化版；
template<> //一个全特化的
class MsgSender<CompanyZ>{ //MsgSender；它和一般template相同
public: //差别只在于它删掉了sendClear
void sendSecret(const MsgInfo& info)
{
...
}
};注意class定义式最前头“template<>”语法象征这既不是template也不是标准class，而是个特化版的MsgSender template，在template实参是CompanyZ时被使用。这事模板全特化（total template specialization）：template MsgSender针对类型CompanyZ特化了，而且其特化是全面性的，也就是说一旦类型参数被定为CompanyZ，再没有其他template参数可供变化。
template<typename Company>
class LoggingMsgSender: public MsgSender<Company>{
public:
void sendClearMsg(const MsgInfo& info)
{
将传送前信息写至log；
sendClear(info);//如果Company==CompanyZ，这个函数就不存在
}
};那就是为什么C++拒绝这个调用的原因：它知道base class template可能被特化，而那个特化版本可能不提供和一般属性template相同的接口。因此它往往拒绝在templatized base class（模板化基类，MsgSender<Company>）内寻找继承而来的名称（本例的SendClear）。从Object Oriented C++跨进Template c++继承就不想以前那般畅通无阻了。
我们必须令c++“进入templatized base classes观察”。有三个办法：
第一个办法是base class函数调用动作之前加上“this->”：
template<typename Company>
class LoggingMsgSender: public MsgSender<Company>{
public:
void sendClearMsg(const MsgInfo& info)
{
将传送前信息写至log；
this->sendClear(info); //成立，假设sendClear将被继承
}
};第二个办法是使用using 声明式：
template<typename Company>
class LoggingMsgSender: public MsgSender<Company>{
public:
using MsgSender<Company>::sendClear; //告诉编译器，请他假设sendClear位于base class内
void sendClearMsg(const MsgInfo& info)
{
将传送前信息写至log；
sendClear(info); //成立，假设sendClear将被继承
}
};这里的using声明式不是条款33中“base class名称被derived class名称遮掩”，而是编译器不进人base class作用域查找，于是我们通过using告诉它，请他这么做。
第三个做法是，明白指出被调用的函数位于base class内：
template<typename Company>
class LoggingMsgSender: public MsgSender<Company>{
public:
void sendClearMsg(const MsgInfo& info)
{
将传送前信息写至log；
MsgSender<Company>::sendClear(info); //成立，假设sendClear将被继承
}
};但这往往不是令人满意的一个解法，因为如果被调用的是virtual函数，上述的明确资格修饰MsgSender<Company>::会关闭virtual绑定行为。
从名称可视点的角度出发，上述每个解法做的事情都相同：对编译器承诺“base class template的任何特化版本都将支持其一般化版本所提供的接口”。这样一个承诺是编译器在解析（parse）像LoggingMsgSender这样的derived class template时需要的。但如果这个承诺最终未被实践出来，往后的编译器最终还是会给事实一个公道。例如，如果稍后的源码内含这个：
LoggingMsgSender<CompanyZ> zMsgSender;
MsgInfo msgData;
zMsgSender.sendClearMsg(msgData); //错误！无法通过编译。因为在那个点上，编译器知道base class是个template特化版本MsgSender<CompanyZ>，而它们知道那个class不提供sendClear函数，而这个函数却是sendClearMsg尝试调用的函数。
根本而言，面对“指涉base class members”之无效的references，编译器的诊断时间可能发生在早期（当解析derived class template的定义式时），也可能发生在晚期（当那些templates被特定之template实参具现化时）。C++的政策是宁愿早诊断。这就是为什么“当base classes从templates中被具现化时”它假设它对那base classes的内容毫无所悉的缘故。