weiyan

????????思考1 : 大局上面仍然有另一個(gè)大局
　　思考2 : 公平永遠(yuǎn)有不同角度的公平
　　思考3 : 這個(gè)游戲只有站在切換器旁邊的人可以決定結(jié)果

　　有一群小朋友在外面玩 而那個(gè)地方有兩條鐵軌，
　　一條還在使用， 一條已經(jīng)停用
　　只有一個(gè)小朋友選擇在停用的鐵軌上玩
　　其它的小朋友全都在仍在使用的鐵軌上玩

　　很不巧，火車來了(而且理所當(dāng)然的往上面有很多小孩的，仍在使用的鐵軌上行駛）

　　而你正站在鐵軌的切換器旁，因此你能讓火車轉(zhuǎn)往停用的鐵軌
　　這樣的話你就可以救了大多數(shù)的小朋友; 但是那名在停用鐵軌上的小朋友將被犧牲
　　你會(huì)怎么辦？

　　據(jù)說大多數(shù)人會(huì)選擇救多一些的人,換句話說，犧牲那名在停用鐵軌上玩的小孩...

　　但是這又引出另一個(gè)問題
　　那一名選擇停用鐵軌的小孩顯然是做出正確決定
　　脫離了他的朋友而選擇了安全的地方
　　而他的朋友們則是無知或任性的選擇在不該玩耍的地方玩
　　為什么做出正確抉擇的人要為了大多數(shù)人的無知而犧牲呢？

　　[響應(yīng)與挑戰(zhàn)]

　　這篇文章蠻發(fā)人深省的,看完了感觸很深!
　　我們常被教育要顧全大局,但公平嗎?

　　似乎當(dāng)大家都做的理所當(dāng)然的時(shí)候,
　　我們就必須隨波逐流,否則就會(huì)被放逐而不容于世,
　　如漁父中那位老翁勸屈原所說的:
　　世人皆濁,何不淈其泥而揚(yáng)其波?
　　眾人皆醉,何不餔其糟而歠其醨?
　　何故深思高舉,自令放為?

　　當(dāng)一個(gè)人太堅(jiān)持自己是"對"的,
　　最后的下場可能就是被犧牲的可憐鬼!
　　又有誰會(huì)為他掬一把同情之淚? 只會(huì)嘲笑他的愚蠢!

　　我們已經(jīng)進(jìn)了社會(huì),學(xué)習(xí)的就是圓滑的做人,
　　當(dāng)你是主管, 就像文章中那位切換軌道的人,
　　內(nèi)心的正義與現(xiàn)實(shí)沖突時(shí), 你會(huì)如何抉擇呢?

　　不過- 換另一個(gè)角度，如不選擇切換軌道
　　因?yàn)椋侨盒∨笥岩欢ㄖ滥鞘腔畹能壍?br />　　所以，當(dāng)他們聽到火車的聲音時(shí)，就會(huì)知道要跑!

　　但若，將軌道切換后那個(gè)乖小孩必定慘死，
　　因?yàn)椋麖膩頉]想過火車還會(huì)開到廢軌道上
　　所以，你認(rèn)為呢？

　　或許這樣的想法與理念，
　　到了人老時(shí)才會(huì)發(fā)現(xiàn)
　　自己成為一個(gè)不斷被犧牲的可憐鬼，
　　但這個(gè)社會(huì)又為什么要把是與非顛倒來又顛倒去呢？

　　另外，再想想，一條鐵道會(huì)被停止使用，自由它的道理。
　　是否代表著這個(gè)鐵道本身有問題，未經(jīng)驗(yàn)證就使用它會(huì)遇到潛藏的危機(jī)呢？

　　如果切過去之后，被犧牲的就不只是一個(gè)或一群小孩了，
　　而是整車的乘客呢？

在VC++下實(shí)現(xiàn)高彩色工具條

　　引言

　　一些Windows系統(tǒng)自帶程序如資源管理器、Internet Explorer等程序的工具條看上去和其他一些程序的工具條不太一樣，在顏色上要漂亮許多。其實(shí)這些程序的工具條上的圖標(biāo)均為256色，而普通應(yīng)用程序 在工具欄上所顯示圖標(biāo)的顏色通常只有16色，這就決定了后者在視覺上遠(yuǎn)沒有前者美觀。由于Windows隨系統(tǒng)而帶的程序也是由開發(fā)人員編寫的應(yīng)用程序， 這就說明通過程序編碼可以實(shí)現(xiàn)256色甚至更多色彩的圖標(biāo)在工具欄上的顯示。為此筆者經(jīng)過摸索，通過MFC編程在應(yīng)用程序中實(shí)現(xiàn)了高彩色工具條。現(xiàn)將實(shí)現(xiàn) 的主要方法介紹如下，以饗廣大讀者。

　　基本設(shè)計(jì)思路

　　在實(shí)現(xiàn)高彩色工具條之前，先研究一下普通16色的工具條的實(shí)現(xiàn)過程，并從中總結(jié)出改進(jìn)方法。在VC的資源視圖中工具條是一個(gè)資源名為 IDR_MAINFRAME的Toolbar型資源，并可通過在編輯按鈕上的圖標(biāo)來完成工具條上圖標(biāo)的繪制。雖然在資源視圖中工具條上各按鈕的圖標(biāo)是相互 獨(dú)立的，但在存儲時(shí)并非像圖標(biāo)一樣保存為ico格式文件而是以bmp位圖格式保存在磁盤上的。該位圖是一個(gè)由工具條上的按鈕圖標(biāo)組成的長條型位圖圖像，中 間沒有任何縫隙，在程序運(yùn)行和在資源視圖對工具條進(jìn)行編輯時(shí)該圖像首先裝載到一個(gè)圖像列表中，然后工具欄根據(jù)索引依次從圖像列表中將圖像顯示到工具條的各 個(gè)按鈕上。由于VC限制工具欄上的圖標(biāo)不能超出16色，因此不論是在資源視圖直接編輯位圖還是用復(fù)制粘貼等手段均無法獲取超出256色的工具條（注：用復(fù) 制粘貼的方法雖然在編輯視圖中可以暫時(shí)顯示出256色的圖標(biāo)，但在程序運(yùn)行時(shí)仍會(huì)退化成16色）。

　　由于不能在資源視圖中通過編輯Toolbar資源實(shí)現(xiàn)16色以上的圖標(biāo)，加之工具條在顯示時(shí)有并不直接從Toolbar獲取圖標(biāo)而是從圖像列表中讀 取，因此可以通過其他一些圖像處理軟件做好類似于工具條的bmp圖像（僅顏色比普通工具條bmp圖像豐富，其余完全一樣），并以位圖的形式加入到程序資 源。在使用時(shí)，先將其讀取到圖像列表，這樣圖像列表中用于顯示到工具條上的圖標(biāo)的顏色就可以是256、24位、甚至32位色的了。由于工具條缺省時(shí)將直接 加載資源名為IDR_MAINFRAME的Toolbar型資源作為圖標(biāo)的來源，因此還必須通過SetImageList（）函數(shù)將含有高彩色工具條位圖 的圖像列表指定為工具條的圖標(biāo)來源。

　　真彩工具條的實(shí)現(xiàn)

　　由于工具條的創(chuàng)建是在主框架類的OnCreate（）函數(shù)中完成的，因此高彩色圖像的裝載和圖像列表的替換工作必須也在此進(jìn)行。在進(jìn)行程序設(shè)計(jì)之前， 需要做好各種準(zhǔn)備工作，比如高彩色工具條位圖的繪制、高彩色位圖加入到資源等。繪制工具條位圖時(shí)，必須控制好圖像的尺寸，如需要有N個(gè)邊長為 M的圖標(biāo)，那么需要繪制的位圖尺寸為長=N*M；寬=M。真彩位圖在加入到工程之后就不能再在VC的資源視圖中進(jìn)行編輯了。由于這個(gè)彩色位圖僅起到美化界 面的作用，因此具體對的事件響應(yīng)等工作還要通過設(shè)置原有的Toolbar資源來完成。

　　準(zhǔn)備工作就緒后，先要把工具條位圖裝載到圖像列表，這樣才能被工具條做獲取。在作這一步時(shí)，必須用::LoadImage（）函數(shù)去加載工具條位圖，并通過宏MAKEINTRESOURCE()來指定具體要加載哪一個(gè)資源位圖：

HBITMAP hbm = (HBITMAP)::LoadImage(AfxGetInstanceHandle(),
MAKEINTRESOURCE(IDB_TOOLBAR), //加載IDB_TOOLBAR
IMAGE_BITMAP, //按位圖格式
0,0, // cx,cy
LR_CREATEDIBSECTION | LR_LOADMAP3DCOLORS );

LoadImage返回一個(gè)位圖句柄HBITMAP，但在MFC下使用CBitmaps會(huì)更加方便，可創(chuàng)建一個(gè)
CBitmap對象并用Attach()成員函數(shù)將它與位圖句柄聯(lián)系起來：

CBitmap bm;
bm.Attach(hbm);

　　MFC加載工具欄位圖時(shí)使用了一個(gè)內(nèi)部函數(shù)AfxLoadSysColorBitmap（）將缺省顏色設(shè)定為16色，因此為了顯示16色以上的圖像，必須在調(diào)用圖像列表類CImageList的Create（）函數(shù)創(chuàng)建圖像列表時(shí)對圖像清單做進(jìn)一步的處理：

m_ilToolBar.Create(32,32,ILC_COLOR8, 4, 4);
m_ilToolBar.Add(&bm,(CBitmap*)NULL);

　　這里用ILC_COLOR8標(biāo)明了創(chuàng)建的圖像列表是256色的，在VC的commctrl.h中對其有定義，并且還提供有其他幾種顏色位深度的預(yù)定義：

#define ILC_COLOR4 0x0004 //16色
#define ILC_COLOR8 0x0008 //256色
#define ILC_COLOR16 0x0010 //16位色
#define ILC_COLOR24 0x0018 //24位色
#define ILC_COLOR32 0x0020 //32位色

　　如果使用的工具條位圖只有256色（對于多數(shù)程序這樣已經(jīng)足夠），則顯然沒有必要再使用更高級別的位深度定義。最后一步，也是最關(guān)鍵的一步，必須通過 SetImageList（）函數(shù)指定工具條m_wndToolBar的圖標(biāo)來源不再是原來缺省的圖像列表而是含有高彩色位圖的圖像列表 m_ilToolBar：

m_wndToolBar.GetToolBarCtrl().SetImageList(&m_ilToolBar);

　　到此為止就可以通過MFC在自己編寫的程序中實(shí)現(xiàn)類似于IE等軟件的漂亮的工具條了。下圖就是筆者用上述方法得到的程序界面：



　　小結(jié)

　　本文通過對作為工具條圖標(biāo)來源的圖像列表的替換，實(shí)現(xiàn)了在普通MFC應(yīng)用程序中具備了以往只有Windows系統(tǒng)自帶程序才具備的高彩色工具條。較好 地美化了程序的界面。本文程序在Windows 98下，由Microsoft Visual C++ 6.0編譯通過。


用VC制作非常酷的工具條

　　自微軟推出Windows 95后,一大批全新的控件使我們的應(yīng)用程序更加美觀,使用也更加方便。其中一個(gè)顯著的變化就是工具條不再是一個(gè)突出的3D小方框,而是變成了平面的狀態(tài),但 是只要把鼠標(biāo)移動(dòng)到上面,它就會(huì)自動(dòng)地浮出來，大大方便了用戶。

　　筆者經(jīng)過一段時(shí)間摸索,終于找到了制作這種工具條的方法。原來Windows 95封裝了許多常用的控件,大都被放在Comctrl32.dll中，其中Toolbar控件是用于制作工具條的。下面 簡要介紹一下如何在VC5.0中添加一個(gè)Toolbar。

　　眾所周知,所有的控件都是某一類型的窗口,所以制作Toolbar也要從制作窗口開始。由于MFC的Toolbar類并不支持新的功能,所以我們只好用SDK方法,通過API調(diào)用來完成整個(gè)過程 ，該過程與制作一個(gè)傳統(tǒng)的工具條類似。

