我们需要一个程序,传送信息到不同的公司去。信息要不译成密码,要不就是未加工的文字。如果编译期间我们有足够信息来决定哪一个信息传至那一家公司,就可以采用基于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的内容毫无所悉的缘故。
|
请发表评论