一個周末過完了。
今天晚上腦子比較清醒，想清楚了tim中好幾個問題。
同時也想TT了，一轉(zhuǎn)眼，四個月沒見面了吧，仿佛昨天還在一起吃米線，還在一起上圖書館，還在寒冷的夜里出去買柚子，病了還有人照顧我，一切都是歷歷在目，不過再一算，已經(jīng)一年多了吧。
TT老婆，我會一輩子愛護你，關心你，照顧你。今天晚上也和朋友提起，我告訴他我其實沒什么理想，只要能幸福的和TT生活在一起，就足夠了，應該說，這才是我真正的理想。
有幸福的家，一定會有成功的事業(yè)。
摘要: 為了更容易理解后面的內(nèi)容，先給出登錄jabber服務器的交互包。
登錄的xml片斷Code highlighting produced by Actipro CodeHighlighter (freeware)http://www.CodeHighlighter.com/--> 1C: 2<?xml version="1.0"?>...
閱讀全文
其實四川電信的吳先生早就為我們提供了服務器，不過無奈網(wǎng)通電信本是冤家，自古就有“南電信北網(wǎng)通”的說法，我這里訪問吳先生提供的服務器，速度非常的慢。所以利用率一直不高。
這里感謝神州通訊的林先生，又為我們提供了服務器和二級域名(huyi.newxz.com)，這個空間主要用于存放和TIM項目相關的東西。
世界上可愛的人真多
在郵件列表中有朋友提出：
1
//我希望把string賦值10，然后顯示
2string Buffer;
3sprintf( Buffer.begin(),"%d",10);
4MessageBox(NULL,Buffer.begin(),NULL,MB_OK); 建個程序，編譯它，是通不過的。原因是Buffer沒有初值
，調(diào)用Buffer.begin()返回是NULL，第三句用MessageBox彈出一個NULL的字符串，這是不可取的。
1//改正后的程序
2string Buffer = "a"; //我隨便給了個初值
3sprintf( Buffer.begin(),"%d",10);
4MessageBox(NULL,Buffer.begin(),NULL,MB_OK);
但是，上面這段程序，可讀性能差。別人會想：作者為什么給個"a"而不是"b"呢？
所以我想請教大家：
（1）這問題有沒有更好的方法？最好不要MFC，也不用char數(shù)組，因為整個程序中其它地方我都用了string。
（2）STL為什么這么設計？
難道定義Buffer以后，還沒有分配空間？如果已經(jīng)有空間，為什么不用Begin()返回首個字符的地址？這樣做意義呵在？
解答一：
1// 這么定義：
2string Buffer(256, '\0');
3// 或者
4string Buffer;
5Buffer.reserve(256);
解答二：
1// 1.使用boost:Buffer = boost::lexical_cast<string>(10);
2// 2.如果不想用boost：
3#include <sstream>
4
5std::stringstream sstr;
6sstr << 10;
7Buffer = sstr.str();
8// 或者：
9Buffer = (std::stringstream() << 10).str();
解答三：
1 std::vector<char> buf(buffer_size, 0);
2 _snprintf(&buf[0], buffer_size, "%d\0", 10);
3 // 賦值給字符串
4 std::string str = &buf[0];
5 MessageBox(NULL, str.c_str(), NULL, MB_OK);
6//好處：
7// 1. 使用std::vector避免手動new/delete
8// 2. 使用stl可以充分利用stl的alloc（如stlport的memory pool)
9// 3. 使用_snprintf防止溢出
10// 4. std::string = std::vector（安逸:）
解答四：
1 char buf[32];
2 _snprintf(buf, 32, "%d", 10);//或者用itoa(10, buf, 10);
3 string str = buf;
有朋友發(fā)現(xiàn)一個錯誤：
看到一個明顯錯誤的做法：str.reserve(NLEN)之后直接去sprintf。要知道reserve只是把capacity擴充到NLEN，并不會擴充size。對于某些標準庫實現(xiàn)，這樣的做法極端危險，它會破壞string的不變式，導致一系列嚴重問題，比如str.size()和str.length()得到錯誤的值。
oscar.ken@gmail.com：
1#ifdef UNICODE
2
3# define tchar wchar_t
4# define tstring std::wstring
5
6#else
7
8# define tchar char
9# define tstring std::string
10
11#endif
12inline tstring FormatString(const tchar* fmt, 
)
13
{
14
static tchar tmp[2048];
15 memset(tmp, 0, 2048 * sizeof(tchar));
16 va_list args;
17 va_start(args, fmt);
18 int re = _vsntprintf(tmp, 2048, fmt, args);
19 va_end(args);
20 return tstring(tmp);
21
}
22
23// 如果2048不夠用，可以改造一個template版本
千里馬肝：
如果這樣
那不如直接使用boost::format導出一個stream的string，更安逸（當然會慢一些）
PS，對于FormatString為了保證format出來的是一個string，每次memset，個人認為無大必要，不如自動在formatstring的最后每次自動加上\0 (XD)
如果我沒有記錯的話
_snprintf是不會自動補\0的
而sprintf會
所以要么char buf[32] = {0}，要么_snprintf( "%d\0")
另外vector的使用是為了配合“不定長buf”而存在，并非buf[32]的替代品
Jiong Tu：
你搞錯了,不補0的是strncpy,不是snprintf
吳詠煒：
用 STL 的最大好處就是空間大小可以自動增長，不會發(fā)生緩沖區(qū)溢出（安全問
題）。否則，又何必付出緩慢的堆上分配的代價呢？——除非要把結(jié)果傳回去，那還
有意義；但最初蘇益彧提出的問題中并不存在這樣的需求。
另外順便提一下，如果棧上分配內(nèi)存大小不固定，也不一定就要改用堆上分配。
C99 支持數(shù)組大小運行時決定（而非 C89/C++98 的編譯時決定），而（不支持
C99 的）大部分 C/C++ 編譯器也都支持一個非標準的 alloca 函數(shù)用于進行棧上
分配。這個函數(shù)通常由編譯器內(nèi)聯(lián)實現(xiàn)，需要效率的場合會用得上。
另外，你測出的 50% 應當是總體的性能下降。純粹的內(nèi)存分配/釋放操作，堆上分
配和棧上分配的性能根本不在同一個量級，差距通常在十倍以上。
WL 提出：
很明顯 C++ 里面沒有一個很好的事件模型，除了 VC7
的統(tǒng)一事件模型之外，不知道大家都用的什么樣的事件模型，都是自己寫的嗎？VC7的統(tǒng)一事件模型不知道性能、開銷如何，文檔太少了。
詳細請參閱:http://groups.google.com/group/dev4server/browse_thread/thread/5e87109f87d60472/0acd3059709df059