C++ MFC 與 .NET？

Question

我的同事正在使用 Visual Studio 2002 並使用 C++ MFC。 我正在用 C# 開發。

之前沒出過什么問題，但是現在質疑我們的客戶是否真的應該在不同的環境中開發。 我的同事認為（當然）我應該轉向 C++ MFC。 我認為他們可以使用 .NET 而不是 MFC。

學習MFC有什么意義嗎？ 感覺有點過時了，還是我錯了？ 與 MFC 相比，反對和支持 .NET 的論據是什么？

編輯：

我們正在為核工業開發過程系統和輔助應用程序。 主要應用程序是一個仿真器，它模擬舊計算機系統並使用 C++/MFC。 這是非常關鍵的，也許核心應該仍然是原生 C++。 但是模擬器和所有周圍應用程序的 GUI 並不是特別重要。

是否有任何真正的理由應該替換現有的 MFC 應用程序？

Answer 1

我已經廣泛使用 MFC 和 Windows 窗體很長時間了。 我來自視頻游戲行業，因此多年來不得不編寫許多桌面應用程序，在 .net 之前，MFC 非常有用。 甚至在此之前，我都是在純 Win32 中編寫工具。

MFC 肯定有它的怪癖，但總的來說它讓生活變得更輕松。 將 OpenGL 和 Direct3D 集成到自定義視圖中非常容易，一旦掌握了它，編寫自定義控件就是小菜一碟。 最重要的是，我可以用純 C++ 編寫代碼，這恰好是我選擇的語言。 另外，我發現 MFC 非常高效和活潑。

漸漸地，MFC 開始獲得外部控件庫支持，尤其是停靠/工具欄庫，所以我的工具，如 3D 模型查看器和關卡編輯器，看起來都非常可愛。

我編寫的大多數應用程序都以編程方式創建了 UI，因此對話框/窗口布局工具足以滿足我的需求。

MFC 9 也很酷，尤其是 Microsoft 作為 Feature Pack 的一部分發布的 Ribbon control/docking 庫。 所以老狗還有生命，這是肯定的！ :)

當 .net 1.0 出現時，我發現轉換相當容易，因為它支持托管 C++。 它並不漂亮，但為 .net 框架提供了一個相對簡單的入口。 但是當我開始編寫更需要 Windows 窗體設計器的工具時，我的轉折點就出現了，大約在 .net 2.0 時代。 我決定重新開始並學習我喜歡的 C# - 盡管我永遠不會習慣沒有 delete() ;) 的 new() 。 然后我開始編寫用戶控件，發現整個體驗非常好和簡單。 .net 框架是巨大的，得到了​​很好的支持，而且通常我發現在 C#/.net 中做幾乎所有事情都更容易。 此外，編譯速度快如閃電，而且在 Visual Studio 中重構的能力非常棒。

c#/.net 的美妙之處在於它並不僅限於編寫托管代碼。 如果性能是一個問題，或者如果您需要在平台之間共享代碼，您仍然可以使用非托管代碼。 例如，我的數學庫是用 C/C++ 編寫的，我將其放入一個庫中，使 C# 能夠包裝/使用相同的代碼，盡管這只是暫時的。 我也將及時將這些庫移植到 C#，因此一切都是純 .net。

我想提的最后一個經驗是，過去幾個月我一直在遠離主機游戲編程，而是花時間為 InterWeb 編程。 我一直在使用 Microsoft 堆棧，在 ASP.net/C# 中編程，我不得不說它非常好，所有 C# 知識都直接適用。 唯一的學習曲線是 ASP.net，而不是語言和支持庫。 隨着 .net 3.5（LINQ 是甜蜜的）的到來，C# 的 .net 框架中的生活很可愛。

無論如何，我不想把它變成我的生活故事，但我只想簡要介紹一個已經通過您所詢問的所有技術的人的經歷。 我還想提一下，嘗試不同的語言/框架對您有好處。 我已經為 iPhone 編寫代碼一年了，並且已經變得非常喜歡 Objective-C。 都是編程，一切都很好。

關於 MFC/.net，兩者都有其優點和缺點，我真的不介意 MFC，但就前進而言，我可能會堅持使用 C#/.net，但是拜托，拜托，拜托了解它是如何工作的。 我要說的唯一說教是了解 .net 中的內存是如何工作的，即使“一切都為您處理好了”；)

你對 C/C++ 的了解應該完全獨立於你是否使用 MFC，它仍然是一種關鍵語言（尤其是在基於控制台的視頻游戲編程中），但對於 Windows 上的桌面應用程序編程，它越來越難以反駁。網。 它快速、簡單、有很好的工具支持、優秀的 3rd 方庫、一個龐大的成長社區、現在是跨平台 (Mono) 並且將使您能夠在所有當前/新興的 Microsoft 技術（ASP.net、WPF、Silverlight、WCF）之間移動等等）。

盡管如此，我仍然將 Visual Studio 設置為 C++ 環境。 有些習慣永遠不會消失;)

Answer 2

