vc程序員是做什麼

『壹』 C++程序員是幹嘛的

C++效率高 開發編譯器也可以 但是那是少數 大部分是用來製作對效率要求高的軟體 游戲。 效率不高的用VB就行了 MFC就可以開發對話框軟體
還有C和C++是不分家的 C也相對其他語言難學 如果C學的好學其他語言會比較快 "這2種程序員"這句話本身就不對 程序員可不是掌握一門語言就夠的

『貳』 程序員是做什麼的什麼是程序

程序員：

程序員是從事程序開發、程序維護的專業人員。程序員一般需要會做：確認通過審查方案的目標，輸入數據，分析師，監事，和客戶的輸出要求的項目要求。

通常情況下將程序員分為程序設計人員和程序編碼人員，軟體從業人員分為初級程序員、中級程序員、高級程序員（現為軟體設計師）、系統分析員，系統架構師，測試工程師六大類。

程序：

程序是一組計算機能識別和執行的指令，運行於電子計算機上，滿足人們某種需求的信息化工具。以某些程序設計語言編寫，運行於某種目標結構體繫上。

程序就如同以英語（程序設計語言）寫作的文章，要讓一個懂得英語的人（編譯器）同時也會閱讀這篇文章的人（結構體系）來閱讀、理解、標記這篇文章。

(2)vc程序員是做什麼擴展閱讀：

程序員的日常工作：

1、確認通過審查方案的目標，輸入數據，分析師，監事，和客戶的輸出要求的項目要求。

2、安排項目要求在編程序列分析要求;准備工作流程圖和使用計算機知識的能力，題材，編程語言和邏輯圖。

3、編碼工作流程的信息轉換成計算機語言的項目要求。

4、通過輸入編碼信息的計算機程序。

5、確認程序操作進行測試，修改程序序列和/或代碼。

6、准備寫操作指令供用戶參考。

7、保持歷史記錄，通過記錄方案的制定和修訂。

參考鏈接：網路-程序員

網路-程序

『叄』 程序員是干什麼的啊

程序員是寫程序的屬於電腦IT行業。

程序員(英文Programmer)是從事程序開發、維護的專業人員。一般將程序員分為程序設計人員和程序編碼人員。

軟體從業人員分為初級程序員、高級程序員、系統分析員，系統架構師，測試工程師五大類。

一年可報考軟考程序員考試兩次，但一次考試只能報考一種資格，因此報考了程序員考試則無法再報考軟考其他級別或科目的考試。

同時軟考程序員考試採用筆試形式，考試實行全國統一大綱、統一試題、統一時間、統一標准、統一證書的考試方式。

『肆』 VC是什麼全稱是什麼

中文名稱： 碳酸亞乙烯酯；VC
英文名稱：Vinylene carbonate
VC在合金中除做主體成分外，還常以添加物成分加入合金中，其主要作用是：降低合金性能對燒結溫度和時間的敏感性，或者說，使合金磁力（Hc）和硬度（HRA）合格的燒結溫度和時間的范圍增大，抑制燒結時碳化物晶粒長大；改變相組成，提高合金耐熱性，添加劑能使WC-Co合金二相區變寬，減小碳對合金性能影響的敏感性；提高合金月牙窪磨損，減少刀瘤，改善斷屑性能等 。
VC在合金中以添加劑物成分加入時，其添加的量的多少應因不同基體合金成分的不同而不同，由於VC的存在可導致合金粉末的壓縮性能下降，隨VC含量的增大，壓坯密度下降的幅度有下降的趨勢。

『伍』 C++程序員和VC程序員.(不太懂的就不要回答了)

呵呵，VC是Microsoft的一個非常好用的C++編程工具，它的最大優勢就是有一個對於程序員來說非常實用的MFC（微軟基礎類庫），掌握和運用好MFC將會給C++編程帶來非常高的開發效率，因此，大多數的C++程序員都喜歡用VC,不但開發環境友好，而且有強大的MFC支持。
而C++就「裸」得多了，它只不過是一個編程語言而已，既編程符合C++語法規范就可以了，它沒有提供更多的經封裝過的類庫，很多開發都要從頭或從底層來，如果只是開發演算法或者一些核心技術，並不涉及太多的UI（用戶界面），就盡量不要使用MFC庫了（為了有更好的移植性，避開對Windows操作系統的依賴），相反，如果確定在Windows操作系統上開發應用系統，使用VC就是一個很好的選擇。C++本身是不依賴於具體的硬體平台和操作系統的，比如Nokia手機上的程序開發，VC就使不上勁了，而C++就可以很好的使用。
因此，程序員要看自己編程的應用環境，來決定使用「純」C++還是VC（特指使用MFC，因為VC工具照樣可以開發純C++程序）。對於你所說的所謂「C++程序員」和「VC程序員」，一般有以下區別：
C++程序員對C++非常熟，能夠從底層開發核心技術和演算法，能夠自己用「面向對象」的概念設計程序，而且可以開發不同硬體平台和操作系統下的應用軟體。而VC程序員對VC開發工具和MFC框架和類庫十分了解，可以快速的「造」出十分出色應用軟體。這兩類程序員都是十分搶手的。（當然，優秀的VC程序員照樣可以是非常優秀的C++程序員）
同樣，一個優秀的C++程序員可以在不同的操作系統或者開發工具上很好的應用C++開發各種應用軟體，當然，它需要一段時間熟悉開發工具（比如VC++，C++ Builder等等）。
至於薪水，並沒有多大的差別，主要還是看工作的性質、內容、完成質量以及公司實力等等，通常而言，一個優秀的程序員都需要有良好的工作經驗和很強的學習能力、創新能力。

