weiyan

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

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

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

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

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

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

　　[響應與挑戰]

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

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

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

　　我們已經進了社會,學習的就是圓滑的做人,
　　當你是主管, 就像文章中那位切換軌道的人,
　　內心的正義與現實沖突時, 你會如何抉擇呢?

　　不過- 換另一個角度，如不選擇切換軌道
　　因為，那群小朋友一定知道那是活的軌道
　　所以，當他們聽到火車的聲音時，就會知道要跑!

　　但若，將軌道切換后那個乖小孩必定慘死，
　　因為，他從來沒想過火車還會開到廢軌道上
　　所以，你認為呢？

　　或許這樣的想法與理念，
　　到了人老時才會發現
　　自己成為一個不斷被犧牲的可憐鬼，
　　但這個社會又為什么要把是與非顛倒來又顛倒去呢？

　　另外，再想想，一條鐵道會被停止使用，自由它的道理。
　　是否代表著這個鐵道本身有問題，未經驗證就使用它會遇到潛藏的危機呢？

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

在VC++下實現高彩色工具條

　　引言

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

　　基本設計思路

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

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

　　真彩工具條的實現

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

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

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

LoadImage返回一個位圖句柄HBITMAP，但在MFC下使用CBitmaps會更加方便，可創建一個
CBitmap對象并用Attach()成員函數將它與位圖句柄聯系起來：

CBitmap bm;
bm.Attach(hbm);

　　MFC加載工具欄位圖時使用了一個內部函數AfxLoadSysColorBitmap（）將缺省顏色設定為16色，因此為了顯示16色以上的圖像，必須在調用圖像列表類CImageList的Create（）函數創建圖像列表時對圖像清單做進一步的處理：

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

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

#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色（對于多數程序這樣已經足夠），則顯然沒有必要再使用更高級別的位深度定義。最后一步，也是最關鍵的一步，必須通過 SetImageList（）函數指定工具條m_wndToolBar的圖標來源不再是原來缺省的圖像列表而是含有高彩色位圖的圖像列表 m_ilToolBar：

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

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



　　小結

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


用VC制作非常酷的工具條

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

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

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

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

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

//注意下面這兩個參數決定了是否注冊Toolbar

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



　　然后就可以調用CreateWindowEx這個函數來建立Toolbar窗口:

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



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

HWND himl;
//MYICON_CX,MYICON_CY是每個按鈕的大小
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個普通的按鈕:

TBBUTTON tbArray[5]; //按鈕的數據結構
for(i=0;i＜5;i＋＋)
{
tbArray[i].iBitmap = i; //第i個位圖
tbArray[i].idCommand = IDM_BUTTONSTART＋i;
//命令ID
tbArray[i].fsState = TBSTATE_ENABLED;
tbArray[i].fsStyle = TBSTYLE_BUTTON;
//按鈕風格
tbArray[i].dwData = 0;
tbArray[i].iString = i; //顯示的字符串
}

//設置按鈕結構的大小

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



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

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

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

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

Dave Schmi


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

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

工具條的新特色

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

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

　　Visual C++程序員沒有這樣的經歷，因為在Visual C++4.0或5.0中comctl32.dll并不是一個可以再分發的組件，它在安裝Internet Explorer時被更新，因此MFC程序員無法依靠最新版本的某些功能來用于他們的程序。這就是CToolBar僅僅具有最初的DLL的有限功能的原 因。CToolBar能夠實現最新的特色意味著微軟將在Visual C++6.0中包含最新的DLL并將其作為一個可以再分發的組件。

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


#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



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

扁平鈕和把手

　　在過去的18個月中我常常被問及該如何獲得象Internet Explorer和Visual Studio中的工具條一樣不使用浮雕按鈕而是用扁平鈕并且帶有便于移動和定位的把手那樣酷的界面。這些特色并不被MFC所支持，因此最簡單獲取的方法就 是購買一個擴展庫。而對于Visual C++ 6.0來說卻無須多此一舉，因為它使得CToolBar類實現了對扁平鈕、把手和其它新的視覺效果的支持。

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


表 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()。這個新的函數在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
);


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

　　上面所作的兩個簡單的改變是使得一個已存程序獲得酷界面的最省力的方法。在一個程序具有了扁平鈕和把手的同時，它也不會發生不應有的其它改變。

