두 도서관이 시간에 따라 어떻게 시작되고 진화했는지를 되돌아 보면 귀하의 질문에 대한 대답은 대부분 역사적이라고 생각합니다.
짧은 대답은 "멋진"일을하지 않는다면 ATL을 사용하는 것입니다. COM이 포함 된 간단한 사용자 인터페이스에 적합합니다.
긴 대답 : MFC는 90 년대 초에 C ++라는이 새로운 언어를 사용해보고 Windows에 적용하기 위해 만들어졌습니다. OS에 아직 기능이 없었을 때 개발 커뮤니티에서 Office와 같은 기능을 사용할 수있게되었습니다.
[장식 편집 : Microsoft에서 일하지 않았기 때문에 Office가 MFC를 기반으로 구축되었는지는 모르겠지만 대답은 '아니요'라고 생각합니다. Win 3.1, Win 95 일로 돌아가서 Office UI 팀은 새로운 컨트롤을 발명하고 라이브러리에 패키징 한 다음 Windows 및 MFC 팀은 재배포 가능한 dll을 사용하여 해당 컨트롤에 래퍼와 API를 통합했습니다. 나는 그 팀들 사이에 약간의 협력과 코드 공유가 있었다고 생각합니다. 결국 이러한 컨트롤은 서비스 팩 또는 다음 Windows 버전의 기본 운영 체제가됩니다. 이 패턴은 Office가 출시 된 후 추가 기능 구성 요소로 Windows에 추가 된 Office 리본에서 계속되었으며 현재 Windows OS의 일부입니다.]
그 당시 라이브러리는 C ++ 언어와 컴파일러가 새롭고 Office가 발전함에 따라 시간이 지남에 따라 Microsoft가이를 구축했기 때문에 매우 원시적이었습니다.
이 역사 때문에 MFC는 :
- 상당히 투박한 디자인입니다. Windows API를 둘러싼 가벼운 래퍼로 시작했지만 성장했습니다. 컴파일러와 언어가 지원하지 않았기 때문에 발명해야 할 작은 '기능'이 많이 있습니다. 템플릿이 없었고, 문자열 클래스를 발명했고, 목록 클래스를 발명했으며, 자체 런타임 유형 식별 등을 설계했습니다.
- 20 년 동안의 Office 및 Windows 진화를 요약합니다. 여기에는 단일 및 다중 문서 인터페이스, DDE, COM, COM +, DCOM, 문서 연결 및 포함 (단어 문서를 포함 할 수 있습니다.) 원하는 경우 앱), ActiveX 컨트롤 (웹용 개체 임베딩의 진화!), 구조화 된 문서 저장소, 직렬화 및 버전 관리, 자동화 (초기 VBA 년부터) 및 물론 MVC. 최신 버전은 Visual Studio 스타일 창 도킹 및 Office 리본을 지원합니다. 기본적으로 20 년 동안 레드몬드에서 나온 모든 기술은 어딘가에 있습니다. 그것은 단지 거대합니다!
- 사소한 문제, 버그, 해결 방법, 가정, 사용하지 않을 것들에 대한 지원이 많이 있으며 문제를 유발합니다. 많은 클래스의 구현과 적절한 크기의 프로젝트에서이를 사용하기 위해 상호 작용하는 방법에 대해 잘 알고 있어야합니다. 디버깅 중에 MFC 소스 코드를 조사하는 것은 일반적입니다. 일부 포인터가 null 인 15 년 된 기술 노트를 발견하면 여전히 충돌이 발생합니다. 고대 문서 임베딩 항목의 초기화에 대한 가정은 애플리케이션에 이상한 방식으로 영향을 미칠 수 있습니다. MFC에는 추상화와 같은 것이 없습니다. 매일 기이하고 내부적으로 작업해야합니다. 아무것도 숨기지 않습니다. 그리고 수업 마법사를 시작하지 마십시오.
ATL은 C ++ 언어가 발전함에 따라 발명되었고 템플릿이 도착했습니다. ATL은 MFC 라이브러리의 런타임 문제를 방지하기 위해 템플릿을 사용하는 방법을 보여줍니다.
- 메시지 맵 : 템플릿 기반이므로 유형이 확인되며 바인딩 된 함수를 망가 뜨리면 빌드되지 않습니다. MFC에서 메시지 맵은 매크로 기반이며 런타임에 바운드됩니다. 이로 인해 이상한 버그가 발생하거나 메시지가 잘못된 창으로 전달되거나, 함수 나 매크로가 잘못 정의 된 경우 충돌이 발생하거나, 무언가가 제대로 연결되지 않아 작동하지 않을 수 있습니다. 디버그하기가 훨씬 더 어렵고 눈치 채지 못한 채 깨지기 쉽습니다.
- COM / 자동화 : 메시지 맵과 유사하게 COM은 원래 매크로를 사용하여 런타임에 바인딩되었으므로 많은 오류 처리가 필요하고 이상한 문제가 발생했습니다. ATL은 템플릿 기반, 컴파일 시간 제한 및 처리하기 훨씬 쉽게 만들었습니다.
[편집 편집 : ATL이 만들어 졌을 때 Microsoft의 기술 로드맵은 주로 '문서 관리'에 중점을 두었습니다. 애플은 데스크톱 출판 사업에서 그들을 죽이고 있었다. 오피스 '문서 연결 및 임베딩'은이 공간에서 경쟁하기 위해 오피스의 '문서 관리'기능을 강화하기위한 주요 구성 요소였습니다. COM은 응용 프로그램 통합을 위해 개발 된 핵심 기술이었으며 Document Embedding API는 COM을 기반으로했습니다. MFC는이 사용 사례에 사용하기 어려웠습니다. ATL은 타사가 COM을 구현하고 문서 임베딩 기능을 활용하기 위해이 특정 기술을보다 쉽게 만드는 좋은 솔루션이었습니다.]
이러한 작은 개선으로 인해 MFC의 기능과 같은 모든 사무실이 필요하지 않은 간단한 응용 프로그램에서 ATL을 훨씬 쉽게 처리 할 수 있습니다. 간단한 UI와 일부 Office 자동화 기능이 포함되어 있습니다. 작고 빠르며 컴파일 시간이 제한되어 많은 시간과 골칫거리를 절약 할 수 있습니다. MFC에는 투박하고 작업하기 어려운 거대한 클래스 라이브러리가 있습니다.
불행히도 ATL이 정체되었습니다. Windows API 및 COM 지원을위한 래퍼가 있었지만 실제로는 그 이상으로 넘어 가지 않았습니다. 웹이 등장했을 때이 모든 것들은 오래된 뉴스로 잊혀졌습니다.
[장식 편집 : Microsoft는이 '인터넷 사물'이 커질 것임을 깨달았습니다. 그들의 기술 로드맵은 분산 트랜잭션 서버의 Internet Explorer, Windows Server, IIS, ASP, SQL Server, COM / DCOM에 초점을 맞추기 위해 크게 변경되었습니다. 따라서 문서 연결 및 포함은 더 이상 높은 우선 순위가 아닙니다.]
MFC의 거대한 발자국으로 인해 덤프가 불가능했기 때문에 여전히 천천히 진화합니다. 템플릿은 라이브러리에 다시 통합되었으며 다른 언어 및 API 개선 사항도 있습니다. (이 질문을 볼 때까지 WTL에 대해 들어 본 적이 없습니다. :)
궁극적으로 어떤 것을 사용할지는 단순히 선호도의 문제입니다. 필요한 기능의 대부분은 기본 OS API에 있으며, 라이브러리에 적절한 래퍼가없는 경우 두 라이브러리에서 직접 호출 할 수 있습니다.
수년 동안 MFC를 사용하여 2 센트 만 사용했고 지금은 매일 사용합니다. 나는 ATL이 몇 년 동안 몇 개의 프로젝트에서 처음 출시되었을 때 가볍게 두들 겼다. 그 당시에는 신선한 공기의 숨결 이었지만 실제로는 어디에도 가지 않았습니다. 그리고 나서 웹이 등장했고 나는 그것에 대해 모두 잊었습니다.
편집 :이 답변은 놀라운 수명을 가지고 있습니다. 내 스택 오버플로 페이지에 계속 팝업되므로 부족하다고 생각한 원래 답변에 약간의 장식을 추가 할 것이라고 생각했습니다.