『陸』 VC程序員到底是做什麼到底做什麼

別看那麼遠，VC入門不那麼容易，如果你真的把那些東西學習扎實了我想你現在應該具備了一定的VC編程能力了。如果你能夠在不看書的情況下把書中所有的例子重新編寫一遍的話你就已經很不錯了，編寫qq也不是過把書里的技術組合起來，你不一定要一次達到那麼高的水平，你不妨從1-2個功能組合開始，嘗試組合不同的功能，最後也許就組合出一個qq。星際爭霸源代碼裡面你至少能看懂一個簡單函數吧，做最小的做起，不要好高騖遠，也不要妄自菲薄。

『柒』 VC++是什麼

概述VC++是微軟公司開發的一個IDE(集成開發環境),換句話說,就是使用c++的一個開發平台.有些軟體就是這個編出來的...另外還有VB,VF.只是使用不同語言...但是,
vc++是Windows平台上的C++編程環境，學習VC要了解很多Windows平台的特性並且還要掌握MFC、ATL、COM等的知識，難度比較大。Windows下編程需要了解Windows的消息機制以及回調（callback）函數的原理；MFC是Win32API的包裝類，需要理解文檔視圖類的結構，窗口類的結構，消息流向等等；COM是代碼共享的二進制標准，需要掌握其基本原理等等。
VC作為一個主流的開發平台一直深受編程愛好者的喜愛，但是很多人卻對它的入門感到難於上青天，究其原因主要是大家對他錯誤的認識造成的，嚴格的來說VC++不是門語言，雖然它和C++之間有密切的關系,如果形象點比喻的話，可以把C++看作為一種「工業標准」，而VC++則是某種操作系統平台下的「廠商標准」,而「廠商標准」是在遵循「工業標准」的前提下擴展而來的。
VC++應用程序的開發主要有兩種模式，一種是WIN API方式，另一種則是MFC方式，傳統的WIN API開發方式比較繁瑣，而MFC則是對WIN API再次封裝，所以MFC相對於WIN API開發更具備效率優勢，但為了對WINDOWS開發有一個較為全面細致的認識，筆者在這里還是以講解WIN API的相關內容為主線。
話說到這里可能更多人關心的是學習VC++需要具備什麼條件，為什麼對於這扇門屢攻不破呢？
要想學習好VC必須具備良好的C/C++的基礎，必要的英語閱讀能力也是必不可少的，因為大量的技術文檔多以英文形式發布。 本書主要從程序內部運行的機制和MFC程序的組織脈絡入手，使讀者在學習VC++編程知識時，既能夠知其然，又能知其所以然，從而幫助讀者從根本上理解和掌握Windows的程序設計。另外，全書還貫穿作者多年來學習編程的一些經驗，以及一些學習方法的建議，為讀者進一步的學習提供指導。
本書從實際應用入手，由淺入深、循序漸進地講述Windows程序內部運行機制、MFC框架、文本、菜單、對話框、文件操作、網路編程、進程間通信、ActiveX控制項、動態鏈接庫、HOOK編程等多個主題。
本書內容豐富、實用性強，許多代碼可以直接應用到工程項目中。書中的配套光碟還免費提供近乎45小時的VC++教學視頻，讀者在學習的過程中可以將視頻和書互為參考，配合學習，這樣可以更快、更好地掌握VC++編程。
本書適合於VC++6．0的初學者和使用VC++從事開發的程序員，對於具有一定VC++編程經驗的讀者價值。VC++中播放聲音的方法編輯本段聲音是多媒體的一個重要組成部分，在應用程序中加入聲音可以使界面更友好。在VC++中可以根據不同的應用要求，用不同的方法實現聲音的播放。
一．播放聲音文件的簡單方法
在VC++ 中的多媒體動態連接庫中提供了一組與音頻設備有關的函數。利用這些函數可以方便地播放聲音。最簡單的播放聲音方法就是直接調用VC++中提供的聲音播放函數BOOL sndPlaySound ( LPCSTR lpszSound,UINT fuSound ); 或BOOL PlaySound( LPCSTR lpszSound, HMODULE hmod, DWORD fuSound );其中參數lpszSound是需要播放聲音的.WAV文件的路徑和文件名， hmod在這里為NULL，fuSound是播放聲音的標志,詳細說明請參考VC++中的幫助。 例如播放C:soundmusic.wav可以用sndPlaySound ("c:\sound\music.wav",SND_ASYNC);或PlaySound("c:\sound\music.wav",NULL, SND_ASYNC|SND_NODEFAULT );如果沒有找到music.wav文件，第一種格式將播放系統默認的聲音，第二種格式不會播放系統默認的聲音。
二．將聲音文件加入到程序中
在VC++的程序設計中，可以利用各種標準的資源，如點陣圖，菜單，對話框等。同時VC++也允許用戶自定義資源，因此我們可以將聲音文件作為用戶自定義資源加入程序資源文件中，經過編譯連接生成EXE文件，實現無.WAV文件的聲音播放。
要實現作為資源的聲音文件的播放，首先要在資源管理器中加入待播放的聲音文件（實現過程並不復雜，這里不在敘述）。假設生成的聲音文件資源標識符為IDR_WAVE1。在播放時只需要調用下面的語句：
PlaySound(MAKEINTRESOURCE(IDR_WAVE1),AfxGetResourceHandle(), SND_ASYNC|SND_RESOURCE|SND_NODEFAULT|SND_LOOP);
其中MAKEINTRESOURCE()宏將整數資源標識符轉變為字元串，AfxGetResourceHandle()函數返回包含資源的模塊句柄，
SND_RESOURCE是必須的標志。
作為資源的聲音文件的第二種播放方法是把資源讀入內存後作為內存數據播放。具體步驟入下：
1．獲得包含資源的模塊句柄：
HMODULE hmod=AfxGetResourceHandle();
2．檢索資源塊信息：
HRSRC hSndResource=FindResource(hmod,MAKEINTRESOURCE(IDR_WAVE1),_T("WAVE"));
3. 裝載資源數據並加鎖：
HGLOBAL hGlobalMem=LoadResource(hmod,hSndResource);
LPCTSTR lpMemSound=(LPCSTR)LockResource(hGlobalMem);
4．播放聲音文件：
sndPlaySound(lpMemSound,SND_MEMORY))；
5．釋放資源句柄：
FreeResource(hGlobalMem);
三．播放聲音文件的高級方法
在VC++中提供了一組對音頻設備及多媒體文件直接進行操作的函數。利用這些函數可以靈活地對聲音文件進行各種處理。
首先介紹幾個要用到的數據結構。WAVEFORMATEX結構定義了WAVE音頻數據文件的格式。WAVEHDR結構定義了波形音頻緩沖區。讀出的數據首先要填充此緩沖區才能送音頻設備播放。WAVEOUTCAPS結構描述了音頻設備的性能。MMCKINFO結構包含了RIFF文件中一個塊的信息。詳細的說明請參考VC++中的幫助。
下面給出程序流程簡圖及程序源代碼清單，在VC++環境下可直接使用：
源程序清單如下：
LPSTR szFileName;//聲音文件名
MMCKINFO mmckinfoParent;
MMCKINFO mmckinfoSubChunk;
DWORD dwFmtSize;
HMMIO m_hmmio;//音頻文件句柄
DWORD m_WaveLong;
HPSTR lpData;//音頻數據
HANDLE m_hData;
HANDLE m_hFormat;
WAVEFORMATEX * lpFormat;
DWORD m_dwDataOffset;
DWORD m_dwDataSize;
WAVEHDR pWaveOutHdr;
WAVEOUTCAPS pwoc;
HWAVEOUT hWaveOut;
//打開波形文件
if(!(m_hmmio=mmioOpen(szFileName,NULL,MMIO_READ|MMIO_ALLOCBUF)))
{
//File open Error
Error("Failed to open the file.");//錯誤處理函數
return false;
}
//檢查打開文件是否是聲音文件
mmckinfoParent.fccType =mmioFOURCC(』W』,』A』,』V』,』E』);
if(mmioDescend(m_hmmio,(LPMMCKINFO)&mmckinfoParent,NULL,MMIO_FINDRIFF))
{
//NOT WAVE FILE AND QUIT
}
//尋找 』fmt』 塊
mmckinfoSubChunk.ckid =mmioFOURCC(』f』,』m』,』t』,』 』);
if(mmioDescend(m_hmmio,&mmckinfoSubChunk,&mmckinfoParent,MMIO_FINDCHUNK))
{
//Can』t find 』fmt』 chunk
}
//獲得 』fmt 』塊的大小，申請內存
dwFmtSize=mmckinfoSubChunk.cksize ;
m_hFormat=LocalAlloc(LMEM_MOVEABLE,LOWORD(dwFmtSize));
if(!m_hFormat)
{
//failed alloc memory
}
lpFormat=(WAVEFORMATEX*)LocalLock(m_hFormat);
if(!lpFormat)
{
//failed to lock the memory
}
if((unsigned long)mmioRead(m_hmmio,(HPSTR)lpFormat,dwFmtSize)!=dwFmtSize)
{
//failed to read format chunk
}
//離開 fmt 塊
mmioAscend(m_hmmio,&mmckinfoSubChunk,0);
//尋找 』data』 塊
mmckinfoSubChunk.ckid=mmioFOURCC(』d』,』a』,』t』,』a』);
if(mmioDescend(m_hmmio,&mmckinfoSubChunk,&mmckinfoParent,MMIO_FINDCHUNK))
{
//Can』t find 』data』 chunk
}
//獲得 』data』塊的大小
m_dwDataSize=mmckinfoSubChunk.cksize ;
m_dwDataOffset =mmckinfoSubChunk.dwDataOffset ;
if(m_dwDataSize==0L)
{
//no data in the 』data』 chunk
}
//為音頻數據分配內存
lpData=new char[m_dwDataSize];
if(!lpData)
{
//faile
}
if(mmioSeek(m_hmmio,SoundOffset,SEEK_SET)<0)
{
//Failed to read the data chunk
}
m_WaveLong=mmioRead(m_hmmio,lpData,SoundLong);
if(m_WaveLong<0)
{
//Failed to read the data chunk
}
//檢查音頻設備，返迴音頻輸出設備的性能
if(waveOutGetDeVCaps(WAVE_MAPPER,&pwoc,sizeof(WAVEOUTCAPS))!=0)
{
//Unable to allocate or lock memory
}
//檢查音頻輸出設備是否能播放指定的音頻文件
if(waveOutOpen(&hWaveOut,DevsNum,lpFormat,NULL,NULL,CALLBACK_NULL)!=0)
{
//Failed to OPEN the wave out devices
}
//准備待播放的數據
pWaveOutHdr.lpData =(HPSTR)lpData;
pWaveOutHdr.dwBufferLength =m_WaveLong;
pWaveOutHdr.dwFlags =0;
if(waveOutPrepareHeader(hWaveOut,&pWaveOutHdr,sizeof(WAVEHDR))!=0)
{
//Failed to prepare the wave data buffer
}
//播放音頻數據文件
if(waveOutWrite(hWaveOut,&pWaveOutHdr,sizeof(WAVEHDR))!=0)
{
//Failed to write the wave data buffer
}
//關閉音頻輸出設備,釋放內存
waveOutReset(hWaveOut);
waveOutClose(hWaveOut);
LocalUnlock(m_hFormat);
LocalFree(m_hFormat);
delete [] lpData;
說明：1）以上使用的音頻設備和聲音文件操作函數的聲明包含在mmsystem.h頭文件中，因此在程序中必須用#include "mmsystem.h"語句加入頭文件。同時在編譯時要加入動態連接導入庫winmm.lib，具體實現方法是從Developer Studio的Project菜單中選擇Settings,然後在Link選項卡上的Object/Library Moles控制中加入winmm.lib。2）在pWaveOutHdr.lpData中指定不同的數據，可以播放音頻數據文件中任意指定位置的聲音。3) 以上程序均在VC++6.0中調試通過，在文中省略了對錯誤及異常情況的處理，在實際應用中必須加入。
四．結論
在VC++中可以根據應用需要採用不同的方法播放聲音文件。簡單應用可以直接調用聲音播放函數。第二種方法可以把聲音作為資源加入可執行文件中。如果在播放之前要對聲音數據進行處理，可用第三種方法。
五.Visual C++.NET
隨著NET的時代來臨,VC++也如同VB一樣,脫胎換骨到VC++.NET