C/C+語言struct深層探索

出處：PConline

1. struct的巨大作用
　　面對一個人的大型C/C++程序時，只看其對struct的使用情況我們就可以對其編寫者的編程經驗進行評估。因為一個大型的C/C++程序，勢必要涉及一些(甚至大量)進行數據組合的結構體，這些結構體可以將原本意義屬于一個整體的數據組合在一起。從某種程度上來說，會不會用struct，怎樣用struct是區別一個開發人員是否具備豐富開發經歷的標志。

　　在網絡協議、通信控制、嵌入式系統的C/C++編程中，我們經常要傳送的不是簡單的字節流（char型數組），而是多種數據組合起來的一個整體，其表現形式是一個結構體。

　　經驗不足的開發人員往往將所有需要傳送的內容依順序保存在char型數組中，通過指針偏移的方法傳送網絡報文等信息。這樣做編程復雜，易出錯，而且一旦控制方式及通信協議有所變化，程序就要進行非常細致的修改。

　　一個有經驗的開發者則靈活運用結構體，舉一個例子，假設網絡或控制協議中需要傳送三種報文，其格式分別為packetA、packetB、packetC：

struct structA
{
int a;
char b;
};

struct structB
{
char a;
short b;
};

struct structC
{
int a;
char b;
float c;
}
　　優秀的程序設計者這樣設計傳送的報文：

struct CommuPacket
{
int iPacketType;　　//報文類型標志
union　　　　　　//每次傳送的是三種報文中的一種，使用union
{
? struct structA packetA;
? struct structB packetB;
? struct structC packetC;
}
};
　　在進行報文傳送時，直接傳送struct CommuPacket一個整體。

　　假設發送函數的原形如下：

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

Recv( (char *)&recvCommuPacket , sizeof(CommuPacket) );
　　接著判斷報文類型進行相應處理：

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

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

　　利用這種強制類型轉化，我們還可以方便程序的編寫，例如要對sendCommuPacket所處內存初始化為0，可以這樣調用標準庫函數memset()：

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

2. struct的成員對齊
　　Intel、微軟等公司曾經出過一道類似的面試題：
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. }
　　問程序的輸入結果是什么？
　　答案是：
8
16
4
　　不明白？還是不明白？下面一一道來：
2.1 自然對界
　　struct是一種復合數據類型，其構成元素既可以是基本數據類型（如int、long、float等）的變量，也可以是一些復合數據類型（如array、struct、union等）的數據單元。對于結構體，編譯器會自動進行成員變量的對齊，以提高運算效率。缺省情況下，編譯器為結構體的每個成員按其自然對界（natural alignment）條件分配空間。各個成員按照它們被聲明的順序在內存中順序存儲，第一個成員的地址和整個結構的地址相同。
　　自然對界(natural alignment)即默認對齊方式，是指按結構體的成員中size最大的成員對齊。
　　例如：
struct naturalalign
{
char a;
short b;
char c;
};
　　在上述結構體中，size最大的是short，其長度為2字節，因而結構體中的char成員a、c都以2為單位對齊，sizeof(naturalalign)的結果等于6；
　　如果改為：
struct naturalalign
{
char a;
int b;
char c;
};
　　其結果顯然為12。

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

2.3 面試題的解答
　　至此，我們可以對Intel、微軟的面試題進行全面的解答。
　　程序中第2行#pragma pack (8)雖然指定了對界為8，但是由于struct example1中的成員最大size為4（long變量size為4），故struct example1仍然按4字節對界，struct example1的size為8，即第18行的輸出結果；
　　struct example2中包含了struct example1，其本身包含的簡單數據成員的最大size為2（short變量e），但是因為其包含了struct example1，而struct example1中的最大成員size為4，struct example2也應以4對界，#pragma pack (8)中指定的對界對struct example2也不起作用，故19行的輸出結果為16；
　　由于struct example2中的成員以4為單位對界，故其char變量c后應補充3個空，其后才是成員struct1的內存空間，20行的輸出結果為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

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

二、前期準備

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

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

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中創建的方法如下：

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

三、具體步驟

3.1 BLOB數據的保存

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

///假設m_pBMPBuffer指針指向一塊長度為m_nFileLen的二進制數據,并且已經成功打開了記錄集對象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); ///創建SAFEARRAY對象

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

