C 箴言：如何訪問模板化基類中的名字

假設我們要寫一個應用程序，它可以把消息傳送到幾個不同的公司去。消息既可以以加密方式也可以以明文（不加密）的方式傳送。如果我們有足夠的信息在編譯期間確定哪個消息將要發送給哪個公司，我們就可以用一個 template-based（模板基）來解決問題：

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 for other companies

class MsgInfo { ... }; // class for holding information
// used to create a message
template<typename Company>
class MsgSender {
public:
　... // ctors, dtor, etc.

　void sendClear(const MsgInfo& info)
　{
　　std::string msg;
　　create msg from info;

　　Company c;
　　c.sendCleartext(msg);
　}
　void sendSecret(const MsgInfo& info) // similar to sendClear, except
　{ ... } // calls c.sendEncrypted
};
　　這個能夠很好地工作，但是假設我們有時需要在每次發送消息的時候把一些信息記錄到日志中。通過一個 derived class（派生類）可以很簡單地增加這個功能，下面這個似乎是一個合理的方法：

template<typename Company>
class LoggingMsgSender: public MsgSender<Company> {
public:
　... // ctors, dtor, etc.
　void sendClearMsg(const MsgInfo& info)
　{
　　write "before sending" info to the log;
　　sendClear(info); // call base class function;
　　// this code will not compile!
　　write "after sending" info to the log;
　}
　...
};

　　注意 derived class（派生類）中的 message-sending function（消息發送函數）的名字 (sendClearMsg) 與它的 base class（基類）中的那個（在那里，它被稱為 sendClear）不同。這是一個好的設計，因為它避開了 hiding inherited names（隱藏繼承來的名字）的問題（參見《C 箴言：避免覆蓋通過繼承得到的名字》）和重定義一個 inherited non-virtual function（繼承來的非虛擬函數）的與生俱來的問題（參見《C 箴言：絕不重定義繼承的非虛擬函數》）。但是上面的代碼不能通過編譯，至少在符合標準的編譯器上不能。這樣的編譯器會抱怨 sendClear 不存在。我們可以看見 sendClear 就在 base class（基類）中，但編譯器不會到那里去尋找它。我們有必要理解這是為什么。

　　問題在于當編譯器遇到 class template（類模板）LoggingMsgSender 的 definition（定義）時，它們不知道它從哪個 class（類）繼承。當然，它是 MsgSender<Company>，但是 Company 是一個 template parameter（模板參數），這個直到更遲一些才能被確定（當 LoggingMsgSender 被實例化的時候）。不知道 Company 是什么，就沒有辦法知道 class（類）MsgSender<Company> 是什么樣子的。特別是，沒有辦法知道它是否有一個 sendClear function（函數）。

　　為了使問題具體化，假設我們有一個要求加密通訊的 class（類）CompanyZ：

class CompanyZ { // this class offers no
　public: // sendCleartext function
　...
　void sendEncrypted(const std::string& msg);
　...
};
　　一般的 MsgSender template（模板）不適用于 CompanyZ，因為那個模板提供一個 sendClear function（函數）對于 CompanyZ objects（對象）沒有意義。為了糾正這個問題，我們可以創建一個 MsgSender 針對 CompanyZ 的特化版本：

template<> // a total specialization of
class MsgSender<CompanyZ> { // MsgSender; the same as the
public: // general template, except
... // sendCleartext is omitted
void sendSecret(const MsgInfo& info)
{ ... }
};
　　注意這個 class definition（類定義）開始處的 "template <>" 語法。它表示這既不是一個 template（模板），也不是一個 standalone class（獨立類）。正確的說法是，它是一個用于 template argument（模板參數）為 CompanyZ 時的 MsgSender template（模板）的 specialized version（特化版本）。這以 total template specialization（完全模板特化）聞名：template（模板）MsgSender 針對類型 CompanyZ 被特化，而且這個 specialization（特化）是 total（完全）的——只要 type parameter（類型參數）被定義成了 CompanyZ，就沒有剩下能被改變的其它 template's parameters（模板參數）。

　　已知 MsgSender 針對 CompanyZ 被特化，再次考慮 derived class（派生類）LoggingMsgSender：

template<typename Company>
class LoggingMsgSender: public MsgSender<Company> {
　public:
　...
　void sendClearMsg(const MsgInfo& info)
　{
　　write "before sending" info to the log;
　　sendClear(info); // if Company == CompanyZ,
　　// this function doesn't exist!
　　write "after sending" info to the log;
　}
　...
};