　　Toolbar是屬于comctrl32.dll的擴(kuò)展功能,所以要先調(diào)用InitCommonControlsEx()的函 數(shù)。該函數(shù)有一個(gè)重要的參數(shù)決定了對Toolbar的支持,它的主要作用是注冊Toolbar窗口,以 便在以后的程序中制作這種窗口,而普通的工具條則要調(diào)用InitCommandControls()。需要注意的是這兩個(gè)函數(shù)的寫法。

INITCOMMONCONTROLSEX icex;
DWORD dwStyle;
icex.dwSize = sizeof(INITCOMMONCONTROLSEX);

//注意下面這兩個(gè)參數(shù)決定了是否注冊Toolbar

icex.dwICC=ICC_COOL_CLASSES|ICC_BAR_ CLASSES;
InitCommonControlsEx(＆icex);



　　然后就可以調(diào)用CreateWindowEx這個(gè)函數(shù)來建立Toolbar窗口:

HWND hwndTB = CreateWindowEx(
WS_EX_TOOLWINDOW, //擴(kuò)展工具條風(fēng)格
TOOLBARCLASSNAME, //Toolbar類名
NULL,
WS_CHILD|WS_VISIBLE|TBSTYLE_FLAT， //窗口風(fēng)格
0,0,0,0, //大小
AfxGetApp()－＞GetMainWnd(), //父窗口名
NULL,
AfxGetInstanceHandle(), //實(shí)例
NULL);



　　判斷一下窗口句柄,如果不為空,就表示窗口建立成功。此時(shí)的Toolbar不過是一個(gè)空空的窗口，我們可以根據(jù)需要向里面添加按鈕。向Toolbar 中添加按鈕是通過向它發(fā)送消息來 實(shí)現(xiàn)的,以下過程與制作傳統(tǒng)的工具條基本一致。首先,建立一個(gè)ImageList控件,然后通過定義按鈕的數(shù)據(jù)結(jié)構(gòu)來確定每個(gè)按鈕的類型。
// 建立一個(gè)Imagelist 控件,

HWND himl;
//MYICON_CX,MYICON_CY是每個(gè)按鈕的大小
himl= ImageList_Create(MYICON_CX,MYICON_CY,ILC_COLOR4,0,4);

//加入事先作好的工具條位圖IDB_BITMAP2
ImageList_Add( himl,
LoadBitmap(AfxGetInstanceHandle(),MAKEINTRESOURCE(IDB_BITMAP2)),NULL);

//通過消息把位圖加入到Toolbar中
SendMessage(hwndTB, TB_SETIMAGELIST, 0, (LPARAM)himl);

　　下面加入5個(gè)普通的按鈕:

TBBUTTON tbArray[5]; //按鈕的數(shù)據(jù)結(jié)構(gòu)
for(i=0;i＜5;i＋＋)
{
tbArray[i].iBitmap = i; //第i個(gè)位圖
tbArray[i].idCommand = IDM_BUTTONSTART＋i;
//命令I(lǐng)D
tbArray[i].fsState = TBSTATE_ENABLED;
tbArray[i].fsStyle = TBSTYLE_BUTTON;
//按鈕風(fēng)格
tbArray[i].dwData = 0;
tbArray[i].iString = i; //顯示的字符串
}

//設(shè)置按鈕結(jié)構(gòu)的大小

::SendMessage(hwndTB,TB_BUTTONSTRUCTSIZE, sizeof(TBBUTTON), 0);
//添加按鈕到Toolbar中
::SendMessage(hwndTB,TB_ADDBUTTONS,(UINT)5, (LPARAM)tbArray);



　　至此,一個(gè)很酷的工具條基本上制作完成,最后再調(diào)用函數(shù)ShowWindow()即可: ShowWindow(hwndTB, SW_SHOWMAXIMIZED);

　　當(dāng)點(diǎn)擊按鈕時(shí),Toolbar就把消息傳送到父窗口中,由父窗口響應(yīng)消息。Toolbar中按鈕的ID包含在消息函數(shù)的wParam參數(shù)中,可以設(shè)置 它來調(diào)度不同的模塊。這時(shí)可以重載父窗口的O nCommand()函數(shù),根據(jù)wParam參數(shù)判斷點(diǎn)擊了哪個(gè)按鈕。假定父窗口是主窗口框架,代碼如下:

BOOL CMainFrame::OnCommand(WPARAM wParam,LPARAM lParam)
{
switch(wParam)
{
case IDM_BUTTONSTART＋0:
AfxMessageBox(“你點(diǎn)中了第一個(gè)按鈕!!", MB_ICONINFORMATION);
break;
case IDM_BUTTONSTART＋1:
AfxMessageBox(“你點(diǎn)中了第二個(gè)按鈕!!",MB_ICONINFORMATION);
break;
case IDM_BUTTONSTART＋2:
AfxMessageBox(“你點(diǎn)中了第三個(gè)按鈕!!", MB_ICONINFORMATION);
break;
}
return CMainFrame::OnCommand(wParam,lParam);
}

Visual C++ 版本6中工具條的新特色

Dave Schmi


　　微軟在www.microsoft.com/visualc已經(jīng)推出Visual C++6.0預(yù)覽版幾個(gè)月了。正式版預(yù)計(jì)到今年年底發(fā)布。同時(shí)，預(yù)覽版顯示出版本6將包含大量的改進(jìn)和提高，包括支持Internet控件,例如扁平工具 條等。雖然改進(jìn)的控件包與Internet無關(guān)，但它首先出現(xiàn)在Internet Explorer中，因此它就被取做這個(gè)名字了。事實(shí)上，官方發(fā)布的預(yù)覽版的標(biāo)題是“針對Internet Explorer 4.0的Visual C++ 5.0技術(shù)預(yù)覽”。

　　在以前關(guān)于MFC工具條類的討論專題中，我曾答應(yīng)提供一個(gè)在版本6中工具條的外觀演示。有一個(gè)很好的消息，那就是你現(xiàn)在用CToolBar所作的所有 工作在新的版本中都是有效的，包括那些在以前的欄目中所描述的一些擴(kuò)展功能。因此，你將很容易修改現(xiàn)存的程序以獲得象Internet Explorer和Visual Studio中那樣“酷”的界面。此外，并沒有什么壞消息。

工具條的新特色

　　早在版本4中，CToolBar就已被MFC庫完全實(shí)現(xiàn)了。一旦公用控件動(dòng)態(tài)鏈接庫（命名為comctl32.dll）變得無所不在了， CToolBar就成了如今已包含在操作系統(tǒng)中的工具條控件的代名詞了。然而，CToolBar并沒有揭示公用工具條控件的所有能力。如今，通過 CreateEx()函數(shù)，它成功了。

　　公用控件動(dòng)態(tài)鏈接庫現(xiàn)在包含了至少三類風(fēng)格：最初的、在Internet Explorer3.0中加入的以及在Internet Explorer 4.0中加入的。雖然這些版本理論上是向下兼容的，但某些專業(yè)人員曾寫出一些不能在后來版本中正常運(yùn)行的應(yīng)用程序，這可能是這些程序采用了一些沒有公開的 功能，而這些功能并沒有被包含在所有的版本中。

　　Visual C++程序員沒有這樣的經(jīng)歷，因?yàn)樵赩isual C++4.0或5.0中comctl32.dll并不是一個(gè)可以再分發(fā)的組件，它在安裝Internet Explorer時(shí)被更新，因此MFC程序員無法依靠最新版本的某些功能來用于他們的程序。這就是CToolBar僅僅具有最初的DLL的有限功能的原 因。CToolBar能夠?qū)崿F(xiàn)最新的特色意味著微軟將在Visual C++6.0中包含最新的DLL并將其作為一個(gè)可以再分發(fā)的組件。

　　絕大多數(shù)新特色將由在調(diào)用CreateEx()和其它CToolBar成員函數(shù)時(shí)指定的新的風(fēng)格標(biāo)志來確定。下面是commctrl.h的一部分，它定義了TBSTYLE類標(biāo)識符：


#define TBSTYLE_BUTTON 0x0000
#define TBSTYLE_SEP 0x0001
#define TBSTYLE_CHECK 0x0002
#define TBSTYLE_GROUP 0x0004
#define TBSTYLE_CHECKGROU TBSTYLE_GROUP | TBSTYLE_CHECK)
#if (_WIN32_IE $#@62;= 0x0300)
　　#define TBSTYLE_DROPDOWN 0x0008
#endif
#if (_WIN32_IE $#@62;= 0x0400)
　　#define TBSTYLE_AUTOSIZE 0x0010
　　#define TBSTYLE_NOPREFIX 0x0020
#endif

#define TBSTYLE_TOOLTIPS 0x0100
#define TBSTYLE_WRAPABLE 0x0200
#define TBSTYLE_ALTDRAG 0x0400
#if (_WIN32_IE $#@62;= 0x0300)
　　#define TBSTYLE_FLAT 0x0800
　　#define TBSTYLE_LIST 0x1000
　　#define TBSTYLE_CUSTOMERASE 0x2000
#endif
#if (_WIN32_IE $#@62;= 0x0400)
　　#define TBSTYLE_REGISTERDROP 0x4000
　　#define TBSTYLE_TRANSPARENT 0x8000
　　#define TBSTYLE_EX_DRAWDDARROWS 0x00000001
#endif



　　你會(huì)注意到其中的一些采用了條件編譯，依賴于_WIN32_IE的值，它缺省指的是Internet Explorer 4.0（即取值為0x0400）。對于Internet Explorer 3.0（即取值為0x0300）以前的版本，大多數(shù)的TBSTYLE標(biāo)識符指的是按鈕或是一組按鈕。Internet Explorer3.0引入了扁平鈕、文本標(biāo)簽、下拉列表和自定義繪制。Internet Explorer 4.0增強(qiáng)了下拉列表和自定義繪制功能，并且增加了支持OLE拖動(dòng)目標(biāo)到一個(gè)工具條。

扁平鈕和把手

　　在過去的18個(gè)月中我常常被問及該如何獲得象Internet Explorer和Visual Studio中的工具條一樣不使用浮雕按鈕而是用扁平鈕并且?guī)в斜阌谝苿?dòng)和定位的把手那樣酷的界面。這些特色并不被MFC所支持，因此最簡單獲取的方法就 是購買一個(gè)擴(kuò)展庫。而對于Visual C++ 6.0來說卻無須多此一舉，因?yàn)樗沟肅ToolBar類實(shí)現(xiàn)了對扁平鈕、把手和其它新的視覺效果的支持。

　　在預(yù)覽版中，AppWizard并不會(huì)自動(dòng)包括這些新特色，但它們卻很容易被加入。表1顯示了AppWizard創(chuàng)建的主框架窗口的OnCreate ()函數(shù)，表2顯示了需要做哪些修改以獲得具有扁平鈕和把手的工具條。圖1顯示了表1創(chuàng)建出的工具條，而圖2顯示出了表2實(shí)現(xiàn)的工具條。