『捌』 vc++是上什麼

VC和Delphi作為開發平台，很重要的一點就是提供了一個"無所不包"的應用框架：VC的MFC和Delphi的VCL。MFC是用C++寫的，VCL是用Object Pascal寫的。當然，我們都知道，C++的使用范圍比Object Pascal廣得多，移植性也好得多。這本來是優點，但很有意思的是，正因為如此，微軟寫MFC時必須考慮最大限度減少對語言本身的改動，而把功夫下在源代碼級，以便能盡可能支持ANSI等標准，結果導致MFC的封裝復雜而不直觀。(尤其是它對消息的封裝，下文還會提到)。太多的宏定義和含義模糊且自動生成、不得改動的注釋使MFC乃至VC讓很多新手望而生畏，不敢"下水"深入學習。而Object Pascal幾乎是Inprise"專用"的，不必考慮"標准"問題，因此Inprise寫VCL時就把全部精力放在了結構與性能上，結果語言與框架的磨合程度非常好。VCL框架的結構清晰，VCL代碼的可讀性非常好。許多人說Delphi比較容易上手，也是這個緣故。天下沒有白吃的午餐。你要工業標准嗎？你要可移植性嗎(關於可移植性和兼容性，下文會詳細比較)？那麼請面對MFC的"天書"級代碼吧。

