web-dev-qa-db-ja.com

MFCとATLの基本的な違いは何ですか？

私がonlyであると仮定して、それらを「通常の」GUIプログラムに使用します（COMなし、ActiveXなし、空想なし）、根本的な違いは何ですかATLとMFCの間を確認し、どちらを使用するかを判断しますか？

私はウェブ上でいくつかの検索を行いましたが、最終的には答えが私の質問に本当に答えませんでした：

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

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

      本当に私の質問に答えないのは：

      • COMを使用していません。

      • これはMFC is n't fastを意味しますか？なぜ、どのように？

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

      また、私の質問には答えません：

      • そもそもActiveX isが何なのかさえも知りません。

      • マイクロソフトがMFCの使用を推奨していないように見えますが、その理由はわかりません。

      • 正確に何isATLが提供しないMFCの「ビルトイン機能」

    • 一般に、これは私の質問に答えません。なぜなら、マイナス面とその背後にある理由を説明していないからです。

直接的または間接的に、すべてが前のページにリンクしているように見えるためです。

私が持っているもの現在観察されているもの（過去数日以内に、両方を学ぼうとしている間）：

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

しかし、そこにはそれらの間にアーキテクチャ上の違いはないようです：

  • どちらもメッセージマップ（BEGIN_MSG_MAP vs. BEGIN_MESSAGE_MAP...大したこと）
  • どちらもWin32メソッドをクラスにラップします
  • 両方とも同様のクラスを持っているようですCWnd vs. CWindow

しかし、コンパイル時と実行時の側面以外に実質的な違いがない場合、なぜ両方が存在するのでしょうか？それらの1つで十分ではありませんか？

ここに何が欠けていますか？

c++visual-c++mfcatl
100
Mehrdad

2つのライブラリがどのように起源を持ち、時間とともに進化したかを振り返ると、あなたの質問に対する答えはほとんど歴史的なものだと思います。

簡単な答えは、「凝った」何かをしていない場合は、ATLを使用することです。 COMがスローされたシンプルなユーザーインターフェイスに最適です。

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