表 1: CMainFrame::OnCreate as generated by AppWizard
int CMainFrame::OnCreate(LPCREATESTRUCT lpCreateStruct)
{
if(CMDIFrameWnd::OnCreate(lpCreateStruct) == -1)
　　return -1;

if(!m_wndToolBar.Create(this)||!m_wndToolBar.LoadToolBar(IDR_MAINFRAME))
　　{
　　　TRACE0("Failed to create toolbar\n");
　　　return -1; // fail to create
　　}

if(!m_wndStatusBar.Create(this) ||
　　!m_wndStatusBar.SetIndicators(indicators,sizeof(indicators)))
　　圖1
表2: Adding flat buttons and the gripper
int CMainFrame::OnCreate(LPCREATESTRUCT lpCreateStruct)
{
if(CMDIFrameWnd::OnCreate(lpCreateStruct) == -1)
　　return -1;

if(!m_wndToolBar.CreateEx(this)||!m_wndToolBar.LoadToolBar(IDR_MAINFRAME))
　　{
　　　TRACE0("Failed to create toolbar\n");
　　　return -1; // fail to create
　　}

if(!m_wndStatusBar.Create(this)||!m_wndStatusBar.SetIndicators(indicators,sizeof(indicators)/sizeof(UINT)))
{
TRACE0("Failed to create status bar\n");
return -1; // fail to create
}

// TODO: Remove this if you dont want tool tips or a resizeable toolbar
m_wndToolBar.SetBarStyle(m_wndToolBar.GetBarStyle() |
CBRS_GRIPPER | CBRS_BORDER_3D | CBRS_TOOLTIPS | CBRS_FLYBY | CBRS_SIZE_DYNAMIC);

// TODO: Delete these three lines if you dont want the toolbar to
// be dockable
m_wndToolBar.EnableDocking(CBRS_ALIGN_ANY);
EnableDocking(CBRS_ALIGN_ANY);
DockControlBar(&m_wndToolBar);

return 0;
}
圖2

　　為了作出扁平按鈕我必須使用CreateEx()來代替Create()。這個(gè)新的函數(shù)在afxext.h中聲明：

BOOL CreateEx
(
CWnd* pParentWnd, // parent window
DWORD dwCtrlStyle = TBSTYLE_FLAT, // extended style
DWORD dwStyle = // style
WS_CHILD | WS_VISIBLE | CBRS_ALIGN_TOP,
CRect rcBorders = CRect(0,0,0,0), // border rectangle
UINT nID = AFX_IDW_TOOLBAR // identifier
);


　　因?yàn)閿U(kuò)展風(fēng)格缺省指的就是TBSTYLE_FLAT，因此我要得到扁平按鈕就只需要簡單地將AppWizard形成的代碼中的Create()改為 CreateEx()即可。我將在后面實(shí)現(xiàn)其它的擴(kuò)展風(fēng)格。為了獲得把手，我必須在調(diào)用SetBarStyle()函數(shù)時(shí)包含CBRS_GRIPPER標(biāo) 志，參看表2。這是CControlBar類的一個(gè)新風(fēng)格，而CToolBar類是從它繼承而來的。請注意到我也加入了CBRS_BORDER_3D標(biāo) 志，這是為了修正一個(gè)未知的繪制問題，該問題將會(huì)在工具條的邊緣繪制一些多余的點(diǎn)。這也許意味著預(yù)覽版確實(shí)有這個(gè)問題，因?yàn)橐坏┪覍?D標(biāo)志加入就立即解 決了并且也似乎沒有影響到別的什么。

　　上面所作的兩個(gè)簡單的改變是使得一個(gè)已存程序獲得酷界面的最省力的方法。在一個(gè)程序具有了扁平鈕和把手的同時(shí)，它也不會(huì)發(fā)生不應(yīng)有的其它改變。

C/C+語言struct深層探索

出處：PConline

1. struct的巨大作用
　　面對一個(gè)人的大型C/C++程序時(shí)，只看其對struct的使用情況我們就可以對其編寫者的編程經(jīng)驗(yàn)進(jìn)行評估。因?yàn)橐粋€(gè)大型的C/C++程序，勢必要涉及一些(甚至大量)進(jìn)行數(shù)據(jù)組合的結(jié)構(gòu)體，這些結(jié)構(gòu)體可以將原本意義屬于一個(gè)整體的數(shù)據(jù)組合在一起。從某種程度上來說，會(huì)不會(huì)用struct，怎樣用struct是區(qū)別一個(gè)開發(fā)人員是否具備豐富開發(fā)經(jīng)歷的標(biāo)志。

　　在網(wǎng)絡(luò)協(xié)議、通信控制、嵌入式系統(tǒng)的C/C++編程中，我們經(jīng)常要傳送的不是簡單的字節(jié)流（char型數(shù)組），而是多種數(shù)據(jù)組合起來的一個(gè)整體，其表現(xiàn)形式是一個(gè)結(jié)構(gòu)體。

　　經(jīng)驗(yàn)不足的開發(fā)人員往往將所有需要傳送的內(nèi)容依順序保存在char型數(shù)組中，通過指針偏移的方法傳送網(wǎng)絡(luò)報(bào)文等信息。這樣做編程復(fù)雜，易出錯(cuò)，而且一旦控制方式及通信協(xié)議有所變化，程序就要進(jìn)行非常細(xì)致的修改。

　　一個(gè)有經(jīng)驗(yàn)的開發(fā)者則靈活運(yùn)用結(jié)構(gòu)體，舉一個(gè)例子，假設(shè)網(wǎng)絡(luò)或控制協(xié)議中需要傳送三種報(bào)文，其格式分別為packetA、packetB、packetC：

struct structA
{
int a;
char b;
};

struct structB
{
char a;
short b;
};

struct structC
{
int a;
char b;
float c;
}
　　優(yōu)秀的程序設(shè)計(jì)者這樣設(shè)計(jì)傳送的報(bào)文：

struct CommuPacket
{
int iPacketType;　　//報(bào)文類型標(biāo)志
union　　　　　　//每次傳送的是三種報(bào)文中的一種，使用union
{
? struct structA packetA;
? struct structB packetB;
? struct structC packetC;
}
};
　　在進(jìn)行報(bào)文傳送時(shí)，直接傳送struct CommuPacket一個(gè)整體。

　　假設(shè)發(fā)送函數(shù)的原形如下：

// pSendData：發(fā)送字節(jié)流的首地址，iLen：要發(fā)送的長度
Send(char * pSendData, unsigned int? iLen);
發(fā)送方可以直接進(jìn)行如下調(diào)用發(fā)送struct CommuPacket的一個(gè)實(shí)例sendCommuPacket：
Send( (char *)&sendCommuPacket , sizeof(CommuPacket) );
假設(shè)接收函數(shù)的原形如下：
// pRecvData：發(fā)送字節(jié)流的首地址，iLen：要接收的長度
//返回值：實(shí)際接收到的字節(jié)數(shù)
unsigned int Recv(char * pRecvData, unsigned int? iLen)；
　　接收方可以直接進(jìn)行如下調(diào)用將接收到的數(shù)據(jù)保存在struct CommuPacket的一個(gè)實(shí)例recvCommuPacket中：

Recv( (char *)&recvCommuPacket , sizeof(CommuPacket) );
　　接著判斷報(bào)文類型進(jìn)行相應(yīng)處理：

switch(recvCommuPacket. iPacketType)
{
??? case PACKET_A:
??? …??? //A類報(bào)文處理
??? break;
??? case PACKET_B:
??? …　? //B類報(bào)文處理
??? break;
??? case PACKET_C:
??? …?? //C類報(bào)文處理
??? break;
}
　　以上程序中最值得注意的是

Send( (char *)&sendCommuPacket , sizeof(CommuPacket) );
Recv( (char *)&recvCommuPacket , sizeof(CommuPacket) );
　　中的強(qiáng)制類型轉(zhuǎn)換：(char *)&sendCommuPacket、(char *)&recvCommuPacket，先取地址，再轉(zhuǎn)化為char型指針，這樣就可以直接利用處理字節(jié)流的函數(shù)。

　　利用這種強(qiáng)制類型轉(zhuǎn)化，我們還可以方便程序的編寫，例如要對sendCommuPacket所處內(nèi)存初始化為0，可以這樣調(diào)用標(biāo)準(zhǔn)庫函數(shù)memset()：

memset((char *)&sendCommuPacket,0, sizeof(CommuPacket));

2. struct的成員對齊
　　Intel、微軟等公司曾經(jīng)出過一道類似的面試題：
1. #include <iostream.h>
2. #pragma pack(8)
3. struct example1
4. {
5. short a;
6. long b;
7. };
8. struct example2
9. {
10. char c;
11. example1 struct1;
12. short e;???
13. };
14. #pragma pack()
15. int main(int argc, char* argv[])
16. {
17. example2 struct2;
18. cout << sizeof(example1) << endl;
19. cout << sizeof(example2) << endl;
20. cout << (unsigned int)(&struct2.struct1) - (unsigned int)(&struct2) << endl;
21. return 0;
22. }
　　問程序的輸入結(jié)果是什么？
　　答案是：
8
16
4
　　不明白？還是不明白？下面一一道來：
2.1 自然對界
　　struct是一種復(fù)合數(shù)據(jù)類型，其構(gòu)成元素既可以是基本數(shù)據(jù)類型（如int、long、float等）的變量，也可以是一些復(fù)合數(shù)據(jù)類型（如array、struct、union等）的數(shù)據(jù)單元。對于結(jié)構(gòu)體，編譯器會(huì)自動(dòng)進(jìn)行成員變量的對齊，以提高運(yùn)算效率。缺省情況下，編譯器為結(jié)構(gòu)體的每個(gè)成員按其自然對界（natural alignment）條件分配空間。各個(gè)成員按照它們被聲明的順序在內(nèi)存中順序存儲，第一個(gè)成員的地址和整個(gè)結(jié)構(gòu)的地址相同。
　　自然對界(natural alignment)即默認(rèn)對齊方式，是指按結(jié)構(gòu)體的成員中size最大的成員對齊。
　　例如：
struct naturalalign
{
char a;
short b;
char c;
};
　　在上述結(jié)構(gòu)體中，size最大的是short，其長度為2字節(jié)，因而結(jié)構(gòu)體中的char成員a、c都以2為單位對齊，sizeof(naturalalign)的結(jié)果等于6；
　　如果改為：
struct naturalalign
{
char a;
int b;
char c;
};
　　其結(jié)果顯然為12。

2.2指定對界
　　一般地，可以通過下面的方法來改變?nèi)笔〉膶鐥l件：
　　· 使用偽指令#pragma pack (n)，編譯器將按照n個(gè)字節(jié)對齊；
　　· 使用偽指令#pragma pack ()，取消自定義字節(jié)對齊方式。
　　注意：如果#pragma pack (n)中指定的n大于結(jié)構(gòu)體中最大成員的size，則其不起作用，結(jié)構(gòu)體仍然按照size最大的成員進(jìn)行對界。
　　例如：
#pragma pack (n)
struct naturalalign
{
char a;
int b;
char c;
};
#pragma pack ()
　　當(dāng)n為4、8、16時(shí)，其對齊方式均一樣，sizeof(naturalalign)的結(jié)果都等于12。而當(dāng)n為2時(shí)，其發(fā)揮了作用，使得sizeof(naturalalign)的結(jié)果為8。
　　在VC++ 6.0編譯器中，我們可以指定其對界方式，其操作方式為依次選擇projetct > setting > C/C++菜單，在struct member alignment中指定你要的對界方式。
　　另外，通過__attribute((aligned (n)))也可以讓所作用的結(jié)構(gòu)體成員對齊在n字節(jié)邊界上，但是它較少被使用，因而不作詳細(xì)講解。

2.3 面試題的解答
　　至此，我們可以對Intel、微軟的面試題進(jìn)行全面的解答。
　　程序中第2行#pragma pack (8)雖然指定了對界為8，但是由于struct example1中的成員最大size為4（long變量size為4），故struct example1仍然按4字節(jié)對界，struct example1的size為8，即第18行的輸出結(jié)果；
　　struct example2中包含了struct example1，其本身包含的簡單數(shù)據(jù)成員的最大size為2（short變量e），但是因?yàn)槠浒藄truct example1，而struct example1中的最大成員size為4，struct example2也應(yīng)以4對界，#pragma pack (8)中指定的對界對struct example2也不起作用，故19行的輸出結(jié)果為16；
　　由于struct example2中的成員以4為單位對界，故其char變量c后應(yīng)補(bǔ)充3個(gè)空，其后才是成員struct1的內(nèi)存空間，20行的輸出結(jié)果為4。

Class Diagrams
Class diagrams are the backbone of almost every object oriented method, including UML. They describe the static structure of a system.

Object Diagrams
Object diagrams describe the static structure of a system at a particular time. They can be used to test class diagrams for accuracy.

