在generic programming當(dāng)中，一個(gè)重要的概念就是concept（滑稽的是，如果把這個(gè)concept也翻譯成“概念”，那就狗屁不通了。我傾向于說它是“操作集”）。concept就是一組操作，如果一個(gè)type具有這些操作，那么就說這個(gè)type是這個(gè)concept的一個(gè)model。
這其中的思想有那么一丁點(diǎn)像是oo當(dāng)中的interface，一個(gè)class如果實(shí)現(xiàn)了一個(gè)interface，那么它就可以被當(dāng)作這個(gè)interface來用。同樣，如果一個(gè)type是一個(gè)concept的model，那么所有接受這個(gè)concept的操作也就可以接受這個(gè)type。
例如，在stl中，stable_sort這個(gè)算法必須接受randomaccessiterator，這里randomaccessiterator就是一個(gè)concept，它規(guī)定自己的model必須可以進(jìn)行下標(biāo)運(yùn)算，那么不滿足這個(gè)concept的type就無法被編譯器接受（搞笑的是我在vc71里面把list<int> 的iterator傳給stable_sort，它居然欣然接受，要知道list的iterator應(yīng)該只是一個(gè)bidirectionaliterator 啊，比randomaccessiterator弱多了。不過仔細(xì)看看代碼，發(fā)現(xiàn)vc71的stable_sort接受bidirectionaliterator就夠了，不知道是好還是壞）。在gcc下面如果傳遞一個(gè)bidirectionaliterator給stable_sort，會得到一堆不知所云的錯(cuò)誤提示，讓人摸不著頭腦。
c++語言本身并沒有對于concept的直接支持，stl解決這個(gè)問題的辦法是用了一些traits來限制iterator的特性，以達(dá)到在編譯時(shí)期檢查concept的目的。但是traits導(dǎo)致的編譯錯(cuò)誤提示實(shí)在是太可怕了，我非常懷疑有哪個(gè)正常人可以從這些錯(cuò)誤提示推測出自己錯(cuò)在哪里。
在boost庫里面，提供了一個(gè)conceptcheck庫，它可以幫助我們寫出帶有concept檢查的代碼，而且沒有運(yùn)行時(shí)的開銷，一旦用戶違反concept限制，輸出的錯(cuò)誤提示也比較好懂。舉個(gè)例子先，如果stl里面有conceptcheck，那么它的stable_sort大約會這樣：
#include <boost/concept_check.hpp>
template <class randomaccessiter>
void stable_sort(randomaccessiter first, randomaccessiter last)
{
function_requires< randomaccessiteratorconcept<randomaccessiter> >();
//... bla bla bla......
}
有了這個(gè) function_requires ，如果再傳遞給它list的iterator，編譯器（vc71）就會報(bào)這樣的錯(cuò)：
c:\boost_1_31_0\boost\concept_check.hpp(642): error c2676: 二進(jìn)制“+=” : “std::list<_ty>::iterator”不定義該運(yùn)算符或到預(yù)定義運(yùn)算符可接收的類型的轉(zhuǎn)換
with
[
_ty=int
]
當(dāng)然還有很多別的，但是至少它說了一點(diǎn)：傳入的iterator不滿足某個(gè)運(yùn)算。這對于用戶來說，應(yīng)當(dāng)是一個(gè)很有用的提示。
使用concept check還有一個(gè)額外的好處，那就是調(diào)用一個(gè) function_requires可遠(yuǎn)比寫一些traits容易，而且代碼也清晰好維護(hù)。
這個(gè)好用的 function_requires 就定義在concept_check.hpp當(dāng)中：
template <class concept>
inline void function_requires(mpl::identity<concept>* = 0)
{
#if !defined(ndebug)
void (concept::*x)() = boost_fptr concept::constraints;
ignore_unused_variable_warning(x);
#endif
}
換句話說，function_requires只在debug中起作用，那么是不是在debug當(dāng)中它就添加了overhead呢？其實(shí)也沒有，仔細(xì)看看代碼：
void (concept::*x)() = boost_fptr concept::constraints;
這一句取constraints的地址。妙就妙在它讓編譯器“注意到”constraints，但又沒有真正調(diào)用constraints，而constraints是一個(gè)虛函數(shù)，做實(shí)際的check。例如在randomaccessiteratorconcept（檢查iterator是否符合randomaccessiterator的concept）當(dāng)中，constraint是這個(gè)樣子：
template <class tt>
struct randomaccessiteratorconcept
{
void constraints() {
function_requires< bidirectionaliteratorconcept<tt> >();
function_requires< comparableconcept<tt> >();
#ifndef boost_no_std_iterator_traits
typedef typename std::iterator_traits<tt>::iterator_category c;
function_requires< convertibleconcept< c,
std::random_access_iterator_tag> >();
typedef typename std::iterator_traits<tt>::reference r;
#endif
i += n; // require assignment addition operator
i = i + n; i = n + i; // require addition with difference type
i -= n; // require assignment subtraction operator
i = i - n; // require subtraction with difference type
n = i - j; // require difference operator
(void)i[n]; // require element access operator
}
tt a, b;
tt i, j;
#ifndef boost_no_std_iterator_traits
typename std::iterator_traits<tt>::difference_type n;
#else
std::ptrdiff_t n;
#endif
};
從這個(gè)實(shí)現(xiàn)中我們完全可以讀出randomaccessiterator的具體含義：
1. 它必須是一個(gè)bidirectionaliterator
2. 它必須滿足“可比較 (comparable)”的concept
3. 它還必須滿足“可轉(zhuǎn)換 (convertible)”的concept，而且是轉(zhuǎn)換成自己的iterator_category類別
4. 它必須定義了reference這個(gè)type
5. 這是最重要的，它必須有difference_type，而且可以進(jìn)行 +, -, +=, -= 的運(yùn)算
還要記得，由于這個(gè)函數(shù)沒有真正的被調(diào)用過，所以無論你怎么寫，它都不會變成實(shí)際的代碼，所以也不會影響運(yùn)行效率的！