WPF / C＃とQt / C ++の選択
私と私のチームは、C++で記述されたバックエンドを含み、OpenCV、MILなどのライブラリを使用するアプリケーションを開発しています。
次に、このプログラムとインターフェイスするGUIを開発し、GUIが画像を表示し、ユーザーが画像を操作して画像に注釈/マークを付け、C++で記述された画像処理アルゴリズムを実行して結果を表示できるようにする必要があります。
GUIについては、WPFとQtの選択にこだわっています。個人的にはWPFの方がQtより簡単で強力だと思います。WPFはLinuxに移植できないことを理解していますが、これについてはあまり心配していません... DirectXテクノロジーを使用します。これは、後の段階で3D視覚化を生成するために使用する必要があります。
これらの点で私を助けてください：
- WPFをC++と直接インターフェースできますか（Visual C＃とはインターフェースしませんか？）
- （ポイント1）が不可能な場合は、これを考慮してください：C++のコードは大きくなり、いくつかのライブラリも含まれるため、C＃を使用してC++関数を呼び出すことができますQtの学習に費やした時間はアンマネージ非OO C++コードはWPFで動作しますか？
（私は、C++とWPFをインターフェースするためにあまりにも多くのコードを書かなければならないという落ち込んだ感じがあります。
QtとC++およびWPFの両方を使用しました。私はユーザーインターフェイスフレームワークとしてWPFを好みます。 Qtは悪くない、特に4.0以降。 Qtの以前のバージョンには触れません。
他の人がコメントで述べたように、WPFはより適切に文書化され、オンラインコミュニティはより大きくなります。スタイル設定されたアプリケーションを検討している場合、WPFを使用するのは確かです。新しいQtの宣言型言語は、その道に沿った良いステップですが、とても新しいので、少しバグが多い傾向があります。 WPFは以前より長く使用されており、より成熟して機能が豊富になっています。
しかし、あなたの場合の本当の問題はあなたが持っているc ++コードベースだと思います。
WPFは、C++コードベースと適切にインターフェイスするために、C++/CLIレイヤー（マネージC++）を必要とします。これは複雑に聞こえますが、少し手間がかかりますが、聞こえるほどクレイジーではありません。また、これに関するドキュメントも多数あります。個人的には、PInvokeから離れていました。
QtはC++ベースであるため少し簡単ですが、C++ネイティブ型と、内部で使用されるQt型（QString、QListなど）の間で何らかの変換を行う必要があります。
考慮すべきもう1つの点は、UIの外観と感じ方です。たとえば、Nice Ribbon（office 2008、2010）の外観を考えていた場合、Qtではこれを取得できません。また、サードパーティのWPFコントロールがたくさんありますが、Qtの多くは見つかりませんでした。場合によっては、Microsoftがデフォルトで提供するコントロールを補完するニースコントロールセットを購入すると非常に便利です。
過去数年間、Linux UIを使用する必要がないため、コードベースに関係なく、WPFを使用していました。まだ後悔していません。
ただし、3番目のオプションも提案します。 Code-jockは、MFCに基づいたUIフレームワークです。 C++およびActiveXベースです。それは非常に洗練されました。 こちら をご覧ください。
編集：私が最初にそれを見て以来、QMLは長い道のりを歩んできました。詳細に見る時間はありませんでしたが、聞いたことから非常に興味深い機能がいくつかあります。それは一見の価値があります。
また、いくつかのコメントが示しているように、リボンなどのOfficeに似たコントロールや、Qtツールセットに追加された図とグラフのコントロールもあります。これらはQtを興味深い見通しにします。
ただし、プログラマーとしてWPFでUIを作成する方がはるかに簡単だと感じ、Qtでコーディングしたものよりも自分の結果に満足している、と先ほど言ったことに立ち向かいます。
C++の場合は、Qtに固執します。プロジェクトの3D部分はQtのOpenGLウィジェットで処理できます。 WPFパスを選択すると、C＃またはVB.netでいくつかの部分を実行する必要があります（常に悪い習慣です）。 C++でWPFを使用する利点はあまりありません。また、残りのコードはC/C++です。あなたのニーズに合っています。 OpenCV、MILなどは、WPFでP/Invoke呼び出しを行うよりもQtと統合する方が多少簡単です（これも.Netマーシャリングによる遅延を引き起こします）。
大きなC++コードベースを既にお持ちの場合は、Qtを使用する必要があります。 WPFは、彼らが言うほど素晴らしいものではなく、開発も容易ではありません。 C++とQtはよく知られたチームですが、WPFを使用したプレーンなC++（.NETではない）はそうではありません。
WPFはUIフレームワークであり、プログラミング言語ではありません。 C＃またはVB .NETでWPFアプリケーションを作成できます。NETアプリケーションからネイティブC++コードを使用するには、2つのオプションがあります。
PInvoke-ネイティブライブラリからプレーンC APIを呼び出すことができます。 PInvokeはC++クラスでは機能せず、関数のみで機能します。 VB6のAPI呼び出しと同じように機能します。
C++/CLIラッパーを使用して、C＃/ VB .NETクライアントで使用できる.NET Dllを作成できます。内部的に、このDllはネイティブC/C++ライブラリを使用します。
WPFに慣れており、クロスプラットフォームソリューションが必要ない場合は、それを使用できます。相互運用性の部分を学ぶ必要があります。 C++/CLIは非常に複雑な言語ですが、ネイティブC++と.NETの両方を知っているプログラマは学習できます。
一方、Qtは既存のC/C++コードを直接使用でき、クロスプラットフォームソリューションを提供します。
過去数年間、私はSWIGを使用して、純粋な（管理されていない）C++ DLLをWPFアプリケーションで使用できるようにしました。問題なく動作し、アビオニクスメンテナンストレーナーなどの大規模なアプリケーション向けです。
SWIGは、1つのインターフェイスファイルセット（.hヘッダーファイルに基づいて記述しているため非常に簡単です）を使用して、すべてのスキャフォールディングコードを生成してC++ DLLを複数にエクスポートできるため、 C＃、Python、Lua、Javaなどの言語。SWIGは、C++またはLuaからC++クラスを拡張する場合に必要なコードを生成し、言語間の例外の受け渡しを処理します（したがって、LuaスクリプトはC++をトリクルする例外をスローできますPInvokeに触れる必要はありません（SWIGがすべてを行います）。それは驚くべきことです。
このように、同じSWIGインターフェイスにより、GUIにWPF（C＃、. NET 4を使用）、統合が必要な既存のライブラリにネイティブC++バックエンド（SWIG経由）を使用し、スクリプトをサポートするLuaインタープリターを埋め込むことができましたアプリケーションの（SWIG、同じ.iインターフェイスファイル、およびsourceforge上のlua-icxxを介して、Lua C APIインタープリタースタックとのインターフェースを簡素化する）。
このスレッドが開始されてから2年後、Qt/QMLとWPF/XAMLがどのように比較されるのか疑問に思っています。また、WPFでしばらく使用できたビルトイン3Dを追加するQt3Dがあります（OpenGLまたはDirectXなしでネイティブに3Dキャンバスをサポート）。
WPFコードは、C＃またはVBでデザイナーとツールのサポートを取得する必要があります。C＃とC++の相互運用は、モジュールのコーディングを可能にする混合モードアセンブリを使用することで非常に優れています。マネージコードとアンマネージコードの混合にコンパイルされるC++で、これにより、ネイティブC++ライブラリへのタイプセーフな相互運用が可能になります。
混合モードアセンブリの詳細については、 here を参照してください。私たちは彼らを保証することができます。
IMOの重要な考慮事項の1つは、WPF学習曲線です。チームを連れて行けば、非常に生産的だと思います。
WPFシナリオでは、WPF（つまり、xamlビュー）からアンマネージC++に直接接続することはありません。 C++モジュールをVBまたはC＃マネージドラッパーでラップします。（理論的にはマネージドC++ラッパーを使用できますが、これを行うには気が狂います。）少なくとも.NET言語で記述されたシンビューモデル。WPFはアンマネージコードに直接アクセスできないため、「。NETアプリはアンマネージC++とインターフェイスできますか？」 。
http://msdn.Microsoft.com/en-us/library/aa984739（v = VS.71）.aspx