Use Case Diagrams
Use case diagrams model the functionality of system using actors and use cases.

Activity Diagrams
Activity diagrams illustrate the dynamic nature of a system by modeling the flow of control from activity to activity. An activity represents an operation on some class in the system that results in a change in the state of the system. Typically, activity diagrams are used to model workflow or business processes and internal operation.

?

Sequence Diagrams
Sequence diagrams describe interactions among classes in terms of an exchange of messages over time.

Collaboration Diagrams
Collaboration diagrams represent interactions between objects as a series of sequenced messages. Collaboration diagrams describe both the static structure and the dynamic behavior of a system.

?

Statechart Diagrams
Statechart diagrams describe the dynamic behavior of a system in response to external stimuli. Statechart diagrams are especially useful in modeling reactive objects whose states are triggered by specific events.

?

Component Diagrams
Component diagrams describe the organization of physical software components, including source code, run-time (binary) code, and executables.

?

Deployment Diagrams
Deployment diagrams depict the physical resources in a system, including nodes, components, and connections.

?

Package Diagrams
Package diagrams are a subset of class diagrams, but developers sometimes treat them as a separate technique. Package diagrams organize elements of a system into related groups to minimize dependencies between packages

二進(jìn)制大對象BLOB(Binary Large Object)
其存取的方式與普通數(shù)據(jù)有所區(qū)別。本文將介紹利用ADO在數(shù)據(jù)庫中存取BLOB數(shù)據(jù)的具體實(shí)現(xiàn)過程，并給出實(shí)現(xiàn)圖像存取顯示的完整示例工程。

二、前期準(zhǔn)備

首先我們建立一張名為userinfo的表，包含三個(gè)字段:id,username,old,photo,其中photo是一個(gè)可以存儲二進(jìn)制數(shù)據(jù)的字段。

2.1 在SQL SERVER中我們可以在Query Analyzer中直接輸入如下語句創(chuàng)建：

CREATE TABLE [dbo].[userphoto] (
[id] [int] IDENTITY (1, 1) NOT NULL ,
[username] [varchar] (50) NULL ,
[old] [int] NULL ,
[photo] [image] NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
其中photo我們定義為image類型的字段。

2.2 在ACCESS中創(chuàng)建的方法如下：

建立一張新表包括id,username,old,photo四個(gè)字段，然后打開表，選視圖菜單中設(shè)計(jì)視圖，將id設(shè)置為自動(dòng)編號的遞增長整型，username為文本，old為數(shù)字，photo為OLE對象。
在我們的示例工程中已經(jīng)包含了一個(gè)建立好的ACCESS2000的庫，你可以直接拿來使用。

三、具體步驟

3.1 BLOB數(shù)據(jù)的保存

BLOB類型的數(shù)據(jù)無法用普通的方式進(jìn)行存儲，我們需要使用AppendChunk函數(shù)，AppendChunk包含在Field對象中，原型如下：
HRESULT AppendChunk (const _variant_t & Data );
從函數(shù)原型中可以看到關(guān)鍵的問題是我們需把二進(jìn)制數(shù)據(jù)賦值給VARIANT類型的變量，下面我們給出具體的代碼并作簡單的分析:

///假設(shè)m_pBMPBuffer指針指向一塊長度為m_nFileLen的二進(jìn)制數(shù)據(jù),并且已經(jīng)成功打開了記錄集對象m_pRecordset///

char *pBuf = m_pBMPBuffer ;
VARIANT varBLOB;
SAFEARRAY *psa;
SAFEARRAYBOUND rgsabound[1];

m_pRecordset->AddNew(); ///添加新記錄
m_pRecordset->PutCollect("username",_variant_t("小李")); ///為新記錄填充username字段
m_pRecordset->PutCollect("old",_variant_t((long)28); ///填充old字段

if(pBuf){
rgsabound[0].lLbound = 0;
rgsabound[0].cElements = m_nFileLen;
psa = SafeArrayCreate(VT_UI1, 1, rgsabound); ///創(chuàng)建SAFEARRAY對象

for (long i = 0; i < (long)m_nFileLen; i++)
SafeArrayPutElement (psa, &i, pBuf++); ///將pBuf指向的二進(jìn)制數(shù)據(jù)保存到SAFEARRAY對象psa中

varBLOB.vt = VT_ARRAY | VT_UI1;///將varBLOB的類型設(shè)置為BYTE類型的數(shù)組

varBLOB.parray = psa; ///為varBLOB變量賦值

m_pRecordset->GetFields()->GetItem("photo")->AppendChunk(varBLOB); ///加入BLOB類型的數(shù)據(jù)
}

m_pRecordset->Update(); ///保存我們的數(shù)據(jù)到庫中

至此我們的數(shù)據(jù)已經(jīng)成功地保存到了數(shù)據(jù)庫中,接下來我們所要做的工作便是將該數(shù)據(jù)提取出來,讓我們繼續(xù)吧!

3.2 BLOB數(shù)據(jù)的讀取

對應(yīng)于保存數(shù)據(jù)時(shí)我們所使用的AppendChunk函數(shù)，讀取數(shù)據(jù)應(yīng)該使用GetChunk函數(shù),GetChunk的原型如下:
_variant_t GetChunk (long Length );
給出數(shù)據(jù)的長度后GetChunk將返回包含數(shù)據(jù)的VARIANT類型變量,然后我們可以利用SafeArrayAccessData函數(shù)得到VARIANT變量中指向數(shù)據(jù)的char *類型的指針,以方便我們的處理，具體代碼如下：

long lDataSize = m_pRecordset->GetFields()->GetItem("photo")->ActualSize;
///得到數(shù)據(jù)的長度

if(lDataSize > 0)
{
_variant_t varBLOB;

varBLOB = m_pRecordset->GetFields()->GetItem("photo")->GetChunk(lDataSize);

if(varBLOB.vt == (VT_ARRAY | VT_UI1)) ///判斷數(shù)據(jù)類型是否正確
{
　　 char *pBuf = NULL;
　　 SafeArrayAccessData(varBLOB.parray,(void **)&pBuf);
　　 ///得到指向數(shù)據(jù)的指針 /*****在這里我們可以對pBuf中的數(shù)據(jù)進(jìn)行處理*****/
　　 SafeArrayUnaccessData (varBLOB.parray);
　　 }

}

以上我們成功實(shí)現(xiàn)了BLOB數(shù)據(jù)在數(shù)據(jù)庫中的存取，為了讓大家有現(xiàn)成的例子可以參考，本文提供了示例工程，在示例工程中我們在數(shù)據(jù)庫中保存圖像數(shù)據(jù)，并可以對這些圖像進(jìn)行瀏覽、修改，該例子還涉及到如何用char *指向的BMP文件數(shù)據(jù)創(chuàng)建BITMAP對象然后顯示出來。

l???????? 創(chuàng)建

??????????????????????????? long i = 0; ??????????????????????????? VARIANT va = {0}; ??????????????????????????? va . vt = VT_BSTR ; ??????????????????????????? ??????????????????????????? SAFEARRAYBOUND bounds [1] = {0}; ??????????????????????????? bounds [0]. cElements = 5; ??????????????????????????? SAFEARRAY * psa = SafeArrayCreate ( VT_VARIANT , 1, bounds );

?

l???????? 存入元素

??????????????????????????? for ( i = 0; i < 5; i ++) ??????????????????????????? { ???????????????????????????????????? va . bstrVal = SysAllocString (L "test" ); ???????????????????????????????????? SafeArrayPutElement ( psa , & i , & va ); ??????????????????????????? }

?

l???????? 獲取元素

??????????????????????????? for ( i = 0; i < 5; i ++) ??????????????????????????? { ???????????????????????????????????? va . bstrVal = SysAllocString (L "test" ); ???????????????????????????????????? SafeArrayGetElement ( psa , & i , & va ); ???????????????????????????????????? SysFreeString ( va . bstrVal ); ??????????????????????????? }

?

l???????? 銷毀

??????????????????????????? SafeArrayDestroy ( psa );

?

l???????? 生成 VARIANT 變量

??????????????????????????? VARIANT vsa = {0}; ??????????????????????????? vsa . vt = VT_ARRAY | VT_BSTR ; ??????????????????????????? vsa . parray = psa ;

?????????野指針，也就是指向不可用內(nèi)存區(qū)域的指針。通常對這種指針進(jìn)行操作的話，將會(huì)使程序發(fā)生不可預(yù)知的錯(cuò)誤。但是，我在文中要說的，就是野指針的“安全”使用方法以及其內(nèi)部的原因.

首先請諸位看以下一段“危險(xiǎn)”的C++代碼：

void?function(?void?) { ????char*?str?=?new?char[100]; ????delete[]?str; ????//?Do?something ????strcpy(?str,?"Dangerous!!"?); }

之所以說其危險(xiǎn)，是因?yàn)檫@是一段完全合乎語法的代碼，編譯的時(shí)候完美得一點(diǎn)錯(cuò)誤也不會(huì)有，然而當(dāng)運(yùn)行到strcpy一句的時(shí)候，問題就會(huì)出現(xiàn)，因?yàn)樵谶@之前，str的空間已經(jīng)被delete掉了，所以strcpy當(dāng)然不會(huì)成功。對于這種類似的情況，在林銳博士的書中有過介紹，稱其為“野指針”。

那么，諸位有沒有見過安全的“野指針”呢？下面請看我的一段C++程序，靈感來自CSDN上的一次討論。在此，我只需要C++的“類”，C++的其余一概不需要，因此我沒有使用任何的C++標(biāo)準(zhǔn)庫，連輸出都是用printf完成的。

#include?<stdio.h> class?CTestClass { public: ????CTestClass(?void?); ????int?m_nInteger; ????void?Function(?void?); }; CTestClass::CTestClass(?void?) { ????m_nInteger?=?0; } void?CTestClass::Function(?void?) { ????printf(?"This?is?a?test?function.\n"?); } void?main(?void?) { ????CTestClass*?p?=?new?CTestClass; ????delete?p; ????p->Function(); }

OK，程序到此為止，諸位可以編譯運(yùn)行一下看看結(jié)果如何。你也許會(huì)驚異地發(fā)現(xiàn)：沒有任何的出錯(cuò)信息，屏幕上竟然乖乖地出現(xiàn)了這么一行字符串：

This is a test function.

奇怪嗎？不要急，還有更奇怪的呢，你可以把主函數(shù)中加上一句更不可理喻的：

((CTestClass*)NULL)->Function();

這仍然沒有問題！！

我這還有呢，哈哈。現(xiàn)在你在主函數(shù)中這么寫，倘說上一句不可理喻，那么以下可以叫做無法無天了：

int?i?=?888; CTestClass*?p2?=?(CTestClass*)&i; p2->Function();

你看到了什么？是的，“This is a test function.”如約而至，沒有任何的錯(cuò)誤。

你也許要問為什么，但是在我解答你之前，請你在主函數(shù)中加入如下代碼：

printf(?"%d,?%d",?sizeof(?CTestClass?),?sizeof(?int?)?);

這時(shí)你就會(huì)看到真相了：輸出結(jié)果是——得到的兩個(gè)十進(jìn)制數(shù)相等。對，由sizeof得到的CTestClass的大小其實(shí)就是它的成員m_nInteger的大小。亦即是說，對于CTestClass的一個(gè)實(shí)例化的對象（設(shè)為a）而言，只有a.m_nInteger是屬于a這個(gè)對象的，而a.Function()卻是屬于CTestClass這個(gè)類的。所以以上看似危險(xiǎn)的操作其實(shí)都是可行且無誤的。

現(xiàn)在你明白為什么我的“野指針”是安全的了，那么以下我所列出的，就是在什么情況下，我的“野指針”不安全：

1. 在成員函數(shù)Function中對成員變量m_nInteger進(jìn)行操作；
2. 將成員函數(shù)Function聲明為虛函數(shù)（virtual）。

以上的兩種情況，目的就是強(qiáng)迫野指針使用屬于自己的東西導(dǎo)致不安全，比如第一種情況中操作本身的m_nInteger，第二種情況中變?yōu)樘摵瘮?shù)的Function成為了屬于對象的函數(shù)（這一點(diǎn)可以從sizeof看出來）。

