看了凌傑的文章（http://blog.csdn.net/owl2008/archive/2004/09/28/119595.aspx），也想補充兩句。lexical_cast比起stringstream來說，的確不一定簡潔，當然，其語義和可讀性都有提高，但同時也失之靈活。例如下面的情況，似乎就無法用lexical_cast辦到。
#include
using namespace std;
int main(int, char*)
如果想像筆者這樣在16進製制的整數和字串之間轉換，似乎還不得不用stringstream，我閱讀了lexical_cast的**，其實它就是用stringstream實現的，lexical_cast函式本身的**非常短，如下：
template
target lexical_cast(source arg)
主要的實現部分在lexical_stream的兩個過載方法：<< 和 >> 中，
..........
bool operator<<(const source &input)
template
bool operator>>(inputstreamable &output)
bool operator>>(std::string &output)
..........
關於lexical cast，一點補充
看了凌傑的文章 也想補充兩句。lexical cast比起stringstream來說，的確不一定簡潔，當然，其語義和可讀性都有提高，但同時也失之靈活。例如下面的情況，似乎就無法用lexical cast辦到。include using namespace std int main int,char...
關於streambuf一點東西
使用插入符和提取符時，一般程式設計師不知道或不必關心資料在 產生和消亡，不管處理的物件是標準i o 檔案 記憶體還是新建立的類或裝置。然而，重要的是與產生和消耗資料的輸入輸出流部分進行通訊為這部分提供統一的介面並隱藏底層實現，標準庫把他抽象成乙個類，成為streambuf.每個輸入輸出流物件都包含乙...
關於iBatis selectKey的一點筆記
技術前提 我們使用ibatis作為持久層方案 技術場景 假設我們有兩張表，一張主表main,一張子表sub,並且主表的主鍵是由資料庫維護的自增長的主鍵，子表中有乙個字段引用這個主鍵，那麼當我們插入主表資料後，就需要馬上返回這個自增長的主鍵。解決方案 可以在insert時通過ibatis的select...