怎麼理解API和MFC的關係?

12-26

直接用API寫界面，能不能只用C不用C++。
另外簡要介紹一下C#

API：應用程序介面

MFC：沒飯吃

你要是非c語言不可，可以試試gtk

win32API是兼容C和C++的，你可以試試

API是一個抽象層，比如從軟盤到硬碟到移動存儲到網路共享，從PS/2滑鼠到USB滑鼠，從印表機到顯卡的繪圖，微軟的抽象讓你可以用同一個API來訪問不同的硬體，由負責Windows兼容性的硬體廠家和微軟來保證這些API在各種環境中的行為保持一致。微軟在設計新的操作系統版本和新的硬體支持的時候，會努力讓這些Windows API仍舊可以繼續工作。為了最大程度兼容各種語言，Windows的API通常都是提供一個C介面，但是也有提供COM、腳本語言和WMI介面的。

MFC和.Net框架是更高級別的抽象層，將API組成各種現成的模塊供以滿足常見的任務。但是下載體積到現在仍舊是個問題，做大而全的封裝類庫並不現實。Net框架雖然有好幾十兆，也僅僅把不用API寫簡單程序搞成了有可能性而已，畢竟不是所有開發任務都只限於常見任務。對於Windows整體來說，.Net框架的API封裝率還是非常地低，看看pinvoke.net: the interop wiki!就知道了。當然，需要支持舊版本的Windows而導致無法封裝新的API也是它們覆蓋率低一個原因。

理論上來說，會彙編語言的人可以寫出所有程序，也可以只用C和Windows API來寫界面，但是實際上除了短小的程序，沒人會這麼自討苦吃，用簡單好學流行的類庫就可以搞定的東西，老闆沒強烈的理由不會花冤枉錢讓你自己從頭造輪子。但是簡單好學流行的類庫會用的人多，如果你不擴展自己的知識面，無法做簡單工作之外的事情的話，也會有讓你容易被要價更低的程序員取代的危險。

至於C#、C、C++之類的語言標準，就是大家寫翻譯源代碼的編譯器時都同意遵循的守則而已，沒有具體功能可言。比如你給晶元寫程序的話，雖然可以用C/C++/C#，但是晶元上既然連Windows都沒有，就不要指望有任何Windows API和基於Windows的類庫來幫你了。

API說的是windows API，也就是操作系統相關的，和語言無關，每種語言都可以調用。不過由於是C寫的，函數和數據類型都是用C的定義的，所以一些比較高級的語言調用起來會比較麻煩。

MFC是windows的一套開發框架，基於c++，裡面不僅包裝了圖形界面相關的API，還提供了許多可以讓windows開發變得更方便的類。

windows的API都是C定義的，當然可以直接用C來寫，不過不用框架就會稍微繁瑣一些罷了（說起來編程語言也都是圖靈等價的，一個東西可以用任何語言實現，只是繁瑣程度不同罷了）。
C#介紹請自行百度。

只用windows api是可以寫界面的
如果我沒記錯的話，C++的一些特性不是必須的，用C和struct應該是可以的
但是直接用api會很痛苦
所以M$提供了MFC
MFC的缺點是包裝的太重了，而且代碼的依賴性（對CObject以及消息映射）很強
所以後來又推出ATL什麼的，輕型一點的

「交通工具」和「泰坦尼克號」的關係。

理論上說 MFC 是對 Windows API 的封裝。但 MFC 封裝得非常漏（不是 Low，是 Leaky），以至於很多問題在 MFC 層面上沒法直接解決，不得不跑回去用 Windows API。

而 Windows API 是……一種 Windows 提供的 API……

Windows api 是操作系統開發給開發者的介面(C介面)，MFC是MicroSoft Foundation Class，是微軟開發的基礎類庫，也能說是一個開發框架，應該快淘汰了

個人覺得sdk比mfc更容易理解。只是麻煩很多。