其實(shí)，安全的野指針在實(shí)際的程序設(shè)計(jì)中是幾乎毫無用處的。我寫這一篇文章，意圖并不是像孔乙己一樣去琢磨回字有幾種寫法，而是想通過這個(gè)小例子向諸位寫明白C++的對象實(shí)例化本質(zhì)，希望大家不但要明白what和how，更要明白why。李馬二零零三年二月二十日作于自宅。

關(guān)于成員函數(shù)CTestClass::Function的補(bǔ)充說明

這個(gè)函數(shù)是一個(gè)普通的成員函數(shù)，它在編譯器的處理下，會(huì)成為類似如下的代碼：

void?Function(?const?CTestClass?*?this?)?//?① { ????printf("This?is?a?test?function.\n"); }

那么p->Function();一句將被編譯器解釋為：

Function( p );

這就是說，普通的成員函數(shù)必須經(jīng)由一個(gè)對象來調(diào)用（經(jīng)由this指針激活②）。那么由上例的delete之后，p指針將會(huì)指向一個(gè)無效的地址，然而p本身是一個(gè)有效的變量，因此編譯能夠通過。并且在編譯通過之后，由于CTestClass::Function的函數(shù)體內(nèi)并未對這個(gè)傳入的this指針進(jìn)行任何的操作，所以在這里，“野指針”便成了一個(gè)看似安全的東西。

然而若這樣改寫CTestClass::Function：

void?CTestClass::Function(?void?) { ????m_nInteger?=?0; }

那么它將會(huì)被編譯器解釋為：

void?Function(?const?CTestClass?*?this?) { ????this->m_nInteger?=?0; }

你看到了，在p->Function();的時(shí)候，系統(tǒng)將會(huì)嘗試在傳入的這個(gè)無效地址中尋找m_nInteger成員并將其賦值為0，剩下的我不用說了——非法操作出現(xiàn)了。

至于virtual虛函數(shù)，如果在類定義之中將CTestClass聲明為虛函數(shù)：

class?CTestClass { public: ????//?... ????virtual?void?Function(?void?); };

那么C++在構(gòu)建CTestClass類的對象模型時(shí)，將會(huì)為之分配一個(gè)虛函數(shù)表vptr（可以從sizeof看出來）。vptr是一個(gè)指針，它指向一個(gè)函數(shù)指針的數(shù)組，數(shù)組中的成員即是在CTestClass中聲明的所有虛函數(shù)。在調(diào)用虛函數(shù)的時(shí)候，必須經(jīng)由這個(gè)vptr，這也就是為什么虛函數(shù)較之普通成員函數(shù)要消耗一些成本的緣故。以本例而言，p->Function();一句將被編譯器解釋為：

(*p->vptr[1])(?p?);?//?調(diào)用vptr表中索引號為1的函數(shù)（即Function）③

上面的代碼已經(jīng)說明了，如果p指向一個(gè)無效的地址，那么必然會(huì)有非法操作。

備注：

①關(guān)于函數(shù)的命名，我采用了原名而沒有變化。事實(shí)上編譯器為了避免函數(shù)重載造成的重名情況，會(huì)對函數(shù)的名字進(jìn)行處理，使之成為獨(dú)一無二的名稱。
②將成員函數(shù)聲明為static，可以使成員函數(shù)不經(jīng)由this指針便可調(diào)用。
③vptr表中，索引號0為類的type_info。

?????????在進(jìn)行軟件開發(fā)過程中間，有很多小功能的實(shí)現(xiàn)，雖然這些東西你可以不用，但是如果應(yīng)用仂將會(huì)是你的程序更具有專業(yè)性。?
一、設(shè)置程序自動(dòng)運(yùn)行。??
???????很多監(jiān)控軟件要求軟件能夠在系統(tǒng)重新啟動(dòng)后不用用戶去點(diǎn)擊圖標(biāo)啟動(dòng)項(xiàng)目，而是直接能夠啟動(dòng)運(yùn)行，方法是寫注冊表Software\\Microsoft\\Windows\\CurrentVersion\\Run。參考程序可以見下：(查找程序目錄的執(zhí)行文件，存在則進(jìn)行添加注冊表操作)?
???????? HKEY RegKey;?
???????? CString sPath;?
???????? GetModuleFileName(NULL,sPath.GetBufferSetLength(MAX_PATH+1),MAX_PATH);?
???????? sPath.ReleaseBuffer();?
???????? int nPos;?
??? nPos=sPath.ReverseFind(’\\’);?
??? sPath=sPath.Left(nPos);?
??? CString lpszFile=sPath+"\\****.exe";//這里加上你要查找的執(zhí)行文件名稱?
??? CFileFind fFind;?
??? BOOL bSuccess;?
??? bSuccess=fFind.FindFile(lpszFile);?
??? fFind.Close();?
??? if(bSuccess)?
??? {?
??????? CString fullName;?
??????? fullName=lpszFile;?
??????? RegKey=NULL;?
??????? RegOpenKey(HKEY_LOCAL_MACHINE,"Software\\Microsoft\\Windows\\CurrentVersion\\Run",&RegKey);?
??????? RegSetValueEx(RegKey,"*****",0,REG_SZ,(const unsigned char*)(LPCTSTR)fullName,fullName.GetLength());//這里加上你需要在注冊表中注冊的內(nèi)容?
??????? this->UpdateData(FALSE);?
??? }?
??? else?
??? {?
??????? theApp.SetMainSkin();?
??????? ::AfxMessageBox("沒找到執(zhí)行程序，自動(dòng)運(yùn)行失敗");?
??????? exit(0);?
??? }?

二、自動(dòng)配置數(shù)據(jù)源?
??? 很多的程序都要用到數(shù)據(jù)庫結(jié)合的操作，這里舉例ACCESS，因?yàn)锳CCESS在中小型VC系統(tǒng)開發(fā)中是最常用到的，如果程序的移植，如果對于很初級的用戶來說，你還需要他到配置面板中進(jìn)行數(shù)據(jù)源配置的話，那就有點(diǎn)說不過去了。?
???????? #include <odbcinst.h>?
???????? //配置數(shù)據(jù)源，數(shù)據(jù)庫在應(yīng)用程序目錄下,這里比如數(shù)據(jù)庫文件名為***.mdb，程序運(yùn)行時(shí)候可以將數(shù)據(jù)庫文件拷貝到程序目錄下面。?
??? CString sPath;?
??? GetModuleFileName(NULL,sPath.GetBufferSetLength (MAX_PATH+1),MAX_PATH);?
??? sPath.ReleaseBuffer();?
??? int nPos;?
??? nPos=sPath.ReverseFind(’\\’);?
??? sPath=sPath.Left(nPos);?
??? CString lpszFileName = sPath + "\\***.mdb";//這里修改成你的數(shù)據(jù)庫文件名稱?
??? CFileFind? fFind;?
??? if(!fFind.FindFile(lpszFileName))?
??? {?
??????? ::AfxMessageBox("沒有找到數(shù)據(jù)庫");?
??????? exit(0);?
??? }??
??? CString szDesc;?
??? szDesc.Format( "DSN=****;Description=****;DESCRIPTION=The DataBase For ***;FIL=MicrosoftAccess;DEFAULTDIR=%s;DBQ=%s;" ,sPath,lpszFileName);//這里***號可以添加成你的描述?

??? //添加數(shù)據(jù)源?
??? if(!::SQLConfigDataSource(NULL,ODBC_ADD_DSN, "Microsoft Access Driver (*.mdb)",(LPCSTR)szDesc))?
??? {?
??????? ::AfxMessageBox("32位ODBC數(shù)據(jù)源配置錯(cuò)誤!");?
??????? exit(0);?
??? }?

三、設(shè)置顯示模式：?
??? 很多的程序的移植的運(yùn)行環(huán)境是改變的。有可能你的原來開發(fā)環(huán)境是1024X768，但是到了那些顯示器大于17的時(shí)候（分辨率超過你的開發(fā)時(shí)的分辨率時(shí)），程序的顯示可能就不好看了。?
???????? DEVMODE lpDevMode;?
??? lpDevMode.dmPelsHeight=768;//Y方向象素點(diǎn)?
??? lpDevMode.dmPelsWidth=1024;//X方向象素點(diǎn)?
??? lpDevMode.dmDisplayFrequency=85;//屏幕刷新率?
??? lpDevMode.dmFields=DM_PELSWIDTH|DM_PELSHEIGHT|DM_DISPLAYFREQUENCY;?
??? ChangeDisplaySettings(&lpDevMode,0);?

四、在你的程序中間加載其他應(yīng)用程序：?
??? 你的程序除了調(diào)用到各個(gè)模塊進(jìn)行協(xié)同工作外（DLL），還有可能調(diào)用不是同一個(gè)開發(fā)環(huán)境下的應(yīng)用程序，比如VC環(huán)境下調(diào)用DELPHI，VB開發(fā)的執(zhí)行程序，你就可以用到下面的方法（將調(diào)用的應(yīng)用程序拷貝程序目錄中）：?
???????? CString sPath;?
??? GetModuleFileName(NULL,sPath.GetBufferSetLength (MAX_PATH+1),MAX_PATH);?
??? sPath.ReleaseBuffer();?
??? int nPos;?
??? nPos=sPath.ReverseFind(’\\’);?
??? sPath=sPath.Left(nPos);?
??? CString lpszFileName = sPath + "\\***.exe";//這里修改成你的調(diào)用應(yīng)用程序的文件名稱?
??? CFileFind? fFind;?
??? if(!fFind.FindFile(lpszFileName))?
??? {?
??????? ::AfxMessageBox("沒有找到調(diào)用的應(yīng)用程序！");??
??????? return FALSE;?
??? }?
??? else?
??????? ShellExecute(NULL,NULL,_T("***.exe"),NULL,sPath,NULL);??

五、結(jié)束進(jìn)程：?
??? 在你的程序中結(jié)束別的程序進(jìn)程，采用的方法是進(jìn)行進(jìn)程列舉，然后采用查找的方法進(jìn)行：?
???????? #include "TLHELP32.H"?
???????? DWORD ProcessID[50];?
??? CString kkk[50];?
??? HANDLE SnapShot=CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS,0);??
??? PROCESSENTRY32* info=new PROCESSENTRY32;?
??? PROCESSENTRY32 ProcessInfo;//聲明進(jìn)程信息變量?
??? ProcessInfo.dwSize=sizeof(ProcessInfo);//設(shè)置ProcessInfo的大小?
??? //返回系統(tǒng)中第一個(gè)進(jìn)程的信息?
??? BOOL Status=Process32First(SnapShot,&ProcessInfo);?
??? int m_nProcess=0;??
??? while(Status)?
??? {?
??????? CString s,str1,str2;?
??????? s.Format("%d",ProcessInfo.cntThreads);?
??????? str1.Format("%s",ProcessInfo.szExeFile);?
??????? str1=ProcessInfo.szExeFile;?
??????? kkk[m_nProcess]=ProcessInfo.szExeFile;??
??????? ProcessID[m_nProcess]=ProcessInfo.th32ProcessID;??
??????? if(str1=="***.exe")//***.exe就是你要結(jié)束的進(jìn)程的名稱?
??????? {?
??????????? HANDLE ProcessHandle;?
??????????? ProcessHandle=OpenProcess (PROCESS_ALL_ACCESS,FALSE,ProcessID[m_nProcess]);?
??????????? TerminateProcess(ProcessHandle,0);?????
??????? }?
??????? Status=Process32Next(SnapShot,&ProcessInfo);?
??????? m_nProcess++;?
??? }?

