一般情況下一個系統可以發送和接收的消息是確定的。例如前面的例子中，visitor可以發送AccessReq消息，可以接收AccessRsp消息，然而客戶在描述測試用例時卻可以傳遞非法的lambda給visitor。
例如：
TEST(...)
{
visitor.send([this](CfgReq& req)
{
req.capability = CAPABILITY;
});
//...
}
此時，visitor將會構造錯誤的消息發送給SUT，這可能會引起測試失敗，也可能不會。但無論如何，這種錯誤都會引起運行期發生一些異常。作為一個測試框架，我們希望能夠讓用戶抉擇是否把這種錯誤的發現提前到編譯期，一旦不小心傳遞了某一FakeSystem不支持的消息類型，就直接編譯失敗。同時用戶也可能想保留不進行類型校驗的權利，這樣就允許用戶刻意構造一些錯誤類型消息以觸發異常流程的測試。
FakeSystem既可以選擇校驗消息類型，也可以選擇不校驗，而且這種權利在客戶手里，于是我們采用基于policy的設計。對于模板所謂基于policy的設計，就是將類的變化部分分離出去，交給一個模板參數，然后再將其組合進來。而用戶就可以通過改變模板參數來定制目標類型的可變化部分了。
如下，我們首先定義一個FakeSystemBase，它和FakeSystem代碼基本一樣，只是它將如何進行消息檢測的規則通過模板參數MsgChecker注入進來，并調用MsgChecker對消息類型進行靜態校驗。
template<typename MsgChecker>
struct FakeSystemBase
{
template<typename BUILDER>
void send(const BUILDER& builder)
{
using Msg = __lambda_para(BUILDER, 0);
ASSERT_TRUE(typename MsgChecker::template IsValidForSend<Msg>);
MsgAllocator<Msg> allocator;
auto msg = allocator.alloc();
builder(*msg);
// ...
}
template<typename Checker>
void recv(const Checker& checker)
{
using Msg = __lambda_para(Checker, 0);
ASSERT_TRUE(typename MsgChecker::template IsValidForRecv<Msg>);
// ...
}
};
如上代碼約束MsgChecker的內部必須定義兩個模板元函數IsValidForSend<Msg>和IsValidForRecv<Msg>，分別對用戶傳入的發送和接收的消息類型進行合法性校驗。上面的ASSERT_TRUE(typename MsgChecker::template IsValidForSend<Msg>)中調用了TLP測試框架中的斷言ASSERT_TRUE，它是靜態斷言，當判斷類型不符就會編譯失敗。
接下來我們首先來實現一個MsgChecker，在任何情況下都返回真，以便實現不用校驗的FakeSystem。
struct OmmitMsgChecker
{
template<typename Msg>
using IsValidForSend = __true();
template<typename Msg>
using IsValidForRecv = __true();
};
有了它，原來的FakeSystem的定義修改如下。我們消除了重復代碼，并且保證了FakeSystem原有的使用習慣不變。
struct FakeSystem : FakeSystemBase<OmmitMsgChecker>
{
};
接來下我們定義對消息嚴格校驗的StrictFakeSystem。如下，它需要將發送和接收的合法消息列表當做模板參數傳入，以供類型校驗使用。
struct OmmitVerify;
template< typename ValidSendMsgs = OmmitVerify
, typename ValidRecvMsgs = OmmitVerify>
struct StrictFakeSystem : FakeSystemBase<StrictFakeSystem<ValidSendMsgs, ValidRecvMsgs>>
{
template<typename Msg>
using IsValidForSend = __if(__is_eq(ValidSendMsgs, OmmitVerify), __true(), __is_included(ValidSendMsgs, Msg));
template<typename Msg>
using IsValidForRecv = __if(__is_eq(ValidRecvMsgs, OmmitVerify), __true(), __is_included(ValidRecvMsgs, Msg));
};
StrictFakeSystem使用時需要傳入模板參數ValidSendMsgs和ValidRecvMsgs，它們是兩個TypeList，分別代表合法的發送消息類型列表和接收消息類型列表。它們還具有默認參數OmmitVerify，一旦使用默認參數，則代表放棄對發送或者接收消息的校驗能力。StrictFakeSystem的實現采用之前介紹過的CRTP(Curiously Recurring Template Pattern)模式。
現在客戶可以選擇將某些FakeSystem定義成需要嚴格判斷消息類型的了，例如：
using FakeVisitor = StrictFakeSystem<__type_list(AccessReq, CapabilityUpdate), __type_list(AccessRsp, UpdateRsp)>;
FakeVisitor visitor;
上述客戶聲明FakeVisitor僅支持發送AccessReq和CapabilityUpdate消息，僅支持接收AccessRsp和UpdateRsp消息。一旦用戶傳入的lambda表達式中的消息類型不符，就會出現編譯錯誤，如：visitor.send([](CfgReq& req){...})將會觸發由靜態斷言失敗引起的編譯錯誤。
最后有了StrictFakeSystem，原有的FakeSystem的定義也可以修改為：
struct FakeSystem : StrictFakeSystem<>
{
};
至此，我們保留了原有FakeSystem的用法，同時又讓用戶可以定義嚴格校驗發送和接收的消息類型的fake系統，從而讓框架變得更靈活和安全。
關于模板元編程在dates中的應用就介紹到這里。我們通過實際的例子列舉了模板元編程在現實代碼中的常用場景和使用技巧：
對trait的合理應用，可以讓代碼更加靈活，讓用戶代碼更加簡潔；
基于policy的設計技巧，可以讓用戶自定義目標類型的變化部分，可以讓代碼更易于被復用和組合；
通過類型抉擇選擇合適的算法類，讓代碼面對不同場景自動選擇最佳的處理方式，同時這種選擇又是對客戶透明的；
通過類型校驗，讓錯誤盡早發生，讓代碼更加的安全和健壯；
接下來，我們將介紹模板元編程更高階的用法，用于做代碼生成和創建DSL語言。
