學習C++能幫助我以良好的速度構建本地應用程序嗎？它能幫助我成爲一名程序員嗎？還有什麼其他的好處？學習C++幫助構建快速/無需額外需求的桌面應用程序？
我想學習C++的原因是因爲我對構建在JVM和.NET之上的應用程序的UI性能感到失望。他們感覺緩慢，並開始緩慢。當然，一個非常糟糕的程序員也可以使用C++創建一個速度較慢且緩慢的應用程序，但我沒有考慮這種情況。
我最喜歡的Windows實用程序應用程序之一是Launchy。在Readme.pdf文件中，程序的作者寫道：
0.6這是第一個C++版本。由於我對C＃的大 .NET框架的要求感到沮喪，並且用戶 缺乏安裝它的慾望，所以我 決定切換回更快的 語言。
我完全同意Launchy的作者關於.NET框架的要求，甚至是桌面應用程序的JRE要求。更不用說它們的特定版本。一些最好的和我最喜歡的桌面應用程序不需要運行.NET或Java。他們只是在安裝後運行。它們大多是用C++構建的嗎？ C++是基於GUI的應用程序的唯一選擇嗎？
而且，我對學習C++的其他好處也很感興趣。
如果你想建立一個將沒有框架，例如.NET或虛擬機/口譯運行Windows應用程序，那麼你唯一的真正可行的選擇將是Visual Basic或C/C++
我寫一些使用C++代碼的小型Windows應用程序，在速度和部署方便性方面肯定會有好處，但這會以犧牲開發難度爲代價。 C++可以非常快速，本地編譯，具有許多現代語言功能以及廣泛的支持。這種折衷是，你可能需要在某些情況下編寫更多的代碼，或者尋找像Boost這樣的庫，它們提供了你所追求的功能。
作爲一名程序員，在C++中工作，特別是在C語言中，對於幫助您理解離機器更近的東西（比如說.NET，Java或VBScript，Python，Perl等腳本語言）來說是一種很好的體驗。不一定會讓你成爲一個更好的程序員，但如果你願意從中學習新的教訓，你可能會發現它可以幫助你獲得對軟件的新觀點。畢竟，你所依賴的大多數框架和系統都是用純C語言編寫的，所以它絕不會傷害你理解基礎。 C++與直接C不同，但如果用C++ for Windows進行開發，則可能會發現自己在混合使用C和C++以使用Windows API，因此它會產生滴流效應。
一如既往。這取決於。 只要你遠離微軟大型框架，如MFC，.net等你的應用程序可以快速，但很難編碼。您的好處：您將真正瞭解Windows如何在其良好（？）表面背後工作。只需查看COM對象的初始化代碼即可知道我的意思。你將永遠不會在VB或C＃中看到這樣的東西。你必須自己編寫每個按鈕，每個窗口和每個控件，發送愚蠢的窗口消息，但是你的應用程序很小，很小。這是一個被遺忘的藝術：
寫小，快節目
祝你好運！
你會恨我的答案：
的最大瓶頸在GUI開發通常是因爲語言的不。在大多數應用程序中，大部分時間都是UI空閒，等待一些用戶輸入。我已經可以聽到你的尖叫聲，但我在大多數應用程序中都說過。
讓我們這樣說吧：我非常肯定你可以在.Net CLR之上設計一個好的用戶界面。學習C++是一件好事，但不能解決開發良好UI的固有問題。
是和否。這都是關於優化......而且由於C++允許您在較低級別上工作，C++是編寫快速應用程序的最佳語言之一。 但是，如果您習慣於更抽象的OOP方法，那麼在C++中實現的那些低級機制可能非常煩人。 用C++測試你的軟件通常是一個漫長的過程。 如果你正在尋找速度，C++肯定會是最好的選擇之一。
是的，C++絕對好。檢查Qt。它也有很好的Python binding，所以你可以很容易地用Python進行原型開發，當你需要額外的性能時，移植到C++大多是1：1翻譯。
但事實上，寫C++是不是很難或者當你有一個很好的平臺，最糟糕的部分是寫所有的類聲明:-)
如果你致力於學習生，堅韌不拔Win32的細節，然後C++會讓你在那裏。如果你不是，那麼你最終會使用一堆包裝。對於像小實用程序或尤其是這樣的東西，就像shell擴展（嘗試使用.NET會導致問題），C++將允許您在外部依賴中編寫有效的代碼，絕對最小化。對於一個更大的應用程序，YMMV--很多UI呆滯都來自於糟糕的設計：天真的算法，不願意將不重要的操作分離到單獨的線程中，依賴於寫得很差的第三方組件，而不是自定義控件...使用任何語言輕鬆製作錯誤。
這是我誠實的回答。
首先，我認爲每個程序員都應該學習C/C++，只是爲了學習C++學習編程。這是一種系統級語言。你必須考慮內存管理的更精細的細節等等。我對有多少程序員不瞭解編程語言或計算機系統的基本方面感到震驚。通過學習C/C++，你可以強迫自己在更親密的層面上理解編程。最重要的是，如果你學習如何用C/C++編程，你幾乎可以編程任何東西。
這並不是說C/C++始終是工作的正確工具。編寫更有意義的代碼可能會花費更多的時間進行調試並花費更長的時間。但是，對於那些需要絕對控制程序執行情況的情況，它非常適用。
這就是說，我不喜歡C/C++的UI編程。您仍然必須使用特定於您所運行的操作系統（MFC，Win32，Motif，GTK，QT等）的窗口框架。這些框架不適合簡單的學習曲線。對於至少Windows開發來說，.NET確實是UI開發的未來（儘管令人驚訝的是，MFC對Vista進行了重大改進，即使.NET沒有這樣做）。如果你使用.NET編寫你的用戶界面，維護起來更容易，而其他用戶需要維護。
我通常在.NET中編寫我的UI，在C++中編寫後端。
我寫了C++ windows應用程序10年，並在大約2年前切換到c＃以使用最新產品。我爲C＃應用程序的可悲程度感到尷尬。啓動需要20秒，您必須等待一秒左右才能在屏幕之間切換。我已經使用了一些第三方GUI控制庫，並且像篩網一樣泄漏內存！我的應用運行在150兆，並且幾乎沒有任何事情。
我期待回到C++。
您可以使用MFC，它將比.Net更快。或者，如果您真的想刻錄，請查看WTL - 儘管如此，這方面的文檔並不多。我建議你選擇MFC或Qt，因爲你會發現很多好的信息和教程。
我可以看到C＃可以更快地開發，也許在未來的某個版本中它會更快更小。
C++的確可能會讓你更精簡，更快，更快的應用程序（如果你做對了）。但是，.NET框架是爲了從開發人員的角度來看的舒適性而構建的;與Win32 API或MFC相比，這是一個巨大的改進，相比之下，這可能看起來像是艱苦的工作。所以考慮如何實現應用程序依賴於.NET的方面（還有其他可能比MFC或Win32 API更簡單的框架）並考慮使用此類框架的成本和許可證問題;例如免費的VC++ Express Edition例如不包括MFC支持。
如果你知道你的應用程序在哪裏呆滯，C++/CLI可能是一個解決方案;允許您混合託管代碼和本地代碼，以加速需要它的部分。但是，如果它是本質上慢而不是應用程序處理的GUI;這可能不是有用的路徑。
你也可以學習D'http://www.digitalmars.com/d/2.0/overview.html' – 2008-10-04 02:06:45