ADHDという分類が妥当であるのかということはADHDの概念を確立したアメリカでも論争が続いている状況である。日本においては、ADHDの特徴については未だ明確に定義化されていない。またADHDの25%に反社会的な行動が見られるとされ、成人しても集中力の困難や反社会性パーソナリティ障害の併発などを起こすことがある。近年は一般向け書籍の増大やテレビ番組における報道による認知度の上昇の影響で、「自分がADHDではないか」と受診してくる患者が増えた。2013年に日本精神神経学会学術総会が静岡県の浜松市で行った調査によれば、調査対象10000人のうち196人がスクリーニングの結果ADHDの「疑いがある」と認定をされた。文部科学省は、ADHDの特徴として、「年齢あるいは発達に不釣り合いな注意力、衝動性、多動性」と定義づけている。文部科学省は、平成15年3月に行われた、「特別支援教育の在り方に関する調査研究協力者会議」において、判断基準や指導方法について提示した。また、同年より、高機能自閉症や学習障害も含めて、支援を目的とした、「特別支援教育推進体制モデル事業」を開始した。
MFCが発売された時、マイクロソフトはマクロの活用によってC++の文法を拡張し、ウインドウメッセージ、例外処理、実行時型情報、クラスの動的インスタンス化などを管理していた（例外処理、実行時型情報などは当時のC++の言語仕様にも実装（コンパイラ）にも存在しなかった）。ウインドウメッセージのために構文に変化を加えたことは、不要な仮想関数テーブルの使用を避けることでメモリの消費量を抑える狙いがあった。さらに、構造がより具体的になり、Visual C++に付属する多様なツールがソースコード全体を解析することなく処理できるという効果もあった。メッセージ処理のマクロは、C++の仮想関数の代わりとなった。ただ、一部のマクロはコンパイラによる型チェックを無効化することがあるので、しばしばバグの原因となった。MFCを使用することの主な利点は、Windows APIを利用したプログラム開発にオブジェクト指向プログラミングモデルを導入するという点である。もう一つは、Windowsのリソースに関連した一般的なデータ型に対するラッパーを提供するという点である。これらのラッパーを使用することで、リソース管理オブジェクトのスコープを出た時に自動的にリソースのハンドルを解放させることなどができる (RAII)。さらに、MFCはModel View Controllerモデルに基づいたアプリケーションを開発するためのドキュメント／ビュー フレームワークを提供する。マイクロソフトはC++標準化にあたって、多重継承について否定的な立場をとっていた。MFCもその理念に従い初期のMFCは多重継承を全く使用しておらず、オブジェクトとしての機能は基底クラスに、そして具体的な機能の実装は単純継承によって実装されている。これはオブジェクトが不要なメンバによって肥大化する事が無く、また不必要に修飾されていないので個々のクラスを理解する事が容易になっている。しかし、一部のクラスは多重継承（より近代的な実装ならばテンプレート）によって実装されるべき物も単純継承によって実装されており、これらは統合開発環境の支援なくしては扱えない難解な物になっている（後述のCViewやCDocumentもこれに含まれる）。MFCの主な欠点は、多くのOSで利用できないという点である。MainsoftはUNIXで利用可能なMFCツールを開発した。マイクロソフトは1990年代にMacintoshに対応したMFCを販売していたが、それ以降はMacintoshに対するVisual Studioのサポートは中止された。また、Visual C++のC/C++ライブラリと同様に、ライブラリのバージョンごとにメモリ管理が異なるため、互いに異なるバージョンのMFCを使用したEXE-DLLプログラム間でDLL境界を越えてMFCオブジェクト・CRTオブジェクトをやりとりできないなど、バージョン間でのバイナリレベルの互換性が低くなっている。そのため、旧バージョンのMFCを使って開発されたDLL（MFC拡張DLL）やスタティックライブラリを、新バージョンのMFCアプリケーションでそのまま利用することは基本的に不可能（その逆もまた然り）となっており、ソースコードからの再ビルドが必要となる。なお、非MFCアプリケーションや、異なるバージョンのMFCアプリケーションから、MFCを使って実装したコードを実行する場合、MFC標準DLLもしくはATL COMサーバーのプロジェクト形式を選択し、C言語関数形式のインターフェイスやCOMインターフェイスを作成してアプリケーション側に公開する必要がある。MFCはあくまでWindows APIのラッパークラス群およびそれらを利用したフレームワークという位置付けのため、生産性の点ではVisual BasicやVisual C#、DelphiなどのRADツールに遠く及ばない。また、C++言語の習得は比較的難しい部類に入るため、エンドユーザープログラミング（エンドユーザーコンピューティング）の観点からも敬遠されがちである。しかし、そういったいくつかの問題点を抱えているにもかかわらず、MFCが未だ多くの企業や個人プログラマーに利用されているのは、実行速度や動作プラットフォーム、開発環境および開発言語の変更コストの問題などで旧来のネイティブコード資産を完全に.NETに移行することが難しく、またWindowsアプリケーションにおいて凝った機能を実装しようとすると、Windows APIおよびCOMコンポーネントを直接操作するほうが却って楽であることが多く、これらと親和性の高いMFCを選択せざるを得ないためである。なお、Visual C++ .NETに搭載されているマネージ拡張C++、あるいはVisual C++ 2005以降に搭載されているC++/CLI言語を利用することで、従来のMFCアプリケーションから.NET Frameworkのライブラリをシームレスに利用する、もしくはMFC標準DLLに実装されたMFCネイティブコードをマネージコードでラップすることで、C#あるいはVB.NETのような.NET言語向けにクラスライブラリの形で公開する、といったハイブリッド開発・相互運用が可能となり、ネイティブコードとマネージコードの資産をともに活かすことができるようになる。しかし、マネージ拡張C++やC++/CLI言語を用いた開発はネイティブコードおよびマネージコード双方にまたがる知識が必要となるため、MFCのみを利用した場合、もしくは.NETのみを利用した場合と比べて難易度が高くなる。