編譯和連接：The Need For Speed
不同的語言帶來的另一個不同是，編譯和連接的速度的不同，以及執行速度的不同。Delphi的編譯和連接速度，毫不誇張地說，比VC快幾十倍。即使把VC的Incremental Link選項打開，Delphi的編譯和連接速度仍比VC快好幾倍。並不是說微軟的編譯器不行，這是由C++的復雜性決定的。模板的處理、預處理和宏的展開都是很費時的。前文不是提到Object Pascal沒有模板、預處理和宏嗎？這本來是缺點，但帶來的一個好處就是編譯速度極快。至於編譯完的二進制代碼，在打開相同的優化選項的情況下，Delphi和VC執行速度並沒有太大的差別。
為了克服編譯的速度問題，C++編譯器一般需要增強的連接器和預處理機制。但是預處理機制仍然存在若干問題：1）程序調試的斷點行可能和代碼行不同；2）沒有將最新的代碼信息綜合進去；3）容易產生錯誤的邏輯；4）因為讀錯文件頭而很容易產生類似"Unexpected End of File"的錯誤。
兩個編譯器有個共同點是都能識別無用的"死"代碼，比如一個沒有用的函數等等。編譯後的程序將不包含這些多餘的信息。Delphi在這方面作得更加出色。它可以讓你在編輯器中可視化地提示出那行代碼是"活"的、那行代碼是"死"的。這樣你就能整理出最精簡的代碼。Delphi在編譯後將在左邊顯示一個小藍點表示這行代碼是"活"的。Visual C++做不到這點。
Delphi編譯後可執行文件至少有200K（如果不使用VCL，僅僅使用WinAPI，文件的大小將大大縮小）但是Visual C++編程使用MFC編譯後的可執行文件通常只有幾十K，主要是因為微軟已經將系統運行庫包含在Windows系統了（Borland公司曾經和微軟協商這個介面，但是微軟利用操作系統的優勢不願意公開）。同樣道理，使用BDE開發的的資料庫程序必須附帶3-5M的額外系統文件，也是非常不協調的。
非常有趣的是，Delphi能夠使用由C++ Builder創建的的OBJ文件，但是使用上受很大的局限性。
最後，Visual C++的編譯和連接時的錯誤信息比Delphi要詳細和具體的多。特別是使用ATL開發更加如此。

