[解決済み] MFCとATLの根本的な違いは何ですか？

ウェブでいくつか検索してみましたが、結局、どの回答も私の質問に本当に答えてはくれませんでした。

• http://msdn.microsoft.com/en-us/library/bk8ytxz5(v=vs.80).aspx :

  • ATL は、C++ で COM コンポーネントを作成し、小さなフットプリントを維持するための高速で簡単な方法です。MFC が自動的に提供するすべての組み込み機能が必要でない場合は、ATL を使用してコントロールを作成します。

    私の質問にはあまり答えていません。

    • COM で作業しているわけではありません。

    • これは MFC を意味するのでしょうか は は速くないということでしょうか？なぜ/どのように？

  • "MFCでは、完全なアプリケーション、ActiveXコントロール、およびアクティブなドキュメントを作成することができます。すでに MFC でコントロールを作成している場合は、MFC で開発を継続することができます。新しいコントロールを作成する場合、MFC の組み込み機能のすべてが必要でなければ、ATL の使用を検討してください。"

    また、私の質問には答えていません、なぜなら。

    • 私は、ActiveX が何であるかさえ知りません。 は がそもそも何なのかさえ知りません。

    • Microsoft は MFC の使用を控えているように見えますが、その理由がわかりません。

    • 具体的にはどのような は ATLが提供しないMFCの"ビルトイン機能"ですか？

  • 一般的に、これは私の質問に対する答えにはなりません。 デメリットを説明していない とその背後にある理由を説明していないからです。

というのも、直接的にも間接的にも、すべてのものが前のページにリンクしているように見えるからです。

• 新しい C++ プロジェクトで ATL、MFC、Win32、CLR のいずれを使用するかをどのように決定すればよいですか。

  • ATL と MFC のどちらかを選択するのは、やや難しいです。 [冗談じゃない！]]。 私は、以下のサイトを参照してください。 MSDN のページ を参照してください。

    明らかに これは私の質問の答えになっていません。）

• http://www.codeguru.com/forum/archive/index.php/t-64778.html

• など。

私が持っているもの 現在観測されている (ここ数日で、両方を学ぼうとしている間)。

• ATL はテンプレート、またはコンパイル時のポリモーフィズムに基づきます。
  • ATL のメソッドは非仮想的で、参照を返す傾向があります。
• MFCは仮想メソッド、つまりランタイムポリモーフィズムをベースにしています。
  • MFC のメソッドは仮想的であり、ポインターを返す傾向があります。

しかし、そこで は、両者の間にアーキテクチャ上の違いはないように思われます。 :

• どちらもメッセージマップ( BEGIN_MSG_MAP 対して BEGIN_MESSAGE_MAP ... 大きな問題)
• どちらも Win32 のメソッドをクラスにラップする
• どちらも似たようなクラスを持っているようです CWnd 対して CWindow

しかし、では、コンパイル時対実行時という側面以外に本当の違いがないのであれば、なぜ両方が存在するのでしょうか？どちらか一方だけで十分ではないでしょうか？

私はここで何を見逃しているのでしょうか？

どのように解決するのですか？

2つのライブラリがどのように生まれ、時代とともに進化してきたかを振り返ると、その答えはほとんど歴史的なものだと思います。

簡単に言うと、もしあなたが何も派手なことをしないのであれば、ATL を使ってください。 これは、COM を含む単純なユーザー インターフェイスに最適です。

長い答えです。 MFC は、C++ という新しい言語を試し、Windows に適用するために 90 年代初期に構築されました。 OS にまだ備わっていなかった Office のような機能を開発コミュニティが利用できるようにしたのです。

[装飾を編集する。 私は Microsoft で働いていなかったので、Office が MFC で作られていたかどうかは知りませんが、答えは「ノー」だと思います。 Win 3.1 や Win 95 の時代には、Office UI チームは新しいコントロールを発明し、それらをライブラリにパッケージ化し、そして Windows と MFC チームは再配布可能な DLL を使ってそれらのコントロールのラッパーと API を組み込んでいたものです。 これらのチーム間では、ちょっとしたコラボレーションやコードの共有が行われていたのでしょう。 最終的には、これらのコントロールは、サービスパックや次のWindowsバージョンで基本オペレーティングシステムに組み込まれることになります。 このパターンは、Officeの出荷後、アドオンコンポーネントとしてWindowsに追加され、現在ではWindows OSの一部となっているOfficeリボンでも続いています]。

当時は、C++ 言語とコンパイラーが新しかったことと、Office の進化に伴って Microsoft が時間をかけて構築してきたことから、ライブラリは非常に原始的なものでした。

このような歴史があったからこそ、MFC