???作為現(xiàn)代C++最重要的特色技術(shù)，template正在各個(gè)傳統(tǒng)領(lǐng)域攻城略地。從基本算法與數(shù)據(jù)結(jié)構(gòu)，到正則表達(dá)式與XML解析，從高性能數(shù)學(xué)計(jì)算，到資源的分配與管理，從網(wǎng)絡(luò)分布式計(jì)算環(huán)境，到組件模型創(chuàng)建，從靜態(tài)多態(tài)性的維度擴(kuò)展，到設(shè)計(jì)模式的自動(dòng)生成，神奇的template顯示出其令人嘆為觀止的強(qiáng)勁實(shí)力，如果不是有一個(gè)隱隱的痛處，template愛好者簡直可以去狂歡了。

這個(gè)隱隱的痛處，就是在GUI編程領(lǐng)域。

???現(xiàn)有的大部分成熟GUI框架和工具庫，其定型時(shí)間都在90年代早期，不管是因?yàn)槭裁丛颍傊覀兏究床坏絫emplate技術(shù)在這些環(huán)境中的任何重要運(yùn)用。無論是專有MFC和OWL，還是開源的wxWindow和Mozilla, 以至于是專有還是開源都說不清楚的Qt，它們在其他方面有著諸多不同，偏偏倒是在對待模板技術(shù)上空前一致：嚴(yán)格限制在底層的數(shù)據(jù)結(jié)構(gòu)領(lǐng)域內(nèi)，抵制模板技術(shù)流入GUI主體結(jié)構(gòu)。最過分的wxWindow和Mozilla，在代碼編寫規(guī)范里嚴(yán)厲禁止使用1990年之后發(fā)展出來的任何C++特性，模板、異常、多繼承、STL等等，均在黑名單上。諸位有興趣，不妨去看看，那與其說是一份C++代碼編寫規(guī)范，倒不如說是對C++現(xiàn)代特性在GUI領(lǐng)域應(yīng)用的一份不公正的判決書。

難道模板技術(shù)真的在GUI領(lǐng)域無用武之地嗎？

WTL給出了一個(gè)響亮的回答。

???WTL是微軟ATL開發(fā)組成員Nenad Stefanovic先生在ATL Windowing機(jī)制上發(fā)展起來的一整套GUI框架，運(yùn)用template技術(shù)組織和創(chuàng)建GUI對象，構(gòu)筑了精致的面向?qū)ο罂蚣埽]錯(cuò)，在這里object oriented與template達(dá)成了精致的融合）。雖然沒有獲得微軟的官方支持，雖然其使用者人數(shù)很少，但是確實(shí)是“用過的都說好”，有位微軟MVP人士甚至說，這是微軟有史以來推出的最優(yōu)秀的一個(gè)framework。真是一個(gè)有趣的諷刺，最好的東西居然不被官方支持。有關(guān)于WTL的流言不少，比如這東西原本是微軟內(nèi)部專用，只是因?yàn)椴恍⌒牟疟恍孤┏鰜淼鹊龋@更加劇它的神秘色彩。相信大家對它一定有不少問題。我們特別邀請到了WTL之父Nenad Stefanovic先生，進(jìn)行了一次網(wǎng)上的訪談，希望能幫助大家了解WTL的真面目。

【C++ View】：I think most of our readers are not very familiar with you, so would you please tell us your story here? We are very fond of that. What do you think about China and Chinese people?

【C++ View】：我想，可能我們的讀者中有很多人對您還不是很熟悉，您能不能在此給我們簡單介紹一下您自己呢？我們將非常樂意聽到您的自述。還有，您能不能也對我們講述一下您對于中國以及中國人民的基本看法呢？

【Nenad】: I am a software developer at Microsoft. Your readers will probably know me as a creator of Windows Template Library, WTL. I am from former Yugoslavia, where I finished school and started working on software development. I've been living in US for 10 years now.

I am intrigued and impressed by the Chinese culture and tradition. I think that China is now in a great position of progress as a country and a nation. I discovered that, being from former Yugoslavia, I already know many things about China, and getting to know people from China gave me a bit of the "everyday" life perspective as well. I'd like to learn more, so I hope to visit China one day.

【Nenad】：好的。我現(xiàn)在在Microsoft工作，是它里面的一個(gè)軟件開發(fā)人員。你們雜志的讀者中可能有人知道，我就是Windows Template Library （WTL）的創(chuàng)作者。我來自于前南斯拉夫，在那我完成了我的學(xué)業(yè)并開始了我作為軟件開發(fā)人員的工作生涯。現(xiàn)在，我在美國居住的時(shí)間已經(jīng)超過了10年了。

???中國的文化以及傳統(tǒng)給我留下了極為深刻的印象，我對此十分感興趣。我想，作為一個(gè)國家以及民族，中國已經(jīng)處于一個(gè)偉大并且不斷在成長中的位置上。作為一個(gè)從前南斯拉夫來的人，我早就了解到關(guān)于中國的很多事情。在與來自中國的人民的接觸過程中，我還了解到了你們?nèi)粘Ｉ畹囊恍顩r。我還想了解更多（有關(guān)中國的事情），希望有一天我可以到中國來游覽。

【C++ View】：When and why did you first think about WTL? What's its original purpose? How do you see its future?

【C++ View】：您是什么時(shí)候開始想起要開發(fā)WTL呢？為什么？您在開發(fā)它時(shí)的最初目的是什么？您又是如何地看待它未來的發(fā)展呢？

【Nenad】：WTL was born while I was working on ATL (Active Template Library). We were extending ATL to support ActiveX controls, and I was working on the windowing support. I started thinking that the same techniques can be applied to much broader windowing support, for the much richer UI for controls, components, and also applications. So, WTL was created as a part of ATL that would extend ATL to support any kind of UI related component or application. It did not ship with ATL in Visual Studio, however, so I decided to ship it as a standalone library that extends ATL.

I think that WTL will continue to be a great option for developers writing Windows applications and components. I don't see big changes or additions to WTL, because one of the design principles for WTL was to follow the Win32 UI API and design. It will continue to do so.

【Nenad】：WTL是我在從事ATL （Active Template Library）開發(fā)工作時(shí)的產(chǎn)物。那時(shí)我們正在擴(kuò)展ATL，使之得以支持ActiveX control，而我負(fù)責(zé)的就是其中對于窗口機(jī)制部分的支持。這時(shí)，我就開始想，是不是可以把同樣的技術(shù)應(yīng)用到更為廣泛的窗口機(jī)制中，以獲得更豐富的UI控制、組件、以至于應(yīng)用程序呢？于是，作為ATL的一部分，WTL被開發(fā)出來了。它將ATL進(jìn)行了擴(kuò)展，以使得它可以支持各種類型的與UI相關(guān)的組件或者應(yīng)用程序。然而，它并沒有隨著ATL一同集成在Visual Studio中被發(fā)布，于是我就決定將它作為一個(gè)單獨(dú)的ATL擴(kuò)展庫發(fā)布出去。

我認(rèn)為WTL將一直是那些在Windows下開發(fā)應(yīng)用程序以及組件的開發(fā)者的一個(gè)很好的選擇。我并不認(rèn)為在以后，我們會(huì)對WTL有一個(gè)大的改動(dòng)（或者增添），因?yàn)閃TL的一個(gè)設(shè)計(jì)宗旨就是“遵循Win32 UI的API及其設(shè)計(jì)”。現(xiàn)在如此，將來還是會(huì)如此下去。

【C++ View】：I first heard about WTL in July, 2000. At that time, I thought: "No official support, no documentation, no commercial hype, it will die in 6 months." Now, fifteen months passed, it spreads wider and be more vigorous. Lots of C++ programmers, esp. the ones we regard them as "gurus and masters" involved in WTL. I know it's surely because WTL is a wonderful library, but it must be more than a wonderful library to gain such attentions without official force.What do you think WTL's relative success? What's the reason?

【C++ View】：我第一次接觸WTL是在2000年7月。在那時(shí)，我就想：“沒有官方的支持，沒有文檔，也沒有商業(yè)吹捧，它最多只能夠存活6個(gè)月。”但現(xiàn)在15個(gè)月過去了，它反而流傳得更為廣泛，更加的生機(jī)勃勃。許多C++程序員，尤其是一些我們所認(rèn)知的“專家”以及“大師”，都在使用WTL。我當(dāng)然知道這主要是因?yàn)閃TL的出色，但我想，能夠在沒有官方的力量牽涉的情況下吸引如此多的注意，WTL一定還有更出色的東西，請問您是如何看待WTL的成功呢？它成功的原因又是什么？

【Nenad】： I think that the main reason of WTL's success is that it did fit the need of developers at the right time. More and more developers started using ATL, and it was natural for them to start using WTL when they needed more UI support. It seems that WTL was perceived as a more open project than others, judging by the support provided by other parties in the development community. Many people did a wonderful job of creating samples, documentation and support for WTL. The support from the programming community is very important part of the acceptance and success of WTL.

【Nenad】：我認(rèn)為WTL成功的最主要原因就是，它確實(shí)而且及時(shí)地滿足了開發(fā)者的需求。越來越多的開發(fā)人員開始使用ATL，當(dāng)他們需要更多的UI支持時(shí)，他們很自然的就會(huì)開始使用WTL。 從其他的開發(fā)團(tuán)隊(duì)所提供支持來看，WTL看起來似乎要比其他的項(xiàng)目更加開放。許許多多人為WTL做了大量工作，如：創(chuàng)建示例代碼，撰寫文檔等。WTL之所以能夠被廣為接受并獲得如此大的成功，來自于這些開發(fā)團(tuán)隊(duì)的支持絕對是一個(gè)重要的因素。

【C++ View】：What do you think about MFC? Do you like it? If you don't, why? And the most confusing thing is Managed C++, is it C++? Do the leaders of MC++ really think some C++ users will go to learn it? Do you believe?

【C++ View】：請問您對于MFC是怎么看的？您喜歡它嗎？如果不，為什么呢？還有，最讓人迷惑不解的就是Managed C++了，它是不是C++呢？MC++的提倡者是不是真的認(rèn)為會(huì)有一些C++的用戶轉(zhuǎn)而去學(xué)習(xí)它呢？您的看法又是如何呢？

【Nenad】： I think that MFC is a great framework library. Don't forget that MFC was designed at the time that C++ compiler was rather limited, and the main platform was 16-bit Windows. Unfortunately, because MFC was designed as a framework, it was really hard to evolve it to use better C++ support in newer compilers, and to add support for new features added to Windows in the meantime. What I don't like about MFC is the DLL approach, which causes many compatibility problems, and framework design, which dictates too many things about app design.

Managed C++ is an extension to C++ which allows C++ programs to use managed code. It is very important to understand that you can compile your existing C++ code using MC++ without any changes. MC++ allows developers to use both familiar non-managed C++ and managed code in the same module. That provides an excellent way to extend existing code to interact with managed code, as well to create new projects that can use both managed and traditional C++.

【Nenad】：我認(rèn)為MFC是一個(gè)了不起的框架庫。請不要忘了，在MFC被設(shè)計(jì)出來初期，那時(shí)的C++編譯器還具有很多的限制，并且那時(shí)主要的平臺還只是16位的Windows。不幸的是，由于MFC被設(shè)計(jì)成為一個(gè)框架，使得我們很難利用新編譯器中那些更好的C++特性來改進(jìn)它，也很難將Windows中的很多新特性添加到MFC中。我不喜歡MFC的地方是它高度依賴DLL的特性——因?yàn)樗鼘?dǎo)致許多兼容性方面的問題；還有就是MFC的整個(gè)框架設(shè)計(jì)——它在應(yīng)用程序的設(shè)計(jì)中限定了太多東西。

Managed C++是C++的一個(gè)擴(kuò)展，它允許C++程序得以使用受管（managed）代碼。我們需要了解的一個(gè)很重要的特性就是，我們可以使用MC++來編譯已有的C++代碼而無需對它們進(jìn)行任何改動(dòng)。MC++允許開發(fā)者同時(shí)使用他們所熟悉的非受管代碼以及受管代碼來開發(fā)同一個(gè)模塊。這就提供了一個(gè)非常好的途徑，使已有的代碼與新的受管代碼相互作用，并也可使得我們創(chuàng)建一個(gè)項(xiàng)目，同時(shí)使用受管的和傳統(tǒng)的C++代碼。