varBLOB.vt = VT_ARRAY | VT_UI1;///將varBLOB的類型設置為BYTE類型的數組

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

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

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

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

3.2 BLOB數據的讀取

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

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

if(lDataSize > 0)
{
_variant_t varBLOB;

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

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

}

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

l???????? 創建

??????????????????????????? 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 ;

?????????野指針，也就是指向不可用內存區域的指針。通常對這種指針進行操作的話，將會使程序發生不可預知的錯誤。但是，我在文中要說的，就是野指針的“安全”使用方法以及其內部的原因.

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

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

之所以說其危險，是因為這是一段完全合乎語法的代碼，編譯的時候完美得一點錯誤也不會有，然而當運行到strcpy一句的時候，問題就會出現，因為在這之前，str的空間已經被delete掉了，所以strcpy當然不會成功。對于這種類似的情況，在林銳博士的書中有過介紹，稱其為“野指針”。

那么，諸位有沒有見過安全的“野指針”呢？下面請看我的一段C++程序，靈感來自CSDN上的一次討論。在此，我只需要C++的“類”，C++的其余一概不需要，因此我沒有使用任何的C++標準庫，連輸出都是用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，程序到此為止，諸位可以編譯運行一下看看結果如何。你也許會驚異地發現：沒有任何的出錯信息，屏幕上竟然乖乖地出現了這么一行字符串：

This is a test function.

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

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

這仍然沒有問題！！

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

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

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

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

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

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

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

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

以上的兩種情況，目的就是強迫野指針使用屬于自己的東西導致不安全，比如第一種情況中操作本身的m_nInteger，第二種情況中變為虛函數的Function成為了屬于對象的函數（這一點可以從sizeof看出來）。

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

關于成員函數CTestClass::Function的補充說明

這個函數是一個普通的成員函數，它在編譯器的處理下，會成為類似如下的代碼：

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

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

Function( p );

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

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

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

那么它將會被編譯器解釋為：

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

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

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

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

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

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

上面的代碼已經說明了，如果p指向一個無效的地址，那么必然會有非法操作。

備注：

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

?????????在進行軟件開發過程中間，有很多小功能的實現，雖然這些東西你可以不用，但是如果應用仂將會是你的程序更具有專業性。?
一、設置程序自動運行。??
???????很多監控軟件要求軟件能夠在系統重新啟動后不用用戶去點擊圖標啟動項目，而是直接能夠啟動運行，方法是寫注冊表Software\\Microsoft\\Windows\\CurrentVersion\\Run。參考程序可以見下：(查找程序目錄的執行文件，存在則進行添加注冊表操作)?
???????? 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";//這里加上你要查找的執行文件名稱?
??? 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());//這里加上你需要在注冊表中注冊的內容?
??????? this->UpdateData(FALSE);?
??? }?
??? else?
??? {?
??????? theApp.SetMainSkin();?
??????? ::AfxMessageBox("沒找到執行程序，自動運行失敗");?
??????? exit(0);?
??? }?

二、自動配置數據源?
??? 很多的程序都要用到數據庫結合的操作，這里舉例ACCESS，因為ACCESS在中小型VC系統開發中是最常用到的，如果程序的移植，如果對于很初級的用戶來說，你還需要他到配置面板中進行數據源配置的話，那就有點說不過去了。?
???????? #include <odbcinst.h>?
???????? //配置數據源，數據庫在應用程序目錄下,這里比如數據庫文件名為***.mdb，程序運行時候可以將數據庫文件拷貝到程序目錄下面。?
??? 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";//這里修改成你的數據庫文件名稱?
??? CFileFind? fFind;?
??? if(!fFind.FindFile(lpszFileName))?
??? {?
??????? ::AfxMessageBox("沒有找到數據庫");?
??????? exit(0);?
??? }??
??? CString szDesc;?
??? szDesc.Format( "DSN=****;Description=****;DESCRIPTION=The DataBase For ***;FIL=MicrosoftAccess;DEFAULTDIR=%s;DBQ=%s;" ,sPath,lpszFileName);//這里***號可以添加成你的描述?

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

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

