Visual C++/C＃でのWinFormsのプログラミングとVisual C++（MFC）でのプログラミングとの違い

Question

Visual C++/C＃でのwinformsのプログラミングは、Visual C++（MFC）でのWindowsプログラミングとどう違うのですか？

また、C＃がフォーム以外の方法でWindowsプログラミングを実行できるほど強力であるかどうかを知りたいと思います。

Answer 1

は、いくつかの顕著な違いがあります。

• それを行うにははるかに簡単であるとしてあなたは最終的に、より生産的になるだろう（.NET）言語は一般的なミスの多くを（行うことからあなたを助け
• NULLポインタ、オーバーフロー、リーク）
• フレームワークはMFCよりもずっときれいです（実際には私は多くを意味します）
• 本質的にほとんど何でもできます。あなたが直接win32 DLLを呼び出す（または他の人が作ったラッパーやライブラリを使用する）必要があることの最も一般的な0.01％。

Answer 2

誰かがこの質問に1つの答えを与えることができるかどうか分かりません。ただ多くの違いのいくつかを指摘しようとすることができます：

• C＃とC++は全く異なっている：メモリ管理、パッケージ構造、クラスのレイアウト、イベント/代表者、ジェネリック/テンプレート...でも非を書きますGUIアプリケーションは、C++とC＃ではまったく異なっています。 C＃言語の多くの機能は、GUI開発用に設計されていない場合でも非常に役立ちます。

• Winformsは、MFCと比較してビジュアルデザイナーのサポートが非常に優れています。すべてのアプリケーションの95％で、winformsを使用することでより生産性が向上します。これは、カスタムコントロール（自分自身または第三者）に特に当てはまります。

• 反対側のMFCは、より多くのフレームワークサポート（ドキュメント/ビュー構造など）を提供します。

• 一部のアプリケーションでは、MFCアプリケーションの方が反応性が高いようです。これらのケースのほとんどで、winformアプリケーションは同じパフォーマンスを持つように最適化できますが、これは平均winforms開発者レベル（一般的にはMFCプログラマーの知識レベルよりも低い）を超えています。

• MFCはWinformsよりも直接的にWIN32 APIをカプセル化します。 winformsから直接WIN32 APIにアクセスする必要がある場合があります。それでは、必ずしも明確ではありません。ここでも、典型的なwinformsプログラマは、MFCプログラマよりもWIN32 APIについての知識が少ないので、これらの場合、より多くの問題に遭遇します。

• 私はwinformsがうまくサポートされていると思います。あなたはすべてのGUI/NON-GUIタスクを黙って解決することができます。ほとんどのタスクでは、C＃プログラムを書く方が簡単です。

私はちょうど私の心に入ってきたことをいくつか指摘し、より多くの引数のプロ/コントラがある、と確信している...

Answer 3

プロとして、私は私が好むことを認めざるを得ませんWIN32 /デスクトップの開発にはC++ではなくDelphiを使用してください。クライアントアプリケーションまたはスタンドアロンアプリケーションであるGUIアプリケーションを作成する場合、Delphi（およびC++ Builder）には.NETよりもはるかに視覚的なコンポーネントがあることがあります。これは、.NETがWeb開発やサービスアプリケーションでさらに普及しているためです。

Delphi（またはC++）が.NETよりも強力であるということではありません.GUIアプリケーションレベルで.NETが急速に普及しているためです。 WPF/Silverlightは、開発者のために多くの新しい可能性を約束します。

多くの人々が依然としてDelphi/C++ for WIN32を使用しているもう一つの理由は、依然として多くのレガシーコードを持っているからです。このコードの一部は既に10年以上働いており、追加のメンテナンスだけが必要です。 C＃/ .NETでこれらのプロジェクトを書き直すにはコストがかかるでしょう。人々はこれを考慮していますが、既存のコードはすでにそれ自体が証明されています。新しいコードでは新しいバグが導入されます。

C＃では、Windows開発を行うつもりはありません。あなたは.NET開発をやっており、.NETのいくつかの部分ではWindowsの機能を使うことができます。しかし、.NETクラスの大部分は実際にはWindows APIのラッパーであり、これらの関数を使いやすくしています。しかし、すべてが.NETで既に実装されているわけではありません。そのため、まだ多くの作業が必要です。

.NET開発の危険は、私が ".NET Hell"と呼ぶものです。 .NETが導入されたとき、人々は、Windows上のすべてのC++開発者を悩ませていたDLL Hellを終了しようとしていると言いました。さて、DLL Hellを終了させました。これは.NET Hellに置き換えて、同じアセンブリの複数のバージョンがまだ多くの問題を引き起こす可能性があります。それで、その点で何も変わったことはありません。特定のランタイムバージョンの特定のライブラリ（特にサードパーティのライブラリを使用している）に依存しているので、ここには本当の意味はありません。

これまでの.NET開発では、旧式のデスクトップアプリケーションの代わりにサービス（SAAS）として実行されるアプリケーションが増えています。基本的には、これらのアプリケーションを使用するためにはWebブラウザが必要なだけなので、特定のハードウェア要件への依存度は低くなります。ここでは、.NET開発の真の強みがあります。