應用框架：MFC？有KFC流行嗎？
應用程序框架(Application Frame)，有時也稱為對象框架。Visual C++採用的框架是MFC。MFC不僅僅是人們通常理解的一個類庫(同樣，Delphi的VCL也不僅僅是一個控制項庫，盡管它的名字叫"可視控制項庫")。你如果選擇了MFC，也就選擇了一種程序結構，一種編程風格。MFC早在Windows 3.x的時代就出現了，那時的Visual C++還是16位的。經過這些年的不斷補充和完善，MFC已經十分成熟。但由於原型出現得比較早，MFC相比於VCL落後了一個時代。盡管微軟對MFC的更新沒有停止，我也經常讀到"只要Windows不過時，MFC就不會過時"之類觀點的文章，但就象Inprise(原Borland)的OWL框架的淡出一樣，MFC的淡出也是早晚的事。其實MFC是和OWL同一個時代的產物。OWL已經不在了，MFC怎能不"居安思危"呢？如果MFC青春永駐，微軟的開發人員也不會"私自"開發出基於ATL的WTL呀。當然，WTL的地位不能和MFC比，它並不是微軟官方支持的框架，封裝的功能也相當有限。但至少也反襯出了MFC存在的不足。
我們以為，最能體現一個應用程序框架的先進性的是它的委託模型，即對Windows消息的封裝機制。對Windows API的封裝就不用說了吧。大同小異，也沒什麼技術含量。如果高興，你也可以自己寫一個類庫來封裝。但對Windows消息驅動機制的封裝就不是那麼容易的了。最自然的封裝方式是採用虛成員函數。如果要響應某個消息就重載相應的虛函數。但出乎我的意料，MFC採用的是"古老"的宏定義方法。用宏定義方法的好處是省去了虛函數VTable的系統開銷(由於Windows的消息種類很多，開銷不算太小)。不過帶來的缺點就是映射不太直觀。對於MFC，則是"太不直觀"了。它的消息映射代碼雖然是可見的，但"勸君莫碰"。好在VC的ClassWizard可以自動生成消息映射代碼，使用起來還算方便。但和VCL的委託模型相比，MFC的映射方法就顯得太落後了。而Delphi的Object Pascal因為沒有"標准負擔"，語言引入了組件、事件處理、屬性等新特性。由於功夫做在編譯器級，生成的源代碼就顯得十分簡潔。似乎VC是"讓框架遷就語言"，而Delphi是"讓語言遷就框架"。
我想舉一個對字元串操作的封裝的例子來說明MFC和VCL的優缺點。在MFC中，CStringList類有加入、獲取、刪除等功能，但VCL的TStringList類除了上述功能還有排序、從逗號分隔的字串讀入、流輸入輸出等功能。但同樣的字元串替換功能，VCL的StringReplace要比MFC的CString::Replace慢2－3倍。總的來說，VCL的封裝比MFC更為高層，更為抽象，但不可避免地帶來的問題是某些部分執行效率比MFC略低。這就象低級語言(如匯編)的執行效率比高級語言(如Basic)高，但編程效率較低。魚和熊掌不可兼得嘛。
VCL比之MFC的另一優點是對異常處理的支持，而一大缺點是對多線程支持差。VCL的大部分都不是針對多線程優化的。雖說VCL提供了簡化多線程操作的類，但只是工作者線程(worker threads)使用起來比較簡單。如果線程要和界面打交道的話事情就變得麻煩了，因為除了應用程序的主線程，任何線程不能訪問任何可視的VCL部件。你不得不使用Synchronize方法等待主線程處理它的消息，然後在主線程中訪問VCL部件。而MFC就沒有這樣的限制。