四、在你的程序中間加載其他應用程序：?
??? 你的程序除了調用到各個模塊進行協同工作外（DLL），還有可能調用不是同一個開發環境下的應用程序，比如VC環境下調用DELPHI，VB開發的執行程序，你就可以用到下面的方法（將調用的應用程序拷貝程序目錄中）：?
???????? 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";//這里修改成你的調用應用程序的文件名稱?
??? CFileFind? fFind;?
??? if(!fFind.FindFile(lpszFileName))?
??? {?
??????? ::AfxMessageBox("沒有找到調用的應用程序！");??
??????? return FALSE;?
??? }?
??? else?
??????? ShellExecute(NULL,NULL,_T("***.exe"),NULL,sPath,NULL);??

五、結束進程：?
??? 在你的程序中結束別的程序進程，采用的方法是進行進程列舉，然后采用查找的方法進行：?
???????? #include "TLHELP32.H"?
???????? DWORD ProcessID[50];?
??? CString kkk[50];?
??? HANDLE SnapShot=CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS,0);??
??? PROCESSENTRY32* info=new PROCESSENTRY32;?
??? PROCESSENTRY32 ProcessInfo;//聲明進程信息變量?
??? ProcessInfo.dwSize=sizeof(ProcessInfo);//設置ProcessInfo的大小?
??? //返回系統中第一個進程的信息?
??? 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就是你要結束的進程的名稱?
??????? {?
??????????? HANDLE ProcessHandle;?
??????????? ProcessHandle=OpenProcess (PROCESS_ALL_ACCESS,FALSE,ProcessID[m_nProcess]);?
??????????? TerminateProcess(ProcessHandle,0);?????
??????? }?
??????? Status=Process32Next(SnapShot,&ProcessInfo);?
??????? m_nProcess++;?
??? }?

???作為現代C++最重要的特色技術，template正在各個傳統領域攻城略地。從基本算法與數據結構，到正則表達式與XML解析，從高性能數學計算，到資源的分配與管理，從網絡分布式計算環境，到組件模型創建，從靜態多態性的維度擴展，到設計模式的自動生成，神奇的template顯示出其令人嘆為觀止的強勁實力，如果不是有一個隱隱的痛處，template愛好者簡直可以去狂歡了。

這個隱隱的痛處，就是在GUI編程領域。

???現有的大部分成熟GUI框架和工具庫，其定型時間都在90年代早期，不管是因為什么原因，總之我們根本看不到template技術在這些環境中的任何重要運用。無論是專有MFC和OWL，還是開源的wxWindow和Mozilla, 以至于是專有還是開源都說不清楚的Qt，它們在其他方面有著諸多不同，偏偏倒是在對待模板技術上空前一致：嚴格限制在底層的數據結構領域內，抵制模板技術流入GUI主體結構。最過分的wxWindow和Mozilla，在代碼編寫規范里嚴厲禁止使用1990年之后發展出來的任何C++特性，模板、異常、多繼承、STL等等，均在黑名單上。諸位有興趣，不妨去看看，那與其說是一份C++代碼編寫規范，倒不如說是對C++現代特性在GUI領域應用的一份不公正的判決書。

難道模板技術真的在GUI領域無用武之地嗎？

WTL給出了一個響亮的回答。

???WTL是微軟ATL開發組成員Nenad Stefanovic先生在ATL Windowing機制上發展起來的一整套GUI框架，運用template技術組織和創建GUI對象，構筑了精致的面向對象框架（沒錯，在這里object oriented與template達成了精致的融合）。雖然沒有獲得微軟的官方支持，雖然其使用者人數很少，但是確實是“用過的都說好”，有位微軟MVP人士甚至說，這是微軟有史以來推出的最優秀的一個framework。真是一個有趣的諷刺，最好的東西居然不被官方支持。有關于WTL的流言不少，比如這東西原本是微軟內部專用，只是因為不小心才被泄漏出來等等，這更加劇它的神秘色彩。相信大家對它一定有不少問題。我們特別邀請到了WTL之父Nenad Stefanovic先生，進行了一次網上的訪談，希望能幫助大家了解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】：好的。我現在在Microsoft工作，是它里面的一個軟件開發人員。你們雜志的讀者中可能有人知道，我就是Windows Template Library （WTL）的創作者。我來自于前南斯拉夫，在那我完成了我的學業并開始了我作為軟件開發人員的工作生涯。現在，我在美國居住的時間已經超過了10年了。