[装飾の編集：Microsoftで働いていなかったため、OfficeがMFC上に構築されたことがあるかどうかはわかりませんが、答えはノーだと思います。勝利3.1、勝利95日、Office UIチームは新しいコントロールを発明し、それらをライブラリにパッケージ化し、その後、WindowsおよびMFCチームは再配布可能なdllを使用してそれらのコントロールにラッパーとAPIを組み込みます。それらのチーム間で少しのコラボレーションとコード共有があったと思います。最終的に、これらのコントロールは、サービスパックまたは次のWindowsバージョンのベースオペレーティングシステムに組み込まれます。このパターンは、Officeの出荷後もアドオンコンポーネントとしてWindowsに追加されたOfficeリボンで継続され、現在はWindows OSの一部となっています。

当時、ライブラリは非常に原始的でした。C++言語とコンパイラが新しく、MicrosoftがOfficeの進化とともに徐々に構築してきたためです。

この歴史のため、MFCは次のことを行います。

  1. かなり不格好なデザインです。 Windows APIの軽いラッパーとして始まりましたが、成長しました。コンパイラと言語がそれらをサポートしなかったため、発明しなければならなかった小さな「機能」の束があります。テンプレートはなく、文字列クラスを発明し、リストクラスを発明し、独自のランタイムタイプ識別などを設計しました。
  2. 20年にわたるOfficeとWindowsの進化をカプセル化します。これには、おそらく決して使用しないものがすべて含まれています。単一および複数のドキュメントインターフェイス、DDE、COM、COM +、DCOM、ドキュメントリンク、埋め込み（Wordドキュメントを必要に応じてアプリ）、ActiveXコントロール（Webのオブジェクト埋め込みの進化！）、構造化ドキュメントストレージ、シリアル化とバージョン管理、自動化（初期のVBA時代から）、そしてもちろんMVC。最新バージョンでは、Visual StudioスタイルのウィンドウドッキングとOfficeリボンがサポートされています。基本的に、レドモンドの20年後のすべてのテクノロジーはどこかにあります。ただ巨大です！
  3. たくさんの小さな落とし穴、バグ、回避策、前提条件、まだ使用しないものがまだ存在することに対するサポートがあり、それらは問題を引き起こします。多くのクラスの実装と、適切なサイズのプロジェクトで使用するためにそれらがどのように相互作用するかについて、親密に理解する必要があります。デバッグ中にMFCソースコードを詳しく調べることは一般的です。ポインタがnullであるためにクラッシュを引き起こす15年前のテクニカルノートを見つけることはまだ起こります。古文書の埋め込みを初期化するという仮定は、奇妙な形でアプリケーションに影響を与える可能性があります。 MFCには抽象化のようなものはありません。MFCの癖や内部処理を毎日行う必要があり、何も隠しません。クラスウィザードを開始しないでください。

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

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

[装飾の編集：ATLが作成された時点で、Microsoftの技術ロードマップは主に「ドキュメント管理」に焦点を合わせていました。 Appleはデスクトップパブリッシングビジネスでそれらを殺していました。Office 'Document Linking and Embedding'は、この分野で競争するためにOfficeの 'Document Management'機能を強化する主要なコンポーネントでした。COMはコアでしたアプリケーション統合のために発明された技術、およびドキュメント埋め込みAPIはCOMに基づいていました。MFCはこのユースケースで使用するのが困難でした。

これらの小さな改善により、MFCの機能のようなすべてのオフィスを必要としない単純なアプリケーションでのATLの処理が非常に簡単になります。シンプルなUIといくつかのOfficeオートメーションが組み込まれています。それは小さく、高速で、コンパイル時間が制限されているため、時間と頭痛が大幅に節約されます。 MFCには、不格好で扱いにくいクラスの巨大なライブラリがあります。

残念ながら、ATLは停滞しています。 Windows APIとCOMサポートのラッパーがあり、それを超えることはありませんでした。 Webが普及したとき、これらはすべて古いニュースとして忘れられていました。

[装飾の編集：Microsoftは、この「インターネットシング」が大きくなることに気付きました。彼らの技術ロードマップは劇的に変化し、Internet Explorer、Windows Server、IIS、ASP、SQL Server、Distributed Transaction ServerのCOM/DCOMに焦点を合わせました。そのため、ドキュメントのリンクと埋め込みは最優先事項ではなくなりました。]

MFCのフットプリントが大きかったため、ダンプすることはできなかったため、まだゆっくりと進化しています。テンプレートはライブラリに組み込まれ、他の言語とAPIの機能強化も行われました。 （この質問を見るまで、WTLのことは聞いていませんでした。）

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

長年MFCを使用していたのにちょうど2セントでしたが、現在は毎日使用しています。 ATLが数年にわたっていくつかのプロジェクトで初めてリリースされたとき、私はATLに手を出しました。それは当時の新鮮な空気の息吹でしたが、どこにも行きませんでした。そして、Webが登場し、それをすべて忘れました。

編集：この答えには驚くべき長寿があります。スタックオーバーフローページに表示され続けるので、欠けていると思った元の答えに装飾を追加すると思いました。

162
Jay

私は両方を使用した多くの人々から、彼らのプログラミング経験はMFCよりもATLの方が痛みが少ないと言われました。コンパイルされた実行可能ファイルも、ATLを使用するとはるかに小さくなります。

WTLを見てください をお勧めします。ATLに基づいているからです。

彼らが言及し続ける「追加機能」とは何ですか？必要ですか？

要件を定義する場合、MFCの使用を避けることができれば、答える方が簡単かもしれません。残念ながら、「空想なものは何もない」だけでは十分ではありません。どの機能を使用するかについて包括的である方が便利です（どのコントロール、使用するフレームワーク/テクノロジー/既存のライブラリなど）。

しかし、ここに WTL/ATLで直接サポートされていないMFCの機能を説明する記事

MFCは、MAPI、他のWindowsロゴ要件のサポート、ソケット、ドキュメント（必要に応じて、および/またはそのパターンを使用する場合）、複合ドキュメントファイルなど、非常に多くの望ましい機能をサポートするように進化しました。 WTLにはクールな機能が多数ありますが、MFCは明確な機能のチャンピオンです。両方の環境は、フレーム付きメインウィンドウアーキテクチャ（個別のビューウィンドウを備えたフレームウィンドウ）、SDIおよびMDIアプリケーション、分割ウィンドウ、ダイアログベースのアプリケーション、およびCOMサポート用のさまざまなCOMベースのクラスをサポートしています。

18
Merlyn Morgan-Graham

ATLは、COMオブジェクトの実装を簡素化するためのクラスのセットです。

MFCなしで​​使用できます。私の仕事では、ATLを使用してCOMインターフェイスを計算コードに公開します。関与するGUIはありません。たとえば、この計算コードを呼び出すことができます。 Excel VBA。

いくつかのCOMガイド/チュートリアルを見て、抽象化されているものを確認してください。

MFCは、Win32 APIへのGUIラッパークラスのセットです。 Win32 APIチュートリアルを見て、抽象化されているものを確認してください。

9
Alexandre C.