穩定性與完善程度：VC是老大哥
VC要比Delphi穩定和完善。VC的發展歷史比Delphi長，微軟的總體實力比Inprise強。VC的框架MFC經歷了那麼多年的發展和完善，功能非常全面，而且十分穩定，bug很少。其中你可能遇到的bug也更少。而且有第三方的專門工具幫助你避開這些bug。如此規模的一個類庫，能做到這一點不容易。不要小看了這一點，很多專業程序員就是為這個選擇VC的。因為盡管VCL比MFC的抽象程度高，封裝較為高層，但由此帶來的開發效率的提高對高手來說畢竟是有限的。而如果你遇到一個怪問題，調試了半天，發現不是你的代碼有錯，而是VCL的bug，你作何感想？雖說遇到這類問題的可能性很小，但對VCL的形象的影響可不小。Delphi的IDE太占資源，啟動速度太慢，和某些顯卡驅動程序沖突，VCL中有bug，調試器不夠健壯，對不穩定的第三方控制項沒有防護措施 …… 問題多多，在這方面Delphi不如VC。希望Inprise能更上一層樓。順便說一下，我們在網上看到有些人極言Delphi的不穩定，說幾分鍾出現20多次非法操作。Delphi的確不如Visual C++穩定，但也不至於如此呀。我估計是那位朋友的Delphi裝了某些有問題的第三方控制項，導致了Delphi的頻頻出錯。不妨卸下那些控制項試試？

可移植性：立足現實，放眼未來
Inprise正在開發Delphi的Linux版本，代號為Kylix。也許通過Kylix，用VCL構架編寫的Windows程序向Linux移植成為可能。但這只是可能。因為在目前Inprise的兼容性工作做得並不好。低版本的Delphi不能使用高版本的VCL組件，而高版本的Delphi竟然不能使用低版本的VCL組件。真是豈有此理，我們很少看見軟體有不向下二進制兼容的。如果Windows 98不能運行95的程序，Windows 95不能運行3.x的程序，Win 3.x不能運行DOS程序，你還會用Windows嗎？如果Windows 95的程序必須經過重新編譯才能在98下運行，98會賣得那麼好嗎？"同門兄弟"C++Builder和Delphi也不能互相使用對方的組件，甚至同一套VCL庫的文件名也不一樣。所以一個組件有for D1/D2/D3/D4/D5/C1/C3/C4/C5這些不同版本是常有的事，而且隨著Delphi和C++Builder版本的升級可能還會增加。希望Inprise能先解決同門兄弟的兼容性問題。而微軟的VC就沒有這類問題。MFC1.0的程序也可以毫無障礙地在VC6.0下編譯通過。