MFC 和 .NET 幾乎處於相反的極端，每個都以自己的方式徹底蹩腳。

使用 MFC 大致相當於生活在二戰剩余建築的腐爛殘骸中。 沒有任何警告危險區域的跡象，並且可能不會立即清楚在哪里可以找到自來水、電或可用的廁所——即使它們都在那里，如果你知道如何找到它們。 像任何腐朽的建築物一樣，牆壁上有很多洞等等，因此您可以隨時離開。 同樣，從外部世界中拖入事物也很容易，盡管您可以通過“拖拽”來實現它。

使用 .NET 就像生活在杜魯門秀的片場。 它符合人們對現實生活應該是什么樣子的看法。 在它的邊界內，生活似乎是烏托邦式的。 然而，歸根結底，它只不過是一個裝飾精美的牢房，它所描繪的生活都不是真實的。 你與外界的所有互動都受制於一位主要目的是提高自己收視率的導演的心血來潮； 你的福利只在影響他的范圍內被考慮。

與大多數監獄不同，.NET 確實有一個標記清晰的逃生路線（標記為“P/Invoke”）。 然而，就像任何好監獄的逃生路線一樣，這是一條一英里長的污水管道。 大多數居民都知道它的存在，但幾乎唯一去那里的是青少年證明了他們的男子氣概。 真正使用它的少數人只是在迫不得已時才這樣做。 我們中那些經常覺得有必要的人已經意識到最好呆在外面而不是回去。

編輯：由於有些人希望圓圈和箭頭以及每個圓圈和箭頭的背面都用作法庭上的證據：MFC 的優勢和劣勢在於它主要是圍繞 API 的相當薄的包裝。 這是一個弱點，因為它的覆蓋范圍有相當多的漏洞，並且因為它在“平滑”API 本身不能特別好地組合在一起的地方方面做得相對較少。 例如，如果某些東西是使用 COM 實現的，那通常會直接顯示在使用它的代碼中。 這是一個優勢，因為擴展 MFC 以處理默認情況下不處理的區域相當容易，並且在需要時可以簡單地繞過它並直接使用 API。 它的更新頻率也相對較低，因此雖然它目前可以生成外觀相當“現代”的應用程序，但情況並非總是如此。 鑒於它的歷史，很難預測它會繼續如此。

.NET 的優勢和劣勢在於它是圍繞 API 的“更厚”的包裝器。 “平滑”API 中的差異要做得更多，因此（例如）在 COM 中實現的部分與作為直接 C 函數調用實現的部分看起來/行為沒有明顯不同。 在 .NET 內部，差異消失了。 .NET 是（目前）Microsoft 最喜歡的技術，因此它更新得更頻繁，並且在確保您的 UI 遵循最新指南方面做得更好。 我的猜測是它比 MFC 更有可能繼續這樣做一段時間。

.NET 的弱點是繞過或擴展要困難得多。 基本上，您通往外部世界的唯一途徑是通過 P/Invoke。 即使是短途旅行，也是丑陋而痛苦的。 嘗試經常使用它或用於任何接近主要擴展的東西是受虐狂的練習。

如果（幾乎）您編寫的所有內容都適合 .NET 支持的內容，那么這是一個明確的選擇。 只要您保持在其邊界內，它就會更干凈、更順暢。

如果您編寫的代碼經常需要超出框架支持的范圍，那么 MFC 可能會更好地為您工作。 使用 .NET，.NET 模型適用於您的整個程序。 使用 MFC，編寫將 MFC 用於 UI 的程序相對容易，並且可以隨心所欲地處理 MFC 不支持的其他任何事情。

Answer 3

我認為了解 C++ 是有價值的，因為該語言將存在很長時間。 您永遠不知道什么時候可能需要使用 C++ 編程，而在當今的就業市場中，掌握更多語言只會增強您的簡歷。

至於MFC ，我正在盡力擺脫它。 它的計算標准已經過時（我認為接近 20 年），但 Microsoft 仍然看到通過新版本和功能包支持它的價值。 從這個角度來看，我懷疑 MFC 會很快消失。 但這並不意味着我想用它編程。 一周中的每一天，C# 編程的流暢性和易用性都讓 MFC/C++ 大吃一驚。 線程、套接字、字符串操作等 - 所有這些事情在 C# 中比在 C++ 中更容易完成。 另外，C#/.NET 是 Microsoft 的主要技術重點，在職業發展方面，我寧願處於這一邊緣而不是 MFC。

Answer 4

這不是一個對另一個。 從 1.1 版開始，Windows 窗體支持由本機客戶端（如 IE 或 MFC 對話框）托管。 MFC 8.0 在其 Windows 窗體支持類中封裝了必要的托管代碼，因此您無需編寫自己的代碼。 根據您當前項目的要求選擇正確的庫。

然而，MFC 不僅僅是它的 GDI 包裝類。 曾經，它被設計為底層 Win32 API 的 OOP 替代品，與今天的 .Net 非常相似。 然而，MFC 並沒有阻止 Win32 API 的增長，現在我可以說 Win32 API 的增長超出了 MFC 的支持范圍。 API 的數量在過去十年中增加了數十倍。

