STL, Loki,Boost
中
Functor
比較之
Boost
庫(kù)
(
一
)
??????
在這一部分中
,
要討論的是
Boost
庫(kù)中的
Function
的有關(guān)功能
,
于前面兩篇不同的是
,Boost
庫(kù)的規(guī)模相對(duì)于
Loki
和
STL
來(lái)說(shuō)
,
在規(guī)模上大了很多
,
這篇文章中討論的是
boost
中的
functor
部分
,
寫的不好之處
,
歡迎提出意見(jiàn)
.
寫作本文使用的是
Boost 1_33_1
版本
,
同時(shí)參考了
Boost
文檔的
function
部分的說(shuō)明
.
?
寫在前面
在
Boost
的
Function
功能中
,
用到了
Boost
的
Preprocessor,
在這部分中
Boost
提供的宏預(yù)處理功能是很強(qiáng)大的
,
主要的宏功能有
重復(fù)生成
(BOOST_PP_REPEAT_FROM_TO),
條件判斷
(BOOST_PP_IF),
連接
(BOOST_PP_CAT),
數(shù)值比較
(BOOST_PP_GREATER),
參數(shù)枚舉
(BOOST_PP_ENUM_PARAMS)
等
,
使用這些宏
,
可以按照自己的需要用宏生成模板類或者代碼
,
實(shí)在是一個(gè)很有效而且很創(chuàng)新的功能
,
可以說(shuō)把預(yù)處理器的功能用到了登峰造極的地步
.
不過(guò)
,
代價(jià)是要花更多的時(shí)間在編譯上
,
我有一個(gè)
18000
行代碼的工程
,
在一個(gè)頭文件中使用了
Preprocessor
產(chǎn)生一些模板代碼后
,
編譯時(shí)間從原先的
4
分鐘一下子升到了
8
分多秒
(
我的機(jī)器比較老
),
最后不得不寫了個(gè)功能
Proxy
類
,
隔絕
cpp
文件對(duì)該頭文件的依賴關(guān)系才縮短了編譯時(shí)間
.
TypeTraits typetraits
的功能是在給定一個(gè)數(shù)據(jù)類型后
,
通過(guò)
c++
的模板能力
,
來(lái)取得這個(gè)關(guān)于這個(gè)數(shù)據(jù)類型的相關(guān)信息
.
在
Loki
庫(kù)中
,
也提供了
TypeTrait
功能
.
常用的有
判斷是否為指針
,
判斷是否為常量
,
判斷是否為引用
,
判斷是否為數(shù)值等
.
在創(chuàng)建模板類或者函數(shù)的時(shí)候
,
有時(shí)候需要根據(jù)模板參數(shù)的類型對(duì)模板進(jìn)行特化
,
這是一個(gè)很重要的輔助功能
,boost
中也有
typetrait
功能
,
在
functor
生成的過(guò)程中
,
也使用了一些
typetrait
的功能
.
?
?
Boost
的的
Functor
的頭文件位于
<boost/function.hpp>
文件中
,
有一個(gè)很重要的宏
BOOST_FUNCTION_MAX_ARGS 用于
定義
boost
的預(yù)處理器展開(kāi)的
Functor
最多的參數(shù)個(gè)數(shù)
,
缺省的定義為
#define
?
BOOST_FUNCTION_MAX_ARGS
?
10
如果有需要擴(kuò)充
Functor
的參數(shù)個(gè)數(shù)
,
可以在包含
Boost Functor
頭文件之前
,
自己定義這個(gè)宏的數(shù)值
,
但是
,
最多可以到
50,
超過(guò)這個(gè)數(shù)值后
,
需要手工修改
<boost/function/detail/maybe_include.hpp>
中的代碼
,
是
Functor
可以使用的參數(shù)再進(jìn)行擴(kuò)充
.
?
Boost
的
Functor
的展開(kāi)
??????
在
Boost
中使用了預(yù)處理元編程提供的疊代頭文件的功能
,
反復(fù)疊代
<boost/function/function_template.hpp>,
最終生成使用所需要的模板類
?
boost::function
<
返回值
(
參數(shù)
[,
參數(shù)
]…)>,
用戶可以使用編譯器的
/P(
微軟
c++
編譯器
),? -save-temps(gcc
編譯器
)
開(kāi)查看宏展開(kāi)后的文件
.
?
?
?
有關(guān)
STL
和
Loki
中的
Functor
的前面兩篇位于我的另外一個(gè)
blog
http://blog.csdn.net/hdqqq/archive/2006/02/07/593877.aspx
http://blog.csdn.net/hdqqq/archive/2006/01/25/588348.aspx