Effective C++——条款43(第7章)

条款43: 学习处理模板化基类内的名称

Knoew how to access names in templatized base classes

    假设需要撰写一个程序,它能够传送信息到若干不同的公司去.信息或是译成密码,或是未加工的文字.如果编译期间就有足够信息来决定哪一个信息传递到哪一家公司,就可以采用基于 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);
    ...
};
...
class MsgInfo { ... };
template <typename Company>
class MsgSender {
public:
    ...
    void sendClear(const MsgInfo& info) {
        std::string msg;
        Company c;
        c.sendCleartext(msg);
    }
    void sendSecret(const MsgInfo& info) 
    { ... }
};

    这个做法行得通,但假设有时候想要在每次送出信息时记录某些信息,derived class 可轻易加上这样的生产力,那似乎是合情合理的解法:

template <typename Company>
class LoggingMsgSender : public MsgSender<Company> {
public:
    ...
    void sendClearMsg(const MsgInfo& info) {
        // 将"传送前"的信息写至log;
        sendClear(info);
        // 将"传送后"的信息写至log;
    }
    ...
};

    注意这个derived class 的信息传送函数有一个不同的名称,与其base class 内的名称不同.那 是个好设计,因为它避免遮掩"继承而得的名称"(详见 条款33),也避免重复定义一个继承而得的non-virtual 函数(详见 条款36). 但是上述代码无法通过编译,这样的编译器会警告sendClear不存在 .但是可以看到 sendClear确实存在于base class 内,编译器却看不到它们, 为什么?
    问题在于,当编译器遭遇 class template LoggingMsgSender定义式时,并不知道它继承什么样的 class.当然它继承的是MsgSender<Company>,但其中的Company是个 template 参数, 不到后来(当LoggingMsgSender被具现化)无法确切知道它是什么.而如果不知道Company是什么,就无法知道 class MsgSender<Company>看起来像什么, 更明确地说是没办法知道他是否有个sendClear函数.
   从某种意义而言,当 从Object Oriented C++跨进Template C++(详见 条款1), 继承就不像以前那样顺畅无阻了.
   为了重头来过,必须有某种办法令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被继承
        // 将"传送后"的信息写至log
    }
    ...
};

      第二是使用 using 声明式. 条款33描述 using 声明如何将"被掩盖的base class名称"带入一个derived class 作用域内.可以这样写下sendClearMsg:

template <typename Company>
class LoggingMsgSender : public MsgSender<Company> {
public:
    using MsgSender<Company>::sendClear;
    // 告诉编译器,请它假设sendClear位于base class内
    ...
    void sendClearMsg(const MsgInfo& info) {
        ...
        sendClear(info);
        ...
    }
    ...
};

    (虽然 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) {
        ...
        MsgSender<Company>::sendClear(info);
        // OK,假设sendClear将被继承下来
        ...
    }
    ...
};

    但这往往是最不让人满意的一个解法,因为如果被调用的是 virtual 函数,上述的明确资格修饰(explicit qualification)会关闭"virtual绑定行为".
    从名称可视点(visibility point)的角度出发,上述每一个解法做的事情都相同:对编译器承诺"base class template的任何特化版本都将支持其一般(泛化)版本所提供的接口".这样一个承诺是编译器在解析像LoggingMsgSender这样的derived class template 时需要的.
    根本而言,本条款探讨的是,面对"指涉base class members"的无效references,编译器的诊断时间可能发生在早期(当解析derived class template 的定义式时), 也可能发生在晚期( 当那些 template 被特定的 template 实参具现化时). C++的政策是宁愿较早诊断,这就是为什么"当base class从template中被具现化时", 它假设它对那些base class 内的内容毫无所悉的缘故.
    注意:
    可在derived class template 内通过 this-> 指涉base class template 内的成员名称,或借由一个明白写出的"base class资格修饰符"完成.