C#與VC++在桌面軟體的開發比較?
看見知乎上的用戶普遍對VC++開發桌面應用軟體各種吐槽。大力宣揚C#的優點和好處。
但是本人在網上搜索發現在桌面開發還是招聘VC++的多。使用PEiD查殼發現，著名的商業軟體大部分都是VC++開發的，比如說QQ，酷狗音樂盒等等。雖然很多人吐槽VC++使用原生控制項開發界面丑，但是現在這麼多好看的界面庫，如Direct UI等等。總感覺C#調用Windows API不是很方便。比如使用MCI介面開發音樂播放程序，需要一大堆常量聲明，如下所示：
public const uint MM_MCINOTIFY = 0x3B9;public const uint MCI_NOTIFY_SUCCESSFUL = 0x0001;
public const uint MCI_NOTIFY_SUPERSEDED = 0x0002;
public const uint MCI_NOTIFY_ABORTED = 0x0004;
public const uint MCI_NOTIFY_FAILURE = 0x0008;public const uint MCI_OPEN = 0x0803;
public const uint MCI_CLOSE = 0x0804;
public const uint MCI_PLAY = 0x0806;
public const uint MCI_SEEK = 0x0807;
public const uint MCI_STOP = 0x0808;
public const uint MCI_PAUSE = 0x0809;
public const uint MCI_RECORD = 0x080F;
public const uint MCI_RESUME = 0x0855;
public const uint MCI_SAVE = 0x0813;
public const uint MCI_LOAD = 0x0850;
public const uint MCI_STATUS = 0x0814;
然而使用VC++不用這麼麻煩，不用寫這麼多變數聲明。直接用mciSendCommand(NULL,MCI_OPEN,0,0);
不用聲明 MCI_OPEN這個常量的數值。請程序大神們，給我說說是不是C#在桌面開發不是很方便，特別是要調用Windows API?
大多簡單的桌面軟體不需要或者很少需要直接調用native api，就算要調用你也可以妥善地封裝起來，而且這些interop的聲明都有現成的網站給你複製粘貼的。
總體開發效率還是C#要高，學習成本低，特別是對於不需要酷炫特效的企業業務類軟體。
以前WPF啟動性能是個大問題，現在也好多了。C++對比C#最主要的問題是開發慢，新員工從什麼都不懂到上手要很長時間。但是這都擋不住公司里這方面的高手多。語言都是為了實現目標而服務的，具體選擇只有合適不合適你公司現有的情況，沒有對不對。樓主說的好多商業軟體包括QQ, 最開始的開發都是在C#出現之前開始開發或者發布的。微軟剛推出C#的時候，WinForm作為UI庫，只是在已有的CommonControl(MFC用的那種)上封裝一層Managed API(如果你用Reflector看WinForm的代碼，就能看到最後render的時候，都是直接調CommonControl API)，所以完全沒有必要用C#重新寫。後來微軟推出WPF的時候(WPF整個UI/Render是全部重寫的，跟之前的Common Control沒有任何聯繫)，有碰到Vista的失敗，而且對於大量的XP用戶，需要額外安裝.Net Framework，再加上性能的問題，所以導致公司升級慾望也不大。另外，我知道很多公司包括Yahoo, Adobe, AutoDesk內部都有組試圖用WPF重寫它們的核心產品，但是最後能發布的應該寥寥無幾，性能，沒有足夠多的人熟悉這門語言，移動互聯網，市場的變化應該都是導致這個結果的因素。最後，一般對於大型產品，很少能重新寫，更多的是在已有的東西上面修修補補，重新寫並能陳宮的屈指可數。
qt被你扔到哪裡去了？
覺得mfc難看，幹嘛不自己覆寫OnPaint拿gdi+重新畫？添加個私貨，相信比你用 WinAPI 簡單，更強大。
音頻播放：xZune.Bass
Bass 音頻庫的 .Net 封裝實現，WIP 狀態，但是已經可以用了。https://github.com/higankanshi/xZune.Bass視頻播放：xZune.VlcLibVlc 的 .Net 封裝實現。https://github.com/higankanshi/xZune.Vlc不會有人因為多打幾個字就不用一門語言的，不然C語言早就拜拜了。就算在VB那個年代，你要調用一個Windows API，你也得自己去寫這些東西。但是這並不妨礙那個時候VB是最火的語言。而且事實上那些有用的Windows API，你去MSDN上看，評論裡面都有人給C#和http://VB.NET寫好了這些東西，你複製就行了。新的使用COM介面的Windows API就更簡單了，你直接從IDL文件import進來就好了。
至於為什麼用C++？主要原因是，能跑在XP SP0上的那個WPF特別爛。等XP什麼時候真正死掉了，.net開發GUI的最後一個缺點也沒有了。如果都是熟練團隊，且在c#和vc++設計能力範圍內的開發，那麼可以說便利程度差不多的，一輛是28寸「老坦克」，一輛是可變速捷安特，習慣了騎著都不錯。
以下開始跑題：
本來沒什麼想回答的，只是樓主的問題本身包含了一個邏輯：
知乎上褒c#貶vc++，找工作時候vc++還是挺多，所以技術上到底是vc++使用方便還是c#使用方便？決定多說兩句。我覺得這是一個搞技術的人在開始階段比較容易走的一個誤區：唯技術決定論——我所看到的一切都是因為技術的原因造成的：技術牛X所以大家誇他、技術上便捷所以用的人多——這是一個假象。首先，除了技術還有屁股，不廢話了，當然屁股也不是唯一的決定因素。
對於一個公司來說，開發一個商業軟體，要考慮的因素絕不僅僅是語言本身的好壞。即使不考慮老闆、員工的好惡，從客觀條件來講，還必須考慮：- 已有用戶的習慣繼承。還別笑，有些用戶就是已經用習慣土功能了，你要來個全新的平面化設計有些客戶要罵娘的。
- 已有項目的維護髮展。很多項目用VC++啟動的時候，C#還不知道在哪裡呢。
- 歷史經驗的積累。重用一些早就做好的輪子，能極大降低開發的成本和風險。如果有誰知道ffmpeg的c#實現請告訴我。
- 開發團隊的開發效率。越是新的技術開發效率越高是真的，但是團隊已經習慣於某種技術很長一段時間了，直接切換到某個的確是更高效率的開發工具上，不見得馬上就能獲得更高的開發效率。
- 市場上開發人員的技能。即便一個開發技能再牛掰、效率再高效，市場上的人才儲備不足的話，也是不宜馬上使用的。沒有草吃進來，哪裡擠得出奶。
- 技術的文檔資料和社區支持。有些技術看著挺潮流，但是任何一個新興技術開始發展起來的時候，社區什麼都可能不成熟，新技術死掉、邊緣化的可能性比成熟技術大多了。silverlight還有多少人在用？
我公司目前為止應該開發過上千個Windows桌面軟體了，平均每一個的代碼量在1000-10000之間（不算VS自己生成的代碼）。對了你猜對了，就是做項目的開發的軟體，小軟體，解決特定的客戶需求。我公司全部用的C#，同行裡面也有用http://VB.net或者C++的。
C# 問題在於冷啟動時間以及固態硬碟太貴了
作為一個使用過Win32, MFC, Winform和WPF的PC客戶端開發老程序員, 談談我的了解。
首先C++做GUI基本不是一個很好的選擇, 開發效率太低，除非你需要跨平台。就是用Xamarin.Forms或者Html5都比C++好。不過很多時候，技術的選擇不是由於哪種技術好與不好，而是很多因素的共同作用，比如歷史原因，現有團隊的經驗，招人成本之類的。
Autodesk的很多核心產品包括AutoCAD, Inventor, Revit等以前都使用MFC來做UI, 大概10年前就都陸續遷移到WPF做的Ribbon界面。核心代碼還是C++, 用C++/CLI來做膠水。很多金融IT內部軟體基本都是用C#來開發客戶端, 原來很多用Winform或者Silverlight的應用，也逐漸在向WPF遷移。
很多行業，比如儀器，醫療，石油和船舶等行業專業軟體也基本用Winform或者WPF來開發軟體。隨著PC客戶端的需求萎縮, 不管是VC++還是WPF的份額都會越來越小。相比之下VC++的開發效率更加低, 運行效率的優勢隨硬體進步逐漸消失，程序員也更加難找。起碼學XAML/WPF的將來找份糊口的工作會稍稍容易一點。你可以調用系統api的用c++，界面用c#，混合編程嘛，我感覺c#寫gui至少比mfc要自然些，而且wpf還比較靠近前沿的界面寫法。c#寫得gui，我覺得還是太耗內存了點。。。。。。大概uwp才是真正出路吧
你說得 這叫 Wapper(封裝) 或者叫 binding(綁定) 這兩種說法基本上是同一個意思。
即 對於 一般性的 C語言(包括C++)的頭文件 的一種翻譯，當然 除了頭文件之外還有 對靜態庫之類的封裝(綁定)，原因就是因為你所使用的語言的編譯器不支持直接引用 頭文件。
這在很多時候是非常不方便的。
這裡只以 Windows 平台作為例子 除了頭文件 還有靜態庫 本地動態庫 com 等等。
由於很多時候 C#語言是個託管語言的原因，所以受到很多限制。
你不能直接調用 win32 api,不能直接引用操作系統sdk中的 .h 後綴的頭文件，不能直接引用動態鏈接庫，也不能直接引用靜態庫 等等
基本上除了 C++ 之外 大部分 語言都要經歷的過程
然而這就產生了一個問題。
作為大公司來說他們覺得自己使用C#這種語言開發應用的話 太繞彎彎了，不能直接和操作系統進行交流的感覺 就好像 你不會英語需要帶個私人翻譯。這是一件多麼讓人心煩的事情？
總結這個缺陷我們稱之為：對操作系統或者本地代碼 或者C/C++ 語言 之間的互操作不夠友好！
雖然C#確實不錯 但是這一點 我也一直不太喜歡。
而且我也始終覺得這是限制C#發展的重要原因之一。
其次：大公司不使用C#的原因還有。讓自己開發的程序跑在 .net 上真是很不放心。
打個比方 即使 C# 有 PInvoke之類的平台調用技術，也可以寫Windows Hook 但是一般只能寫普通的窗口Hook 但是要寫別的就不行了。像QQ這種軟體 安全性非常重要。因此用C++開發幾乎是必然。 因為C++可以寫 QQ 進程保護之類的東西，然而 C#寫不出 或者很難寫出。或者即使寫出來了，自己也很可能被反編譯（C#寫的程序 如果不做處理目前為止 網上很容易下載到反編譯軟體 基本上90%以上還原你們的源代碼，你的心血或者 關鍵信息就完全泄漏）了，談何安全？由於.net 編譯上安全問題， 什麼VM保護，混淆，基本上都是渣！ 然而 C++編譯後是 二進位的 彙編，相對來說 安全不少。而且C++對操作系統的功能訪問非常友好，所以更加安全，可以實現更底層的安全機制保護程序。
除了這些.net framework 本身也是個問題。太大太臃腫，缺乏擴展性等問題。
寫到這
有空，再更新。。。
針對 C#的 這些 缺陷 其實 目前已經有不少語言 開始 嘗試解決。比如 go(可以再注釋裡面引用頭文件 當然go還不算太智能) ，又比如Nim，Swift 等等
謝邀，C#本來就不建議直接調用系統API。當然也有辦法去使用，無非就是聲明一下而已。不算特別麻煩，只不過C++ 里已經有了頭文件，而C#沒有，它本來是基於.net 編程的。像播放媒體、Winsocket、串口通訊等等功能本來.net自帶，用起來更方便，何苦自討苦吃？
另外，有兩種情況不應該選擇C#，第一，需要極度壓榨機器性能的輪子，而你有能力的話，當然是選擇C++，而不應該選擇其他。
第二，原來的C++程序，在沒有必要情況下，也不應該選擇C#。必要情況是指，會有很多需求改變，有開發進度需求，或者原來程序寫得普通，需要性能優化，又不想造太多輪子。
下面再說說，QQ轉移用WPF碰到的問題，首先，他們是基於對C++高度熟練之下，遷移到一個自己陌生的WPF環境下開發，其次，因為是早已商業化，有用戶壓力，他們試圖複製一個，不說完全一樣，也可以說是差不多90%功能一致軟體——這是很難的。
因為C++ + winsdk是可以靈活做輪子的，而C#+WPF是基於有限變化模式的。完全對等起來就要做很多額外的工作。就如你原來用C++給用戶設定了3隊玩一個足球的遊戲，而你想用WPF弄出來，對不起，它默認給你兩隊的。搞起3隊來就繞很多了。
我們換個角度想一下，如果我們一開始為用戶弄正常的足球賽，就比用C++簡單多了，而且其實3隊人踢足球不是個剛需。只是為了搞搞新花樣，完全可以用別的遊戲代替。但是現在不同了，用戶已經付錢，被迫成為成為剛需了。
新開項目時候，我們應該想的，往往不是兩個方案之間的性能區別（畢竟即使你選了C#，還是可以調用C++的輪子），而是你需要做多少奇葩的設定，有沒有讓這些設定困住自己。C#是一門高級語言，而VC++是一個開發工具，性質不同，拿來直接比較不是很合適。
如果要對比的話，應該拿C#和C++作對比。在桌面開發的範圍內，那主要是WPF/Windows Forms和QT之間的對比。還有一些桌面開法經常要用到的基礎類庫的對比，例如是C#方面的Entity Framework、System.Net.Sockets、System.XML(.Linq)、http://Json.Net……，對應C++/QT方面是QxOrm、QTcpSocket、QXmlReader、QJsonObject……並不需要比較，在通用的qq類軟體是不可能上.net的，而且這些公司招c草草的人就是寫界面的。
招c++是讓他們做核心邏輯，也就是沒有現成的.net庫可用或者對效率要求極高的部分，並不是讓他們去寫界面的。
如果目標是世界最強的某類桌面應用，追求可能做到的最優值，不記成本，肯定是c++，否則都是c#
為撒不用qt？
你見到的只是面向消費者的通用軟體，比如QQ，這種類型的客戶端軟體其實只是少數，大量的行業軟體，企業應用，用.net開發客戶端，因為用C#實現業務邏輯比C++的開發效率高多了，技術上的坑也少很多。這樣的軟體，你沒有身處那個行業你是見不到的
我來說下各種用C#做桌面程序（C/S）的：1、醫療行業的各種業務系統的（比如HIS系統，掛個號、出個病歷）2、金融行業的各種前端和外圍系統，比如某些核心對應的前端（櫃員等系統）、ATM和其他自助設備，報表系統（特別是給人行和銀監的）等3、進銷存、OA、財務、收銀等企業內部的CS系統，比如常見的某些超市的收銀系統.......想到再補充。
c# 方便，但同時限制很多，動不動就要託管，感覺繞來繞去；vc++複雜一些，但自由度高，想怎麼玩都行。
前些天答主要寫個測試程序，每10ms發個udp包，看丟包率怎麼樣。vc++極其簡單，要用c#的話，.net自帶的timer那叫一個渣。總結C#受.net拖累太多，.net用起來很爽但性能不行，尤其是實時性太差，響應時間不能忍。如果有API能把代碼插入到硬體中斷就爽了，
單純看語言特性，我還是挺喜歡c#的，用著很舒服推薦閱讀：
※一行 JS (以分號結束)能實現什麼喪心病狂的功能？
※Matlab求一個矩陣中所有元素的平方和，兩種循環寫法為什麼性能相差很大？
※C 語言指針的指針和二維數組的區別?
※如何生成rest api文檔？
※零基礎學習python需要直接使用linux嗎？