WPF是可行的C++程序GUI解決方案么?

12-30

用過WPF之後再解觸其它的C++界面庫都感覺用起來沒WPF來得爽，由此想到了用C++來寫動態連接庫並由C#WPF調用來做東西。請問這種方案有什麼缺點么?有更好的解決方案么?
由於編程啟蒙是vb開始的不管過多久還是很喜歡可視化程序界面設計的感覺。。
謝謝。

一定要純粹的C++的話，如果你追求使用WPF的那種獨特的爽快感覺的話，只有我寫的 http://gaclib.net 最接近WPF了，可惜還沒寫完（逃，1.0目測年底可以出，gaystudio要到明年。

現在的GacUI可以讓你用XML（以後就是gaystudio輸出XML）把整個界面做完之後，調用GacGen.exe生成一大堆C++代碼。這份代碼看起來比較啰嗦（因為偷懶生成了太多獨佔一行的大括弧），但是實際上他的功能就是用C++來表達你在XML裡面寫的東西，包括如何構造UI，還有data binding，還有為了方便些進去的一些腳本等等。不管你的界面多複雜，啟動速度都如閃電一般，運行的時候絲般順滑。而且經過前幾個月的優化，CPU的佔用也已經無限下降了，再也不會在沒有任務的時候10%，而是已經變成了0%。

我作為作者，並不推薦大家在使用GacUI的時候，不使用XML。因為我每次升級的時候，我都保證XML是向下兼容的，但是並不保證C++構造UI的部分也是向下兼容的，雖然跟構造GUI無關的很多別的東西，其實也是向下兼容的（逃

在我把control template的構造部分重構完以後（XML仍然向下兼容，但是C++介面大改），GacUI大概也就有了可以做1.0 release的品質了，後面就是要給gaystudio做準備。gaystudio大概就是一個編輯器（可能含有調試功能），需要支持XML+腳本的那種parse起來很麻煩的東西。

到時候估計要開一個專欄的系列，就像以前寫博客一樣，當周記一樣寫，記錄我造輪子的過程。這種東西當然不是教程，所以你們有可能看到我一個東西介紹著介紹著，突然發現有什麼問題，然後推翻重來（逃

Multiplatform Game UI Middleware based on XAML

你可以認為這個是native C++ XAML，不用跨語言調用了。

GUI這個東西其實跟應用程序類型很有關係，你寫個類似記事本的應用就用不著太可視化拖拽設計的GUI庫，但是如果寫一個有成百上千窗體的應用就是需要方便的設計器。所以，從另一個角度說，WPF不是所有場合都適用，另，純寫DLL調也是一種方案，曾經這樣做過項目，就是比較麻煩，採用了類似全插件的設計，界面庫也是一個單獨的插件，我甚至可以在WTL和MFC寫的兩種界面庫中切換，但是這樣做需要把所有東西都介面化，抽象化，這樣才能在不同的DLL中訪問，內存管理也比較複雜，除非必要，不要這樣給自己找麻煩比較好。

目前的項目架構就是wpf+c++cli+c++。

wpf寫上層確實很爽，天然的mvvm架構，看起來莫名舒服。一部分非得用c++做的東西，做完後需要再封裝一層給c#調用。我們的項目很大一塊核心是要和fpga交互，還要做很多圖像處理的工作，界面不是核心，但也很重要。目前的感覺就是，wpf還是不錯的，開發快，界面美觀，對了，wpf和dx完美結合，用dx引擎做東西拿上來呈現很方便！這一點也是當時考慮的原因之一。

缺點：招不到人，基本都是招進來從頭帶，還有人覺得做wpf沒市場，不願意做這個開發；啟動速度的話我們沒有要求，不過確實不快，但可以接受；跨平台，這個還沒去做，感覺會遇到不少問題，擔憂中；

其他：運行效率和質量也還不錯，目前沒遇到因為wpf的原因導致的產品問題；封裝c++，用c++cli調用必要的函數，工作量還行，多花幾分鐘的事。反正我們花幾個月做的東西，有客戶說和大廠搞得東西用起來差不多，界面很漂亮。

為啥不用Qt。。。。這麼好的工具

Qt QML，類json的表述，比xml強太多

UWP可以C+++XAML，絕對原生

QML 讓你寫界面跟wpf一樣爽，還跨平台。

至於gayui那個，自己玩玩還成，商業項目放著這麼多優秀的開源框架不用用這個簡直作死。

正在學Qt 看起來不錯 wpf沒接觸過不做評價但是試過mfc…內個手感酸爽

主要有3個缺點：

1）麻煩，很多功能都要封裝成C#可用的形式，這些都是額外的工作量，並且很多這類工作都很枯燥

2）啟動慢，WPF程序的啟動速度相比原生C++要慢一些。

3）依賴.net框架

有沒有更好的方案則見仁見智，有人覺得QT不錯，有人覺得wxWidgets不錯，有人覺得其它什麼UI庫不錯，還有很多人覺得自己寫的UI庫就很好，所以不能一概而論，頗有些「文無第一」的味道。

不好，動態庫這東西有很多局限性的。有很多東西在動態庫裡面實現很難或者不能實現。調用動態庫不如用靜態庫，然而。。。