集成界面：宏觀與微觀
就大處說，VC的集成界面是不如Delphi的。Delphi僅僅一個Object Inspector就可以將VC的一堆Wizards比下去，何況它還有Code Explorer、ToDo List等。但從小處，又可以看出Delphi的不成熟。比如"自動完成"功能的智能化程度和提示詳細程度不如VC，響應速度也沒有VC快。
Visual C++所帶的MSDN是一部"開發者的網路全書"，信息龐大，查詢方便，這方面比Delphi更專業。很多幫助項都有源程序示範。
Delphi的OpenTools是完全面向第三方的開放系統，開發者可以修改很多Borland公司自身的功能，從IDE的可擴充性上說Delphi更好。

調試：細微之處見真功
Visual C++和Delphi的調試功能都非常強大，同時都具有單步可視化調試、斷點跟蹤、運行時改變變數、滑鼠指向可以得到變數值等等功能。對DLL的輸入輸出也能方便的管理，能夠進行源碼級別的調試。
相對而言，Visual C++能夠更加方便地看到變數的變化情況，這包括對結構可以展開成數據樹，從而了解每一個變數的值，每一步調試，變化了的變數會加紅，從而使調試更加方便。另外，Visual C++的塊內存察看比Delphi也要方便。
當然，Delphi也有很多體貼的細微之處，比如在線程調試的時候，Delphi能夠很方便地察看線程的變化，Visual C++卻必須要彈出一個模式對話框。

資料庫開發：Delphi一枝獨秀
資料庫支持是Delphi的強項。這主要體現在Delphi與BDE的無縫集成，以及Delphi提供的那一大堆現成的資料庫操作控制項。這是VC望塵莫及的。目前Delphi支持BDE、ADO、InterBase三種資料庫訪問方式。所有的方式都能拖拉到應用程序中實現可視化操作。正是因為Delphi對資料庫類的包裝，使得用戶操作資料庫不像在Visual C++中必須從開始到最後都要干預。明顯地提高了開發速度。
Delphi中使用WebBroker控制項還能很方便地構造出基於資料庫的Web頁面，通過HTML管理Web資料庫。 Visual C++訪問數據主要通過ADO和OLEDB，很多ActiveX控制項也能添加資料庫功能。但是沒有像Paradox這樣的桌面資料庫，Access相對功能太弱了。也許SQL Server是不錯的選擇。

COM：新技術的力量
COM是組件對象模型的縮寫。它是OLE和ActiveX技術的基礎，COM定義了一組API和一個二進制標准，讓不同的編程語言、不同平台的彼此獨立的對象相互進行通訊。
COM是Microsoft制訂的行業標准。但Delphi也為COM提供了強大的語言支持。支持介面、variant、寬字元串功能。這些對COM的封裝確實比C++更方便。比如在C++（沒有類框架）進行COM編程時，變體定義為oaidl.h文件中的VARIANT結構。要處理變體，必須手工調整oleaut32.dll中VariantXXXX() API函數對其進行初始化和管理，如VariantInit()、VariantCopy()、VariantClear()等等。
Visual C++實現COM編程有一種特殊的方法就是使用ATL。ATL使用Visual C++特有的多重繼承來實現COM介面。雖然不見得實現COM服務和控制更容易，但是ATL和最新COM技術的介面，基於模板的構造都比Delphi強。ATL更有利於建立小巧、快捷的COM組件程序。
按目前通用的觀點，Visual C++應用到COM服務程序更有優勢，Delphi應用到COM組件程序更合適。

昨天，今天，明天
技術的進步在很多時候是此消彼長的。當初Borland的Turbo C和Borland C++幾乎是C/C++程序員唯一的選擇。微軟的Quick C(現在還有人知道這個產品嗎？)和Microsoft C/C++從來也沒有成為過主流。但Borland C++又流行了多少年呢？不久就被新崛起的Microsoft Visual C/C++壓下去了。於是Inprise(原Borland)揀起了當年Turbo Pascal和Borland Pascal的輝煌(事實上Borland的成名作就是第一個Pascal編譯器)，全力推出了Delphi。Delphi當初推出時被稱為VB殺手，但VB現在仍然活得挺好。畢竟微軟是靠Basic起家的嘛，VB不是那麼容易被打敗的。Inprise想了想不和VB爭了，使用Delphi的IDE和VCL配上C++語言，推出了C++Builder，又向Visual C++的市場發起了夾攻。C++Builder似乎是個不錯的折衷選擇了？再仔細想想！C++Builder的優點Delphi都有，但Delphi的優點C++Builder未必有。比如C++Builder的編譯速度比VC還慢，哪能和Delphi比？而且因為VCL是Object Pascal寫的，C++語言和VCL磨合得並不好。C++Builder的bug比Delphi還多，甚至Sample代碼中還有錯。VCL的部分功能不能使用，要靠嵌入pascal代碼訪問。C++Builder可用的第三方控制項遠沒有Delphi多。
唉，真是金無足赤。Microsoft和Inprise，誰會笑在最後呢？