???中國的文化以及傳統給我留下了極為深刻的印象，我對此十分感興趣。我想，作為一個國家以及民族，中國已經處于一個偉大并且不斷在成長中的位置上。作為一個從前南斯拉夫來的人，我早就了解到關于中國的很多事情。在與來自中國的人民的接觸過程中，我還了解到了你們日常生活的一些狀況。我還想了解更多（有關中國的事情），希望有一天我可以到中國來游覽。

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

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

【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）開發工作時的產物。那時我們正在擴展ATL，使之得以支持ActiveX control，而我負責的就是其中對于窗口機制部分的支持。這時，我就開始想，是不是可以把同樣的技術應用到更為廣泛的窗口機制中，以獲得更豐富的UI控制、組件、以至于應用程序呢？于是，作為ATL的一部分，WTL被開發出來了。它將ATL進行了擴展，以使得它可以支持各種類型的與UI相關的組件或者應用程序。然而，它并沒有隨著ATL一同集成在Visual Studio中被發布，于是我就決定將它作為一個單獨的ATL擴展庫發布出去。

我認為WTL將一直是那些在Windows下開發應用程序以及組件的開發者的一個很好的選擇。我并不認為在以后，我們會對WTL有一個大的改動（或者增添），因為WTL的一個設計宗旨就是“遵循Win32 UI的API及其設計”。現在如此，將來還是會如此下去。

【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月。在那時，我就想：“沒有官方的支持，沒有文檔，也沒有商業吹捧，它最多只能夠存活6個月。”但現在15個月過去了，它反而流傳得更為廣泛，更加的生機勃勃。許多C++程序員，尤其是一些我們所認知的“專家”以及“大師”，都在使用WTL。我當然知道這主要是因為WTL的出色，但我想，能夠在沒有官方的力量牽涉的情況下吸引如此多的注意，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】：我認為WTL成功的最主要原因就是，它確實而且及時地滿足了開發者的需求。越來越多的開發人員開始使用ATL，當他們需要更多的UI支持時，他們很自然的就會開始使用WTL。 從其他的開發團隊所提供支持來看，WTL看起來似乎要比其他的項目更加開放。許許多多人為WTL做了大量工作，如：創建示例代碼，撰寫文檔等。WTL之所以能夠被廣為接受并獲得如此大的成功，來自于這些開發團隊的支持絕對是一個重要的因素。

【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++的提倡者是不是真的認為會有一些C++的用戶轉而去學習它呢？您的看法又是如何呢？

【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】：我認為MFC是一個了不起的框架庫。請不要忘了，在MFC被設計出來初期，那時的C++編譯器還具有很多的限制，并且那時主要的平臺還只是16位的Windows。不幸的是，由于MFC被設計成為一個框架，使得我們很難利用新編譯器中那些更好的C++特性來改進它，也很難將Windows中的很多新特性添加到MFC中。我不喜歡MFC的地方是它高度依賴DLL的特性——因為它將導致許多兼容性方面的問題；還有就是MFC的整個框架設計——它在應用程序的設計中限定了太多東西。

Managed C++是C++的一個擴展，它允許C++程序得以使用受管（managed）代碼。我們需要了解的一個很重要的特性就是，我們可以使用MC++來編譯已有的C++代碼而無需對它們進行任何改動。MC++允許開發者同時使用他們所熟悉的非受管代碼以及受管代碼來開發同一個模塊。這就提供了一個非常好的途徑，使已有的代碼與新的受管代碼相互作用，并也可使得我們創建一個項目，同時使用受管的和傳統的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年中（甚至更長的一段時間內），C以及C++構成了幾乎所有Microsoft技術的基礎（如：OS，COM等）。我們這些C++用戶花費了大量的時間來熟悉并掌握它們（C以及C++），因為我們相信我們所付出的一定會有回報（?）。但現在的風向好像有了很大的改變。.NET出現了，世界似乎就要充斥CLR （Common Language Runtime，公共語言運行庫）以及／或JVM （Java Virtual Machine，Java虛擬機）。現在C++已經出現了退潮的跡象。那么，請問您對于C++（不是MC++）在Microsoft技術中的前景如何看待？它是否會由此消亡？還是就此淪落為一門邊緣語言？