　　就像注釋中寫的，當 base class（基類）是 MsgSender<CompanyZ> 時，這里的代碼是無意義的，因為那個類沒有提供 sendClear function（函數）。這就是為什么 C 拒絕這個調用：它認可 base class templates（基類模板）可以被特化，而這個特化不一定提供和 general template（通用模板）相同的 interface（接口）。結果，它通常會拒絕在 templatized base classes（模板化基類）中尋找 inherited names（繼承來的名字）。在某種意義上，當我們從 Object-oriented C 跨越到 Template C ，inheritance（繼承）會停止工作。

 

 

 

 

 

　　為了重新啟動它，我們必須以某種方式使 C 的 "don't look in templatized base classes"（不在模板基類中尋找）行為失效。有三種方法可以做到這一點。首先，你可以在調用 base class functions（基類函數）的前面加上 "this->"：

template<typename Company>
class LoggingMsgSender: public MsgSender<Company> {
public:
...

void sendClearMsg(const MsgInfo& info)
{
　write "before sending" info to the log;
　this->sendClear(info); // okay, assumes that
　// sendClear will be inherited
　write "after sending" info to the log;
}
...
};
　　第二，你可以使用一個 using declaration，如果你已經讀過《C 箴言：避免覆蓋通過繼承得到的名字》，這應該是你很熟悉的一種解決方案。該文解釋了 using declarations 如何將被隱藏的 base class names（基類名字）引入到一個 derived class（派生類）領域中。因此我們可以這樣寫 sendClearMsg：

template<typename Company>
class LoggingMsgSender: public MsgSender<Company> {
public:
　using MsgSender<Company>::sendClear; // tell compilers to assume
　... // that sendClear is in the
　// base class
　void sendClearMsg(const MsgInfo& info)
　{
　　...
　　sendClear(info); // okay, assumes that
　　... // sendClear will be inherited
　}
　...
};
　?。m然 using declaration 在這里和《C 箴言：避免覆蓋通過繼承得到的名字》中都可以工作，但要解決的問題是不同的。這里的情形不是 base class names（基類名字）被 derived class names（派生類名字）隱藏，而是如果我們不告訴它去做，編譯器就不會搜索 base class 領域。）

　　最后一個讓你的代碼通過編譯的辦法是顯式指定被調用的函數是在 base class（基類）中的：

template<typename Company>
class LoggingMsgSender: public MsgSender<Company> {
public:
...
void sendClearMsg(const MsgInfo& info)
{
　...
　MsgSender<Company>::sendClear(info); // okay, assumes that
　... // sendClear will be
} // inherited

...
};
　　通常這是一個解決這個問題的最不合人心的方法，因為如果被調用函數是 virtual（虛擬）的，顯式限定會關閉 virtual binding（虛擬綁定）行為。

　　從名字可見性的觀點來看，這里每一個方法都做了同樣的事情：它向編譯器保證任何后繼的 base class template（基類模板）的 specializations（特化）都將支持 general template（通用模板）提供的 interface（接口）。所有的編譯器在解析一個像 LoggingMsgSender 這樣的 derived class template（派生類模板）是，這樣一種保證都是必要的，但是如果保證被證實不成立，真相將在后繼的編譯過程中暴露。例如，如果后面的源代碼中包含這些，

LoggingMsgSender<CompanyZ> zMsgSender;
MsgInfo msgData;
... // put info in msgData
zMsgSender.sendClearMsg(msgData); // error! won't compile
　　對 sendClearMsg 的調用將不能編譯，因為在此刻，編譯器知道 base class（基類）是 template specialization（模板特化）MsgSender<CompanyZ>，它們也知道那個 class（類）沒有提供 sendClearMsg 試圖調用的 sendClear function（函數）。

　　從根本上說，問題就是編譯器是早些（當 derived class template definitions（派生類模板定義）被解析的時候）診斷對 base class members（基類成員）的非法引用，還是晚些時候（當那些 templates（模板）被特定的 template arguments（模板參數）實例化的時候）再進行。C 的方針是寧愿早診斷，而這就是為什么當那些 classes（類）被從 templates（模板）實例化的時候，它假裝不知道 base classes（基類）的內容。

　　Things to Remember

　　·在 derived class templates（派生類模板）中，可以經由 "this->" 前綴引用 base class templates（基類模板）中的名字，經由 using declarations，或經由一個 explicit base class qualification（顯式基類限定）。

原文轉自：http://www.kjueaiud.com

評論列表（網友評論僅供網友表達個人看法，并不表明本站同意其觀點或證實其描述）