魚和熊掌：艱難的選擇
選擇一個開發工具依賴於很多不同的因素，每個人都能因為某種語言的某個缺陷而放棄學習或使用這種語言。任何程序員都希望自己喜歡的工具能達到理想的境界，通過上面不完善的比較，我想大家都有自己的看法。我們認為影響大家選擇開發語言的因素主要包括：
1） 哪門語言更容易入門？
學習一種語言需要投入大量的時間和精力。開發程序的開發成本是值得考慮的現實。一個熟練的Delphi程序員和一個熟練的VC程序員工作效率是一樣的。但是，成為熟練的程序員必須很快掌握一門語言的技巧。不幸的是，目前熟練的Visual C++程序員是十里挑一。相對而言，Delphi更適合初學者。
2） 哪門語言有更多可繼承的代碼？
語言代碼的可重用性是加快開發效率明顯方面，從早期的過程、函數到現在的組件技術都是朝這個目標在奮斗。這兩種語言對代碼重用的理解是不一樣的，Delphi主要通過VCL控制項來實現代碼重用，Visual C++實現起來就比較復雜。
3） 語言自身的本性。
就技術(主要指應用框架)來說，Delphi目前領先於Visual C++。但穩定性和健壯性的不足又讓我對Inprise"想說愛你不容易"。而VC盡管發展到今日已十分完善，但MFC框架已是明日黃花了。如果不使用MFC，目前又沒有合適的替代品。根據你的需要和實際情況做選擇吧。實際上Visual C++和Delphi也不是簡單競爭關系。它們在許多領域並不重疊，甚至是互補的。到底怎樣取捨，要根據你的項目特性決定。如果你開發系統底層的東西，需要極好的兼容性和穩定性，選Visual C++吧。你可以只調用Windows的各種API，不用MFC。如果你寫傳統的Windows桌面應用程序，Visual C++的MFC框架是"正統"的選擇；如果界面部分佔這個應用程序代碼比例較大的話，或者Delphi中有相關功能的控制項的話，Delphi是事半功倍的選擇。如果你為企業開發資料庫、信息管理系統等高層應用("高層"是相對於"低層/底層"而言的，不是說技術高級或低級)，而且有比較緊的期限限制，選Delphi比較好。如果你熟悉的語言是Object Pascal，又不打算學復雜的C++，那麼Delphi幾乎是唯一的選擇。傳統的觀點是：Delphi適合編寫Internet/Intranet、表格制圖、資料庫操作、高級用戶界面等等。Visual C++適合編寫設備驅動、COM服務程序、科學計算、控制台（console）程序、WinCE的應用和一些小的工具等等。應用范圍的不同要求好的程序員同時精通這兩門語言。
4） 語言的前景和可擴充性。
Delphi是Inprise的旗艦產品之一，前景應當還是比較樂觀的，而且Inprise已經在向Linux進軍了，而微軟還遲遲沒有動作。遺憾的是，Inprise公司Delphi的創始人已經跳槽到微軟去主持Visual J++和C#項目了。但願對Inprise沖擊不會太大。
微軟的Visual C++的前景又怎樣呢？Visual Studio 7.0就要推出了。這一版本將加強網路開發的特性。看來微軟雖然被判解體，開發實力可是一點沒打折扣。
另外，雖說MFC已稍顯落後，但不是說它不值得學。事實上，不學MFC就等於沒學VC。利用MFC框架開發程序仍然是目前開發桌面應用的主流模式，而且還會保持相當長的時間。微軟公司CEO史蒂夫·巴爾默(Steve Ballmer)曾說，.NET流行還得等2－3年。那麼，MFC至少還有2－3年的生命空間。在技術日新月異的IT界，2－3年實在是很長一段時間了。好好把握吧。即使你不使用MFC框架，花點時間看一下MFC的封裝機制對你熟悉C++的OOP機制和Windows底層功能也是很有好處的。而VCL的源代碼是Object Pascal的，對C/C++程序員就沒有這個"額外"的作用了。