【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】：是的，世界也已經發生了變化。對于網絡服務以及連接這樣的新型應用程序的開發已經浮上了水面。我認為那些新的編程語言（如Java，C#，以及VB.NET）都是針對以下兩個主要的問題而開發出來的——簡化軟件的開發過程以及對于Internet應用程序開發提供更好的的支持。簡化軟件的開發過程使得更多的開發者可以寫出更多更好的應用程序并減少完成開發項目所需要的時間。而支持Internet的開發，對于這個Internet越來越深入到我們的日常生活中的時代來說，毫無疑問是一件非常重要的事情。

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

【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】：我們的讀者中有很多是初學者，在他們學習完（標準）C++后，他們希望能夠找到一條道路，掌握到足夠多的Microsoft的技術使自己成為經驗豐富的、熟練的程序員。您能不能給我們指出這樣的一條道路來呢？我們是不是應該學習Win32 API編程？學習MFC是否是值得的？WTL/ATL/STL算得上是一個可靠的解決方案嗎？又或是我們應該直接學習C#？如果您能夠給我們一些建議，相信會有很多的人為此而感激您的。

【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】：我認為這主要取決于他們的計劃以及雄心。你所做的越多，在長時間競爭中你就越占據優勢。不過你也要注意保持與實際問題的平衡。我建議那些決心以后只做Internet相關開發的人可以直接去學習C#或者VB.NET，同時學習.NET平臺。而那些更多地了解Windows平臺以及它所提供的服務方面知識的人，當然就必須需要更多地了解有關Win32 API以及那些支持Windows編程的庫相關的知識。

【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】：在我剛開始學習WTL后不久，有一位熱心人給我發了份郵件。他寫道：“如果你不是一個好的ATL程序員的話，你就不可能成為一個好的WTL程序員；如果你不會COM編程的話，你就不可能成為一個好的ATL程序員；但一旦你決定開始學習COM，你就邁出了踏向地獄的第一步。”COM是不是真的那么難學？我們應該如何地來學習WTL呢？我們是不是應該按照這樣的順序學下來呢，API->COM->ATL->WTL？還有，COM將會變得如何？他是不是還能夠保持Microsoft的核心技術這一頭銜，抑或是被.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】：我不認為使用和理解WTL就一定要掌握COM。相比于COM來說，Win32 UI的知識對于理解WTL顯得更為重要。但毫無疑問的是，ATL的相關知識是必不可少的。由于ATL主要任務就是支持COM，所以，有COM的知識只是會更好一些而已，但它們并不是必需的。

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

【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】：請問您對于泛型程序設計是如何看待的？它到底是OOP的一個補充呢，還是完全不同于OOP的另外一個程序設計范型呢？我們是否可以將GP以及OOP一同聯合使用？我想，在設計和實作出WTL的艱苦過程中，對于OOP以及GP之間的關系，您一定有了自己的看法，您能不能給我們說一下呢？

【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從不顯式地表達出設計元素之間的關聯來。然而，它們也可以被非常高效地組合運用。

WTL中使用了一種GP連同OOP的設計。我在其中大量使用了模板來實作出傳統的OOP中的類。我很樂意指出的是，WTL中并沒有使用一種“純”設計，它也沒有遵循任何的設計指導方針或者設計規格。可是，我還是認為WTL使用到了C++語言中的最主要的精髓處——對于一個特定的問題使用一種最適合它的適當典范。

【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開發小組中的一員。請問您對于此事是如何看待的？您認為Microsoft試圖向公眾傳播一種什么樣的信息呢？這是否也意味著Microsoft希望VC.NET成為一個完全標準化的C++編譯器，并繼續保持C++的核心系統語言地位呢？

【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】：我認為這顯示了Microsoft對于促進C++編譯器以及語言繼續發展的決心，并為此找到了最佳人選來獲取幫助。我確信VC.NET將會繼續是開發應用程序的強有力工具，并且它同時還將包含有.NET開發能力。目前我們正在進行兼容C++標準方面的工作，不久我們就會看到成效。

【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】：我現在正在學習WTL以及ATL，既然您是WTL的作者，同時又是ATL開發小組中的一員，您能不能給我一些建議呢？

【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來說，有好幾個編程方面的領域是十分重要的：大體上的C++語言知識，了解模板，COM（對ATL而言），以及Windows UI編程（對WTL而言）。在這些領域有著堅實的基礎對于WTL以及ATL開發人員來說有著很大的好處，同時對于理解這兩個的源代碼也能夠起到幫助作用。