【C++ View】：In the past 15 years or more, C and C++ is the base of almost all Microsoft's technologies(OS, COM, etc.). We C++ user paid a lot of hard work to catch them, because we felt what we paid was worthy(?). Now, it seems the climate changed. .NET is coming, the world is going to be full of CLRs and/or JVMs. There has been a decampment from C++. So what do you think about the future of C++ (not MC++) in Mircosoft technologies? Will it go away? Will it become a marginal language?

【C++ View】：在過去的15年中（甚至更長的一段時(shí)間內(nèi)），C以及C++構(gòu)成了幾乎所有Microsoft技術(shù)的基礎(chǔ)（如：OS，COM等）。我們這些C++用戶花費(fèi)了大量的時(shí)間來熟悉并掌握它們（C以及C++），因?yàn)槲覀兿嘈盼覀兯冻龅囊欢〞?huì)有回報(bào)（?）。但現(xiàn)在的風(fēng)向好像有了很大的改變。.NET出現(xiàn)了，世界似乎就要充斥CLR （Common Language Runtime，公共語言運(yùn)行庫）以及／或JVM （Java Virtual Machine，Java虛擬機(jī)）。現(xiàn)在C++已經(jīng)出現(xiàn)了退潮的跡象。那么，請問您對于C++（不是MC++）在Microsoft技術(shù)中的前景如何看待？它是否會(huì)由此消亡？還是就此淪落為一門邊緣語言？

【Nenad】：Well, the world is changing too. The new type of development for Web services and connected applications is on the horizon. I think that new languages, like Java, C#, and VB.NET, were developed to address two main issues - to simplify software development and to provide better support for Internet development. Simplifying software development allows more developers to write good applications and cuts down on time needed to finish a project. Supporting Internet development is obviously very important in this time when Internet is used more and more in every part of everyday life.

I think that C++ will continue to be an important language, especially for ISV's and for system development. On the other hand, I believe that .NET will be very important platform soon. .NET has the potential to be the main programming platform for the future, but it is reasonable to expect that the transition will take some time.

【Nenad】：是的，世界也已經(jīng)發(fā)生了變化。對于網(wǎng)絡(luò)服務(wù)以及連接這樣的新型應(yīng)用程序的開發(fā)已經(jīng)浮上了水面。我認(rèn)為那些新的編程語言（如Java，C#，以及VB.NET）都是針對以下兩個(gè)主要的問題而開發(fā)出來的——簡化軟件的開發(fā)過程以及對于Internet應(yīng)用程序開發(fā)提供更好的的支持。簡化軟件的開發(fā)過程使得更多的開發(fā)者可以寫出更多更好的應(yīng)用程序并減少完成開發(fā)項(xiàng)目所需要的時(shí)間。而支持Internet的開發(fā)，對于這個(gè)Internet越來越深入到我們的日常生活中的時(shí)代來說，毫無疑問是一件非常重要的事情。

我認(rèn)為C++會(huì)繼續(xù)作為一門重要的編程語言發(fā)揮作用，尤其是對那些獨(dú)立軟件開發(fā)商和那些系統(tǒng)級開發(fā)來說更是如此。從另一方面來說，我相信.NET將會(huì)在不久以后成為另外一個(gè)非常重要的開發(fā)平臺。對于未來來說，.NET擁有成為主流編程平臺的潛力，但我們必須認(rèn)識到，這樣的過渡階段肯定要持續(xù)一段時(shí)間。

【C++ View】：There a lots of beginners in our readers, after they learn (standard) C++, they want to seek a path to master enought Microsoft technologies to be practical and proficient programmers. Could you recommend such a path? Should they learn Win32 API programming? Is it worthy of studying MFC? Is WTL/ATL/STL a reliable solution? Or goto C# directly? Many many people will thank you if you give them frank advice.

【C++ View】：我們的讀者中有很多是初學(xué)者，在他們學(xué)習(xí)完（標(biāo)準(zhǔn)）C++后，他們希望能夠找到一條道路，掌握到足夠多的Microsoft的技術(shù)使自己成為經(jīng)驗(yàn)豐富的、熟練的程序員。您能不能給我們指出這樣的一條道路來呢？我們是不是應(yīng)該學(xué)習(xí)Win32 API編程？學(xué)習(xí)MFC是否是值得的？WTL/ATL/STL算得上是一個(gè)可靠的解決方案嗎？又或是我們應(yīng)該直接學(xué)習(xí)C#？如果您能夠給我們一些建議，相信會(huì)有很多的人為此而感激您的。

【Nenad】：I think that depends on their plans and ambitions. The more of those things you do, the better you are off in the long run. But, you also have to balance that with the practical issues. So, I think that people who see their future in the Internet development can go directly to C# or VB.NET, and study .NET platform. Those who would like to have more knowledge of the Windows platform and services it provides should certainly learn more about Win32 API and libraries that support Windows programming.

【Nenad】：我認(rèn)為這主要取決于他們的計(jì)劃以及雄心。你所做的越多，在長時(shí)間競爭中你就越占據(jù)優(yōu)勢。不過你也要注意保持與實(shí)際問題的平衡。我建議那些決心以后只做Internet相關(guān)開發(fā)的人可以直接去學(xué)習(xí)C#或者VB.NET，同時(shí)學(xué)習(xí).NET平臺。而那些更多地了解Windows平臺以及它所提供的服務(wù)方面知識的人，當(dāng)然就必須需要更多地了解有關(guān)Win32 API以及那些支持Windows編程的庫相關(guān)的知識。

【C++ View】：Soon after I began to learn WTL, a warm-hearted man posted me a email. He wrote: "You won't be a good WTL programmer if not a good ATL programmer, you won't be a good ATL programmer if not a COM programmer. And once you decide to learn COM, you are beginning your travel to hell." Is COM so difficult to learn? How to study WTL? We must learn API, COM, ATL and WTL in sequence, do we? And what about COM, will it remain to be the core technology of Microsoft, or just be substituted by .NET and dismiss?

【C++ View】：在我剛開始學(xué)習(xí)WTL后不久，有一位熱心人給我發(fā)了份郵件。他寫道：“如果你不是一個(gè)好的ATL程序員的話，你就不可能成為一個(gè)好的WTL程序員；如果你不會(huì)COM編程的話，你就不可能成為一個(gè)好的ATL程序員；但一旦你決定開始學(xué)習(xí)COM，你就邁出了踏向地獄的第一步。”COM是不是真的那么難學(xué)？我們應(yīng)該如何地來學(xué)習(xí)WTL呢？我們是不是應(yīng)該按照這樣的順序?qū)W下來呢，API->COM->ATL->WTL？還有，COM將會(huì)變得如何？他是不是還能夠保持Microsoft的核心技術(shù)這一頭銜，抑或是被.NET給替換掉然后就此消失？

【Nenad】：I don't think it is necessary to master COM to use and understand WTL. Win32 UI knowledge is more important than COM to understand WTL. But it is true that knowledge of ATL is required, and ATL mainly supports COM. So, COM knowledge is desirable, but not required.

I don't think that COM is hell, but it sure does require a lot to learn to be an expert. Keep in mind that many people don't have to be COM experts to use COM, or to use WTL. Just understanding basic principles of COM is enough to use it, and then people can learn more when needed.

【Nenad】：我不認(rèn)為使用和理解WTL就一定要掌握COM。相比于COM來說，Win32 UI的知識對于理解WTL顯得更為重要。但毫無疑問的是，ATL的相關(guān)知識是必不可少的。由于ATL主要任務(wù)就是支持COM，所以，有COM的知識只是會(huì)更好一些而已，但它們并不是必需的。

我也不認(rèn)為COM是一個(gè)噩夢，但毫無疑問的是，想要成為一個(gè)COM專家，要學(xué)的東西實(shí)在是太多了。但請記住一件事情，很多使用COM或者WTL的人并不都是COM方面的專家。要想使用它們，人們所需了解的只是一些COM的基本原理就夠了，其他的相關(guān)的知識則可以在需要時(shí)再去學(xué)習(xí)。

【C++ View】：What do you think about Generic Programming? Is it a whole different paradigm from OOP, or just OOP's supplemental facility? Can we combine GP and OOP? In the hard work of design and implement WTL, you must had got an insight about the relationship between OOP and GP, what's it?

【C++ View】：請問您對于泛型程序設(shè)計(jì)是如何看待的？它到底是OOP的一個(gè)補(bǔ)充呢，還是完全不同于OOP的另外一個(gè)程序設(shè)計(jì)范型呢？我們是否可以將GP以及OOP一同聯(lián)合使用？我想，在設(shè)計(jì)和實(shí)作出WTL的艱苦過程中，對于OOP以及GP之間的關(guān)系，您一定有了自己的看法，您能不能給我們說一下呢？

【Nenad】：Generic Programming and OOP are very different, mostly because Generic Programming doesn't explicitly express relationships between design elements. They can, however, be used together very efficiently.

WTL uses a combination of Generic Programming and OOP design. Templates are mostly used to implement traditional OOP classes. I'd like to point out that WTL doesn't use any "pure" design, and it doesn't strictly follow any design guidelines or styles. I do think, though, that WTL does use one of the main strengths of the C++ language - it uses appropriate paradigm that is the most suitable for a particular problem.

【Nenad】：GP和OOP非常不同，這主要是由于GP從不顯式地表達(dá)出設(shè)計(jì)元素之間的關(guān)聯(lián)來。然而，它們也可以被非常高效地組合運(yùn)用。

WTL中使用了一種GP連同OOP的設(shè)計(jì)。我在其中大量使用了模板來實(shí)作出傳統(tǒng)的OOP中的類。我很樂意指出的是，WTL中并沒有使用一種“純”設(shè)計(jì)，它也沒有遵循任何的設(shè)計(jì)指導(dǎo)方針或者設(shè)計(jì)規(guī)格。可是，我還是認(rèn)為WTL使用到了C++語言中的最主要的精髓處——對于一個(gè)特定的問題使用一種最適合它的適當(dāng)?shù)浞丁?

【C++ View】：Recently, the famous C++ pioneer Stanley Lippman joined Microsoft and became a member of Visual C++.NET group. How do you think about this? What message do you think your company like to pass to public? Does this mean Microsoft want to make VC.NET a full-standardized C++ compiler and hold C++ as your core system language?

【C++ View】：最近，著名的C++元老級大師Stanley Lippman加入了Microsoft并成為其VC.NET開發(fā)小組中的一員。請問您對于此事是如何看待的？您認(rèn)為Microsoft試圖向公眾傳播一種什么樣的信息呢？這是否也意味著Microsoft希望VC.NET成為一個(gè)完全標(biāo)準(zhǔn)化的C++編譯器，并繼續(xù)保持C++的核心系統(tǒng)語言地位呢？

【Nenad】：I think that shows that Microsoft is committed to advance the C++ compiler and language, and ready to get the best people to help. I am sure that VC++.NET will continue to be powerful tool for developing applications, and that it will also include additional capabilities for the .NET development. Compliance with the C++ Standard is an ongoing work, and we will see further improvements there, too.

【Nenad】：我認(rèn)為這顯示了Microsoft對于促進(jìn)C++編譯器以及語言繼續(xù)發(fā)展的決心，并為此找到了最佳人選來獲取幫助。我確信VC.NET將會(huì)繼續(xù)是開發(fā)應(yīng)用程序的強(qiáng)有力工具，并且它同時(shí)還將包含有.NET開發(fā)能力。目前我們正在進(jìn)行兼容C++標(biāo)準(zhǔn)方面的工作，不久我們就會(huì)看到成效。

【C++ View】：I'm learning WTL and ATL, since you are the author of WTL and a member of ATL group, can you give me some advice?

