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