另一方面，Windows Forms 旨在替代 Windows 的 GDI 系統。 .NET Framework 庫的其余部分旨在替換 Win32 的其余部分，例如用於 DirectX 的 WPF 和 XNA 和用於 SAPI 的 System.Speech。 但是，我可以看到 win32 API 的增長超出了 .Net 可以在幾年內沒有顯着增加下載大小的情況。

因此，Windows 窗體不能做 MFC 能做的所有事情，它旨在使基於 GDI+ 的 RAD 更容易，並且可能包括 MFC 不能做的事情。 然而，隨着微軟重新關注 WPF，基於 GDI+ 的 Windows 窗體正在走下坡路，而 MFC 則根據消費者的要求復興。 如果您正在為未來的應用程序設計，您可能需要考慮到這一點。

Answer 5

您要解決的問題是什么？ 假設您同樣了解 C++/MFC 和 C#/.NET。 哪個工具集可以讓您更好地構建和維護？ （更好是主觀的，但這同樣取決於您的目標）

除非我使用 .NET 中不可用的本機 API 進行大量工作，否則到目前為止我將使用 .NET。 C++ 是一種很棒的語言，沒有什么可以阻止您使用托管 C++ 進行編碼以保持 .NET 框架和內存管理。

相比之下，我的觀察是，與 .NET Windows 窗體相比，MFC 框架非常笨拙且笨拙。

Answer 6

MFC 提供的一項很好的功能是文檔/視圖框架（單個文檔或多個文檔），它在 .NET 中尚不具有等效性。 當您需要創建像 Microsoft 的 Word 一樣工作的應用程序時，此功能非常有用和方便。 它有助於將數據模型與您想要呈現給用戶的視圖分開。 我認為一旦實現了這個功能，大多數人都會跳到 .NET 方面。 （微軟是否正在為此努力，或者至少有計划在這方面開展工作？）

Answer 7

這個選擇有很多優點/缺點。 MFC 是舊的備用設備，它已經存在了很長時間並且確實顯示了它的年齡。 另一方面，它仍然得到很好的支持，MS 不斷更新它以保持最新狀態。

.Net 框架有更好的支持，因為它有一個更大的團隊支持它，並且被視為構建 Windows 新部分的東西。

另一方面，MFC 是 Windows 生態系統的重要組成部分。 如果您在該平台上編程，那么當您最終支持 MFC 應用程序時，至少了解 MFC 的作用以及如何工作是值得的（別擔心，總有一天你會）對從哪里開始有一個良好的基礎。

Answer 8

一年多前，我從 C++/MFC 過渡到 C#/WinForms（大器晚成，我知道 ;)）。

撇開語言差異不談，從 MFC 過渡到 WinForms 要比其他方式容易得多。 如果您打算有效地維護遺留應用程序，我認為了解 MFC 絕對有價值。 然而：

我會從頭開始學習 MFC（考慮到現有技術）嗎？ 不，可能不是。
我會在 MFC 中編寫新的應用程序嗎？ 不，可能不是。

.NET 的支持、靈活性和易用性遠遠超過了 MFC 的優勢。 就其本身而言，MFC 非常棒，我很感激有機會使用它——它教會了我很多。 但最終，它正在走出去。

Answer 9

天啊。 我知道我參加這個派對已經很晚了，但作為一個用 C 和純 Win32 編寫的人，然后他的大部分職業生涯都是在 C++/VC/MFC 上，用 C# 和 WPF 編寫是一種痛苦！！ 我知道我是新手，但我強迫自己用 C# 編寫這個小應用程序，因為我想更適應 C#/.NET 和 WPF。 雖然很高興我能夠輕松地使 UI 成為光滑的黑色，但我需要花費時間來定義菜單，當在 MFC 中時，我會創建菜單資源，添加菜單項，然后添加事件處理程序到他們輕松！ 這是苦差事。 我喜歡 C# 作為一門語言，但如果我能像在 MFC/Windows 的資源編輯器中一樣定義一切，並添加像 WPF 那樣使 UI 元素變得活潑的能力，我會更喜歡它。

Answer 10

非托管代碼不一定執行得更快，這取決於編寫的代碼以及編寫代碼的人。 我讀過一些復雜的基准測試報告（源代碼、代碼項目），C# 在某些方面勝過 C++，C++ 在其他方面勝出。 這取決於您的領域：我為飛行模擬器編寫軟件，因此需要一個非托管環境。 如果您正在制作 GUI 應用程序，C# 可能是更好的選擇。 對於低級別套接字編程，C++ 可能會返回更好的結果。 我注意到在正常操作中 C++ 和 C# 之間沒有嚴重的速度差異，但我喜歡 C++ 的本機可移植性和 C# 的易用性。

Answer 11

.NET 使用托管代碼。 MFC 使用非托管代碼。 我讀過非托管代碼的執行速度比托管代碼快。 因此，如果您正在開發軟實時代碼，您可能希望使用非托管代碼。