1. かなり不格好なデザインを持っています。 Windows API の軽いラッパーとして始まりましたが、大きくなりました。 コンパイラーと言語がサポートしていなかったので、たくさんの小さな「機能」を作り出さなければなりませんでした。 テンプレートはなく、文字列クラスを発明し、リストクラスを発明し、独自のランタイム型識別を設計した、などです。
2. 20 年間に及ぶ Office と Windows の進化をカプセル化したもので、おそらく一度も使うことのないようなものも含まれています。単一および複数のドキュメント インターフェイス、DDE、COM、COM+、DCOM、ドキュメントのリンクと埋め込み (その気になればアプリにワード ドキュメントを埋め込むことができます)、ActiveX コントロール (Web 用オブジェクト組み込みの進化版!)、構造化ドキュメント保存、シリアライズとバージョン管理、自動化 (VBA 初期の頃) そしてもちろん MVC など、おそらく一度も使うことのないものが満載です。 最新バージョンでは、Visual StudioスタイルのウィンドウドッキングやOfficeリボンもサポートされています。 基本的に、この20年間にRedmondから生まれたすべてのテクノロジーが、どこかに含まれているのです。 まさに巨大です!
3. たくさんの小さな不具合、バグ、回避策、思い込み、決して使うことのないもののサポートがまだ残っていて、それが問題を引き起こすのです。まともな規模のプロジェクトで使用するには、多くのクラスの実装とそれらがどのように相互作用するかを熟知している必要があります。 デバッグ中にMFCのソースコードに入り込むことはよくあることです。 ポインタがNULLになるとクラッシュするという15年前のテクニカルノートを見つけたりすることは、今でもよくあることです。 古くからあるドキュメントエンベッディングの初期化に関する思い込みが、アプリケーションに変な影響を与えることがある。 MFCには抽象化というものがなく、その癖や内部構造を日々扱う必要があります。 そして、クラスウィザードについては、私に始めさせないでください。

ATL は、C++ 言語が進化し、テンプレートが登場したときに発明されました。ATL は、MFC ライブラリの実行時の問題を回避するためにテンプレートを使用する方法を紹介するものでした。

1. メッセージ マップ。 メッセージ マップはテンプレート ベースなので、型がチェックされ、バインドされた関数が正しく動作しない場合はビルドされません。 MFC のメッセージ マップはマクロ ベースであり、実行時にバインドされます。 このため、メッセージが間違ったウィンドウにルーティングされたり、関数やマクロが正しく定義されていないとクラッシュしたり、何かが正しく接続されていないために単に動作しないなど、奇妙なバグを引き起こす可能性があります。 デバッグがはるかに困難であり、気づかないうちに破損することもあります。
2. COM/自動化。 メッセージ マップと同様に、COM はもともとマクロを使用してランタイム結合されており、多くのエラー処理を必要とし、奇妙な問題を引き起こしていました。 ATL はそれをテンプレート ベースにし、コンパイル時にバインドし、はるかに、はるかに簡単に対処できるようにしました。

[編集の装飾。ATL が作成された当時、Microsoft の技術ロードマップは主に「ドキュメント管理」に焦点を合わせていました。 Apple は、DTP ビジネスで彼らを殺していました。 Office の「ドキュメントのリンクと埋め込み」は、この分野で競争するために Office の「ドキュメント管理」機能を強化するための主要な要素でした。 COMはアプリケーション統合のために発明されたコア技術であり、Document Embedding APIはCOMをベースにしていた。 MFCはこのユースケースには使いにくかった。 ATL は、サードパーティが COM を実装してドキュメント埋め込み機能を利用するために、この特殊な技術をより簡単にするための良いソリューションでした]。

これらの小さな改善により、ATL は、MFC のオフィスのようなすべての機能を必要としないシンプルなアプリケーションで扱うのが非常に簡単になりました。 シンプルな UI といくつかの Office オートメーションを含む何かです。 ATLは小さく、高速で、コンパイル時に拘束されるので、時間と頭痛の種を大幅に減らすことができます。 MFC には巨大なクラス ライブラリがありますが、これは不便で、一緒に作業するのが難しいものです。

残念ながら、ATL は停滞しました。 Windows API と COM サポートのためのラッパーがありましたが、それ以上には進みませんでした。 Web が軌道に乗ったとき、これらすべてのものは古いニュースとして忘れ去られたようなものでした。

[Edit Embellishment: Microsoft は、この「Internet Thing」が大きなものになることに気づきました。 彼らの技術ロードマップは、Internet Explorer、Windows Server、IIS、ASP、SQL Server、COM/DCOM、Distributed Transaction Server に焦点を当てるように大きく変わりました。 そのため、ドキュメントのリンクと埋め込みは、もはや高い優先度ではありませんでした]。

MFC の巨大なフットプリントにより、ダンプすることが不可能になったため、今でもゆっくりと進化しています。 テンプレートはライブラリに再び組み込まれ、他の言語やAPIの強化も行われました。 (私はこの質問を見るまで WTL のことを知りませんでした。 :)

最終的に、どれを使うかは単に好みの問題です。 必要な機能の大部分は基本 OS API にあり、ライブラリに適切なラッパーがない場合は、どちらのライブラリからも直接呼び出すことができます。

長年 MFC を使用し、現在は毎日使用している私の意見です。 ATL が最初にリリースされたとき、2 年ほどいくつかのプロジェクトで手を出しました。 当時は新鮮な息吹を感じたものですが、実際にはどこにも行きませんでした。 そして、Webが登場し、私はそのことをすっかり忘れてしまいました。

編集: この回答は意外と長持ちします。 私のスタック オーバーフローのページで何度も出てくるので、私が不足していると思ったオリジナルの回答に装飾を加えてみようと思いました。