【C++ View】：我現(xiàn)在正在學(xué)習(xí)WTL以及ATL，既然您是WTL的作者，同時(shí)又是ATL開發(fā)小組中的一員，您能不能給我一些建議呢？

【Nenad】：There are several areas of programming that are very important for WTL and ATL: knowledge of the C++ language in general, understanding of templates, COM for ATL, and Windows UI programming for WTL. Solid knowledge in these areas is very beneficial for WTL and ATL developers, and it also helps to understand the source code for both libraries.

I would also like to encourage everybody to write programs. That is the best way to learn how to use any library, or a programming language or operating system. Writing programs often brings problems that must be solved that are not addressed in books. Reading about something is very useful to start learning, writing programs is the best next step.

【Nenad】：對于WTL和ATL來說，有好幾個(gè)編程方面的領(lǐng)域是十分重要的：大體上的C++語言知識，了解模板，COM（對ATL而言），以及Windows UI編程（對WTL而言）。在這些領(lǐng)域有著堅(jiān)實(shí)的基礎(chǔ)對于WTL以及ATL開發(fā)人員來說有著很大的好處，同時(shí)對于理解這兩個(gè)的源代碼也能夠起到幫助作用。

我同樣也很樂意去鼓勵(lì)大家多寫程序。這也是學(xué)習(xí)如何使用一個(gè)程序庫，或者一門編程語言，或者一個(gè)操作系統(tǒng)的一個(gè)最好的方法。在寫程序的過程中經(jīng)常會(huì)出現(xiàn)一些書本上沒有提及但又必須被解決的問題。在開始學(xué)習(xí)時(shí)讀一些東西是很有用的，而寫程序則是向縱深發(fā)展的最佳方式。

【C++ View】：They say we are in the gate of Post-PC times, it will be a embedded world, and there will be embedded smart device everywhere, and the embedded industry will build a far large market compare to PC's. Do you believe it? Do you think WTL and other C++ template libraries are available and appropriate for embedded development? Are there available for Internet development?

【C++ View】：有人說，我們現(xiàn)在已經(jīng)處于后PC時(shí)代的門口，未來將會(huì)是一個(gè)嵌入系統(tǒng)的世界，嵌入式的智能設(shè)備將會(huì)無所不在，并且對比PC來說，嵌入系統(tǒng)的產(chǎn)業(yè)將會(huì)是一個(gè)更大的市場。您是否相信這些呢？您是否認(rèn)為WTL以及其他的一些C++模板庫對于嵌入式開發(fā)也適用呢？它們是否適合Internet開發(fā)？

【Nenad】：Yes, I think that large number of various devices that we use everyday will become small, specialized computers. That doesn't mean that the number and importance of PCs will go down, just that there are many other devices that will be enhanced to be programmable and connected. Those new devices will provide a great opportunity for software developers, because they will all have software and somebody has to write it.

Many of the C++ libraries are quite appropriate for embedded development, and WTL would also be in cases where Windows based user interface is important (for example, Pocket PC platform). Great flexibility and small footprint are always very important features for embedded development, so template libraries are in the very good position there.

【Nenad】：是的，我認(rèn)為我們現(xiàn)今所使用的各種設(shè)備中的大部分在以后都將會(huì)演變成為一些小的，具有專門用途的計(jì)算機(jī)。但這并不意味著PC的數(shù)目以及重要性將會(huì)由此降低，只不過是表明還有著許多其他的設(shè)備需要被加強(qiáng)以使得我們可以對其進(jìn)行編程并且連接。由于必須需要有軟件的支持，而軟件又需要有人來寫，這些新的設(shè)備將會(huì)給軟件開發(fā)人員帶來極大的機(jī)遇。

有許多的C++函數(shù)庫都可用于嵌入系統(tǒng)的開發(fā)，WTL也將會(huì)在那些Windows用戶界面較為重要的開發(fā)中（例如，在Pocket PC平臺上面開發(fā)）占有一席之地。對于嵌入式開發(fā)來說，良好的彈性，微小的內(nèi)存耗用永遠(yuǎn)都會(huì)是很重要的特性，而模板庫在這方面占據(jù)了一個(gè)非常好的地位。

【C++ View】：In the past 7 years or more, COM is Microsoft's core technology. And we now can see that in the next decade, the core role may be .NET. My question is, what's wrong with COM? Where will COM be? Will it disappear? Will it be substituted by something else? What's the relationship between COM and .NET? Is .NET based on COM? Is it worthy of learning COM now?

【C++ View】：在過去的7年（甚至更長的一段時(shí)間）內(nèi)，COM都是Microsoft中的核心技術(shù)。現(xiàn)在我們可以預(yù)見到，在下一個(gè)十年間，這個(gè)核心將會(huì)變?yōu)?NET。我的問題就是，COM有什么過錯(cuò)？COM將何去何從？它是否會(huì)逐漸消失呢，還是會(huì)被其他的一些技術(shù)給替代？COM和.NET之間的關(guān)系是什么樣的情況？.NET是否是基于COM之上呢？現(xiàn)在學(xué)習(xí)COM是不是還值得？

【Nenad】：Maybe you shouldn't ask what is wrong with COM, but just think of .NET as the evolution of COM. .NET extends what was started with COM- creating reusable binary components - and brings additional important features: rich metadata, great run-time, built-in security, versioning, etc. All of these new features are important for development today, and it is really great that .NET has extensive support for them. Interoperability between .NET and COM is also provided, so that the previously developed COM components can still be used in the .NET environment.

I still think that it is a good idea to learn COM - it is a great first step even for people who want to learn .NET, and it also provides better understanding of the design and implementation of .NET itself.

【Nenad】：或許你不應(yīng)該問COM有什么過錯(cuò)，而是應(yīng)該把.NET看成COM的進(jìn)化。.NET擴(kuò)展了COM最初的目的——?jiǎng)?chuàng)建可重用的二進(jìn)制程序組件——并向其中添加了很多重要的特性：豐富的元數(shù)據(jù)，了不起的運(yùn)行庫，內(nèi)建的安全機(jī)制，版本機(jī)制等。對于現(xiàn)今的軟件開發(fā)來說，所有的這些新的特性都非常重要，所以.NET能夠廣泛地支持它們，是一件很偉大的產(chǎn)品。Microsoft同時(shí)也提供了在.NET和COM之間進(jìn)行互操作的能力，這使得以前所開發(fā)出來的COM組件在.NET環(huán)境中同樣也能夠得到使用。

我仍然認(rèn)為學(xué)習(xí)COM是一個(gè)很好的主意——它甚至對于那些希望學(xué)習(xí).NET的人們來說也是一個(gè)很好的開端，學(xué)習(xí)COM同時(shí)也有助于我們更深入地理解 .NET本身的設(shè)計(jì)和實(shí)現(xiàn)。

【C++ View】：I know you must be a C++ fan. Now the language is facing lots of challenges. To counterattack, Dr. Stroustrup suggest to develop many useful libraries, and teach the programmers to use C++ as a high level language. Now there are several wonderful modern C++ libraries. Aside of ATL, WTL and STL, there are still Boost library, MTL, ACE/TAO, DTL, etc. It seems the C++ community is preparing a movement. Do you think the movement will success? Why? What are your colleagues'(in Microsoft VC.NET group) attitude towards such a movement?

【C++ View】：我猜想您肯定是一個(gè)C++愛好者。現(xiàn)在這門語言面對著許多的挑戰(zhàn)。作為反擊措施，Stroustrup博士提議開發(fā)許多有用的庫，并引導(dǎo)C++程序員把C++當(dāng)作一門高級語言來使用。現(xiàn)在我們已經(jīng)可以得到好幾個(gè)極好的現(xiàn)代的C++庫，除去ATL、WTL以及STL之外，還有Boost庫、MTL、ACE/TAO、DTL等。一切都顯示著C++社區(qū)正在醞釀著一次變革。請問您覺得這場變革能否成功？為什么？您的那些Microsoft中的VC.NET開發(fā)小組中的同事對于此態(tài)度是怎樣的？

【Nenad】：C++ is a great language and its importance remains high, even with the new challenges. Libraries are an excellent addition to the language itself, as they provide very useful reusable code for developers. The existence of many great C++ libraries shows the size and strength of the C++ community. I think that is already a success, and that it will continue. You can be sure that the VC++.NET group is aware of the existing libraries, and I expect them to continue to enhance the support for them.

【Nenad】：C++是一門偉大的語言，即便遇到了新的挑戰(zhàn)，它仍然將是非常重要的。程序庫對于語言本身是極好的補(bǔ)充，它們?yōu)殚_發(fā)者提供了一些十分有用的可重用代碼。存在如此眾多的、了不起C++程序庫，這件事情本身就表明了C++社區(qū)的龐大和強(qiáng)大。我認(rèn)為這場變革已經(jīng)成功了，并且會(huì)一直成功下去。你們可以放心，VC.NET開發(fā)組是不會(huì)對這些已有的程序庫熟視無睹的，我預(yù)期他們會(huì)不斷地加強(qiáng)對于這些庫的支持。

【C++ View】：The last question. Since lots of people don’t acquaint themselves with WTL, now we have a chance for you, the father of WTL, to introduce WTL in a short speech here. What would you like to speak?

【C++ View】：最后一個(gè)問題。既然許多人并不了解WTL，作為WTL之父，您現(xiàn)在有機(jī)會(huì)在這里做一個(gè)演講，請簡短地介紹一下WTL。

【Nenad】：WTL is a template based library for user interface development. It extends ATL to provide classes for implementing user interface for applications, components, and controls. It provides classes for various user interface elements: top-level windows, MDI, standard and common controls, common dialogs, property sheets and pages, GDI objects, UI updating, scrollable windows, splitter windows, command bars, etc.

WTL is implemented using the same template architecture as ATL, so it is a natural fit for ATL developers. It also doesn't alter or hide Windows specific constructs, thus allowing Windows programmers to use WTL without surprises. The important design goal of WTL was to avoid inter-dependencies - classes themselves do not reference other WTL classes. That means that your program will contain just the code that you actually use, and nothing else. Coupled with the use of templates, this allows creation of very small programs without run-time dependencies.

WTL delivers the object oriented way to program for the Windows user interface, while keeping the code size small. It also provides a great foundation that developers can extend with their own classes.

And finally - WTL was written with a hope that developers will enjoy using it. I hope you will use it and enjoy it, too.

WTL是一個(gè)基于模板的、專為開發(fā)用戶界面的程序庫。它擴(kuò)展了ATL，并提供了一些類用來實(shí)現(xiàn)應(yīng)用程序的用戶界面、組件和控件。它提供了各種類來支持各種各樣的用戶界面元素：頂級窗口、MDI、標(biāo)準(zhǔn)控件和通用控件、通用的對話框、屬性表以及屬性頁、GDI對象、UI更新、可卷動(dòng)的窗口、分割窗口、命令條等等……

WTL的實(shí)現(xiàn)使用了和ATL一樣的模板架構(gòu)，所以對于ATL開發(fā)者顯得很自然。同時(shí)它并沒有改變或者是隱藏那些Windows相關(guān)結(jié)構(gòu)，那些Windows程序員在使用WTL時(shí)也不會(huì)感到很吃驚。WTL的一個(gè)主要設(shè)計(jì)原則就是避免在沒有引用到其他WTL類時(shí)，出現(xiàn)不必要的內(nèi)部依賴。這意味著我們的程序?qū)⒅话形覀儗?shí)際上所使用的代碼，除此之外再無其他的東西。加上了模板的使用后，這樣做得到的結(jié)果就是一些非常小的，不依賴于運(yùn)行庫的程序。

WTL專注于用面向?qū)ο蟮姆椒▉砭帉慦indows的用戶界面程序，同時(shí)保持代碼的尺寸很小。同時(shí)，它也為開發(fā)者提供了一個(gè)很好的基礎(chǔ)，可以寫新的類來擴(kuò)展WTL。

最后，我在編寫WTL時(shí)就希望開發(fā)者能夠喜歡在開發(fā)中使用它。我同樣也希望您能夠使用它并喜歡上它。