Microsoft Foundation Class
Unicode文字列に対応したWindows OSはWindowsNT系で、Windows 9x系のOSではもともとUnicode非対応であり、歴史的にWindowsアプリケーション開発言語としてのC/C++は長らくMBCSを使用してきたが、国際化対応(Unicode対応)が求められるという時代の流れから、まずVisual Studio 2005ではプロジェクトの既定の設定がUnicodeとなり、さらにVisual Studio 2013からは、MBCS版MFC/ATLライブラリは非推奨となりインストーラに同梱されなくなった(Unicode版MFC/ATLライブラリのみ同梱)。なお、ライブラリのバイナリがIDEにバンドルされなくなっただけで、Visual Studio 2013向けMBCS版MFCライブラリのDLLバージョンはマイクロソフト社の公式サイトからダウンロードすることで取得できる。一方、Visual C++ 再頒布可能パッケージ(エンドユーザー向けリテールランタイム)には、2013以降も、引き続きMBCS版MFCランタイムDLLが含まれ、MBCS版MFCランタイムを顧客に再頒布するための追加の手順は必要ない。
なお、Windows 8/Windows RTで導入されたWindowsストアアプリ(のちのWindows 10におけるユニバーサルWindowsプラットフォームアプリ)は、C#などの.NET言語による開発のほか、C++/CX(英語版)というネイティブ拡張言語による開発も可能となっているが、ATLの一部は使用できるもののMFCは使用できない。また、Windowsストアアプリではマルチバイト文字・文字列のAPIが使えなくなっており、ASCIIもしくはUnicode文字・文字列のみが使用できる。
CDocument, CView 等の基本的なクラスの仕様が難解である。Windowsメッセージ、コマンド、およびシェルといったWin32 APIの基本を理解していることが前提となる。
クラスは基本的に単一継承のみであるため、階層が深くなりがちである。また、friendクラスが多用されていることもあって直交性が低い。
ATLと共有する一部を除き、すべての関数、構造体、クラスおよび列挙型などがグローバル名前空間に存在し、さらにマクロが多用されているため、名前のコンフリクト(識別子の衝突、競合)が発生しやすく、また継承の階層構造がわかりにくい。なお、MFCシリアライズ機能を使用するクラスは、グローバル名前空間で定義しなくてはならない。
実行時型情報や例外処理機構などの一部の仕様は、独自のマクロを使用した実装となっているため、標準C++との統一感がない(標準C++の実行時型情報および例外処理機構との併用や共存は可能)。
変数名に(16ビット時代からの)古いシステムハンガリアン記法 を採用しているため、最新のコーディングスタイルに合わない。
Win32 API自体が拡張を繰り返した結果、APIとしての統一性に欠けるものとなったため、その薄いラッパーライブラリ(英語版)でしかないMFCでは隠蔽しきれない。
トレース用のDEBUG_NEWマクロによるnewキーワードの置換など、標準規格違反を犯している。