我同樣也很樂意去鼓勵大家多寫程序。這也是學習如何使用一個程序庫，或者一門編程語言，或者一個操作系統的一個最好的方法。在寫程序的過程中經常會出現一些書本上沒有提及但又必須被解決的問題。在開始學習時讀一些東西是很有用的，而寫程序則是向縱深發展的最佳方式。

【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】：有人說，我們現在已經處于后PC時代的門口，未來將會是一個嵌入系統的世界，嵌入式的智能設備將會無所不在，并且對比PC來說，嵌入系統的產業將會是一個更大的市場。您是否相信這些呢？您是否認為WTL以及其他的一些C++模板庫對于嵌入式開發也適用呢？它們是否適合Internet開發？

【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】：是的，我認為我們現今所使用的各種設備中的大部分在以后都將會演變成為一些小的，具有專門用途的計算機。但這并不意味著PC的數目以及重要性將會由此降低，只不過是表明還有著許多其他的設備需要被加強以使得我們可以對其進行編程并且連接。由于必須需要有軟件的支持，而軟件又需要有人來寫，這些新的設備將會給軟件開發人員帶來極大的機遇。

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

【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年（甚至更長的一段時間）內，COM都是Microsoft中的核心技術。現在我們可以預見到，在下一個十年間，這個核心將會變為.NET。我的問題就是，COM有什么過錯？COM將何去何從？它是否會逐漸消失呢，還是會被其他的一些技術給替代？COM和.NET之間的關系是什么樣的情況？.NET是否是基于COM之上呢？現在學習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】：或許你不應該問COM有什么過錯，而是應該把.NET看成COM的進化。.NET擴展了COM最初的目的——創建可重用的二進制程序組件——并向其中添加了很多重要的特性：豐富的元數據，了不起的運行庫，內建的安全機制，版本機制等。對于現今的軟件開發來說，所有的這些新的特性都非常重要，所以.NET能夠廣泛地支持它們，是一件很偉大的產品。Microsoft同時也提供了在.NET和COM之間進行互操作的能力，這使得以前所開發出來的COM組件在.NET環境中同樣也能夠得到使用。

我仍然認為學習COM是一個很好的主意——它甚至對于那些希望學習.NET的人們來說也是一個很好的開端，學習COM同時也有助于我們更深入地理解 .NET本身的設計和實現。

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

【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++是一門偉大的語言，即便遇到了新的挑戰，它仍然將是非常重要的。程序庫對于語言本身是極好的補充，它們為開發者提供了一些十分有用的可重用代碼。存在如此眾多的、了不起C++程序庫，這件事情本身就表明了C++社區的龐大和強大。我認為這場變革已經成功了，并且會一直成功下去。你們可以放心，VC.NET開發組是不會對這些已有的程序庫熟視無睹的，我預期他們會不斷地加強對于這些庫的支持。

【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】：最后一個問題。既然許多人并不了解WTL，作為WTL之父，您現在有機會在這里做一個演講，請簡短地介紹一下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是一個基于模板的、專為開發用戶界面的程序庫。它擴展了ATL，并提供了一些類用來實現應用程序的用戶界面、組件和控件。它提供了各種類來支持各種各樣的用戶界面元素：頂級窗口、MDI、標準控件和通用控件、通用的對話框、屬性表以及屬性頁、GDI對象、UI更新、可卷動的窗口、分割窗口、命令條等等……

WTL的實現使用了和ATL一樣的模板架構，所以對于ATL開發者顯得很自然。同時它并沒有改變或者是隱藏那些Windows相關結構，那些Windows程序員在使用WTL時也不會感到很吃驚。WTL的一個主要設計原則就是避免在沒有引用到其他WTL類時，出現不必要的內部依賴。這意味著我們的程序將只包含有我們實際上所使用的代碼，除此之外再無其他的東西。加上了模板的使用后，這樣做得到的結果就是一些非常小的，不依賴于運行庫的程序。

WTL專注于用面向對象的方法來編寫Windows的用戶界面程序，同時保持代碼的尺寸很小。同時，它也為開發者提供了一個很好的基礎，可以寫新的類來擴展WTL。

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