[include(틀:다른 뜻1, other1=다른 의미, rd1=MFC(동음이의어))] [include(틀:마이크로소프트)] {{{+3 '''__M__'''icrosoft '''__F__'''oundation '''__C__'''lasses}}} [[http://msdn.microsoft.com/en-us/library/d06h2x6e.aspx|MSDN의 MFC 페이지]] [목차] == 개요 == [[Microsoft Windows]] 운영체제 환경에서 작동하는 [[GUI]] 응용프로그램을 개발하기 위한 [[C++]] 언어 기반의 라이브러리로, 1992년 발표되었다. [[Windows API]]의 [[C언어]] 함수들을 Wrapping 하여 C++ 언어의 클래스화 한 [[라이브러리]]이다. 윈도우 환경에서 COM(Component Object Model) 개발을 위한 라이브러리인 [[ATL]](Active Template Library)과 CString 등의 기반 클래스를 공유하는 등 매우 밀접한 관련이 있다. 별도의 라이브러리 없이 윈도우즈용 GUI 응용프로그램을 개발하려면 운영체제가 제공하는 [[C언어]] 기반의 [[Windows API]]를 써야 하는데, 단순히 운영체제의 여러 기능들을 노출시켜주는 C 함수들의 집합일 뿐이기 때문에 복잡한 UI를 작성하는 등의 고차원적인 작업을 할때에는 필연적으로 코드 노가다가 수반된다. 그리고 최신의 윈도 컨트롤과 같은 고차원적인 기능들은 [[Windows API]]가 아닌 [[COM]] 라이브러리로만 쓸 수 있기 때문에 [[Windows API]]만으로는 한계가 있다. 그래서 이걸 그나마 좀 편하게 클래스 형태로 쓸 수 있도록 해주는것이 바로 MFC이다. [[비주얼 스튜디오]]의 유료 버전과 Community(개인사용자용)에는 기본으로 포함되어 있다. 무료인 'Express' 버전에는 MFC와 ATL이 포함되지 않는다. == 사용 목적 == [[Microsoft Windows]]용 GUI 응용프로그램을 개발하기 위해 사용된다. [[C언어]]기반의 [[Windows API]]를 직접 사용할 수도 있으나, [[C++]]언어 기반의 MFC를 사용할 경우 보다 구조적이고 간편하며 대규모의 어플리케이션 개발이 용이하다. 90년 초반부터 2000년 중반 사이의 윈도우즈용 GUI 응용프로그램 개발을 위한 라이브러리로 널리 사용되었다[* 비슷한 시기 대체제로는 Object Pascal 언어 기반의 [[델파이]]와 [[Visual Basic]]이 있었다.]. 현재는 과거 개발된 어플리케이션의 유지보수가 주된 용도이다. [[웹]]과 [[모바일]]환경이 대두되었을 뿐만아니라, 데스크톱 응용프로그램의 개발 환경도 [[.NET Framework]]를 기반으로 하는 WinForms, WPF 등과 웹을 기반으로 하는 [[The Chromium Projects#Electron|Electron]] 등이 등장하면서 더이상 신규개발에서 MFC는 타당한 선택지가 아니게 되었다. MS에서 개발하는 프로그램 중 [[Microsoft Office]]나 윈도 운영체제 자체 등 일반 사용자에게 제공되는 제품은 MFC를 사용하지 않는다. MFC를 사용하여 개발된 것 중 가장 유명한 것은 [[Visual Studio]] 6.0에 포함되어 있는 Visual C++ 6.0 IDE일 것이다. 하지만 [[.NET Framework]]가 발표되면서 현재의 Visual Studio는 닷넷의 WPF로 개발되고 있다. 사실 MFC를 사용하는 가장 큰 이유는 [[경로의존성|줄곧 Visual Studio에 포함되어 있었기 때문]]이라는 말이 있다. 더 좋은 라이브러리들이 존재하지만(혹은 존재를 잘 몰라서) 굳이 찾지 않고 포함되어 있는 것을 사용한다는 것. 근거 없는 말이 아닌 것이, 타인에게 작업물을 전달한다거나, 라이브러리를 GUI 예제 프로그램과 함께 외부 공개한다거나 할 때에는 MFC의 경우 비주얼 스튜디오 버전만 맞춰주면 보통 별 문제가 없지만, 비주얼 스튜디오에서 기본지원하지 않는 외부 기술을 사용했을 경우에는 그것에 대한 설치와 설정방법도 함께 제공해야 하는데 이것이 귀찮기 때문이다. == 단점 == * [[비주얼 스튜디오]] 2019 버전에서도 여전히 사용 가능하나, 메이저 버전은 비주얼 스튜디오 2015 시절의 MFC 14에서 멈춰있고 마이너 업데이트만 제공되는 상황이다. 2015년 이후 MFC를 새로 공부하는것은 시간낭비이다. * 순수하게 C언어로 Win32 API를 사용하여 개발한 프로그램에 비하면 무겁다. 물론 [[Qt(프레임워크)|Qt]]나 GTK+와 비교한다면야... * ATL과 공유되는 CString, CList 등의 클래스는 매우 강력하지만, GUI를 위하여 제공되는 기능은 Windows API의 매우 얇은 Wrapper 정도이다. 게다가 MFC로 개발한다고 해서 Windows API를 쓰지 않을 수도 없다. * Visual C++ 2008 Feature Pack에서 추가된 리본 인터페이스는 [[Microsoft Office]]와 비교해 보면 매우 엉성하고 조잡한 티가 난다. 이는 해당 클래스들이 MS에서 제작된 것이 아니라 타사([[http://www.bcgsoft.com/]])에서 제작한것을 MS가 구입하여 포함시켰기 때문이다. * GUI 디자인 기능이 매우 부실하다. 직접 UI를 그려서 설계할 수 있는 부분은 "윈도 리소스"라는 매우 특이한 형식으로 처리되는 '''다이얼로그(대화상자)'''만 가능하며, 일반적인 화면은 직접 코드로 구현해야 한다. VB6.0이나 닷넷의 WinForm/WPF, Qt의 QtDesigner 등과 비교하면 이뭐병 소리가 절로 나온다. * 닷넷 출시 이후로 MS로부터 버려졌다는 소문이 있다. 실제로 VS2008 이후부터 MFC에 큰 변화가 없어졌고, VS2012까지는 MFC가 탑재되어 릴리스 되었지만 VS2015부터는 따로 패키지를 설치해서 사용해야 한다. * 지난 몇년 새 MFC에 속한 라이브러리 수가 굉장히 방대해져서 현재는 MS에서 MFC를 유지/개보수하는 AFX 팀에서도 포기했다고 할 정도로 여러 면에서 꼬였다고 한다. MFC 프로젝트를 만들 때 작성되는 설정들이 제대로 설정되지 않는다던지, 리소스를 수정한 후 코드창에서 저장을 하면 리소스 헤더파일의 인코딩이 문제가 된다던지... 각종 오류가 난무하는 중. 이러한 문제로 MS/AFX 팀이 신랄하게 까이지만 그들도 인간인지라 어쩔 수 없는 부분[* AFX 팀에서 관리하는 함수가 얼마나 많냐면 윈도우가 한번 업그레이드 되었을 때, MFC는 반년 뒤에 업그레이드가 될 정도라고 하니...]이다. C++ 언어와 윈도우 운영체제에 대한 이해가 있다면 못 써먹을 정도의 물건은 아니다. MFC는 C++ 라이브러리이며, 윈도우 운영체제를 다루기 위한 것이므로 이 둘에 대한 선행 학습이 이루어져야 한다. 하지만 MFC의 클래스/함수/변수들의 네이밍 센스, Visual Studio가 자동 생성해주는 Template들의 구조는 정말 최악이다. 그런 코드들에 물들면 [[스파게티 코드]]가 탄생한다. 그리고 MFC는 C++ 표준에서 벗어난 MS의 비표준 함수들을 굉장히 많이 사용하기 때문에, 이런 코드가 많아지면 차후 다른 프레임워크나 컴파일러를 사용할 수 있는 여지도 없어진다. == 대안 == 윈도우 응용프로그램을 만들기 위해 반드시 Win32 API 또는 MFC를 사용해야 하는 것은 아니다. * [[C++]]를 사용해 강력하고 다양한 기능을 가진 UI를 개발하고 싶은가? * 그렇다면 [[Qt(프레임워크)|Qt]] 라이브러리를 사용해 보자. * Qt는 Windows, macOS, Linux를 모두 지원하는 C++ 프레임워크로, 단순한 GUI 라이브러리가 아니라 자체적으로 네트워크, 파일 및 DB 처리, XML 지원, 강력한 String 클래스 등 방대한 기능들을 가지고 있다. * 윈도우 시스템 함수를 호출하는 것도 가능하다.[* 당연하겠지만 윈도우 외 운영체제에서는 사용 불가능하다.] * 한번만 써 보면 MFC의 다이얼로그 편집기는 쓰레기로 보이게 될 GUI Designer를 제공하며, 비주얼 스튜디오와 훌륭히 연동된다. [[http://qt-project.org/|홈페이지]] * [[닷넷]]의 WPF와 비슷한 QtQuick을 제공한다. [[http://blog.qt.digia.com/blog/category/qml_start/|QML을 시작합니다.]] * C++ Builder는 훌륭한 GUI 개발 환경을 가진 [[통합 개발 환경|IDE]]이며, C++를 이용하여 동일한 편의성을 누릴 수 있다. 다만 사용률이 적어 자료를 찾기가 힘들다. 또한, IDE가 한국어팩을 지원하지 않으므로 영어에 익숙하지 않으면 개발하는데 시간이 걸릴 수 있다. * [[리눅스]]에서 빛나는 크로스폴랫폼을 지원하는 GTK가있다. C,C++,Python,C#과유사한Vala등을 모두지원한다. [[wxWidgets]]도 있다. * 다른 언어는 어떤가? 반드시 C++를 사용할 필요가 없다면? * [[.NET Framework]] 플랫폼에는 Windows Forms와 WPF의 두 가지 GUI 라이브러리가 포함되어 있다. Windows Forms는 쉬운 난이도 덕분에 초보자가 접하기에도 용이하다. 또한 [[C\#]]은 [[C++]]과는 비교도 되지 않는 높은 생산성을 자랑하는 언어이다. 기존 윈도용 C/C++ 프로젝트나 라이브러리와의 연동도 수월하므로 일단 핵심 코드는 그대로 둔 채 껍데기부터 차차 교체할 수도 있다. 닷넷 프레임워크로 개발된 프로그램의 대표작이라면 [[비주얼 스튜디오]] 중 2008 이후의 버전들(WPF로 개발되었다)을 들 수 있을 것이다. 커다란 용량의 닷넷 런타임 배포가 부담스럽다면, 개인적으로 사용하는 프로그램의 개발에서부터 활용해 보자. 또한 웹 인스톨러 등을 이용하거나 인스톨러가 닷넷 설치 웹사이트를 띄워주는 등의 방법으로 배포에 대한 부담을 줄일 수도 있다. 어차피 윈도우 7부터는 닷넷 프레임워크 3.5가, 윈도우 8부터는 4.5가 기본적으로 포함돼 있기도 하고, [[카탈리스트(소프트웨어)|ATI 카탈리스트]] 컨트롤 센터처럼 장치 드라이버 관련 유틸리티가 닷넷 기반으로 개발되기도 하는 등, 완전히 닷넷이란 것과 담을 쌓다가 갑자기 설치해야 되는 일은 많이 줄어들었다. * [[Python]]은 Tcl/Tk, PyQt, PyGTK 등 다양한 GUI 라이브러리와의 연결 기능을 제공한다. * [[Java]]에는 JavaFX와 SWT[* [[이클립스(통합 개발 환경)|이클립스]]에서 사용된다. [[http://www.eclipse.org/swt/|홈페이지]]], SwingX 등의 GUI 라이브러리가 존재한다. AWT나 Swing은 MFC와 비슷한 개발 난이도를 자랑하기에 별로 추천하지는 않는다. * [[파스칼(프로그래밍 언어)|파스칼]] 언어를 사용하는 [[파스칼(프로그래밍 언어)#델파이|델파이]] 환경은 MFC와 얼마 차이나지 않는[* 1995년 최초 공개되었다] 역사를 자랑하지만, [[macOS]]와 [[Linux]] 뿐만 아니라 [[안드로이드]], [[iOS]] 환경도 지원하며 [[RAD]] 툴로서 빠르게 강력한 GUI 개발이 가능하다. * [[The Chromium Projects#Electron|Electron]]을 사용하면 [[HTML]] + [[CSS]] + [[JavaScript]]([[Node.js]])로 데스크톱 환경을 만들 수 있다! 당장 [[Atom(에디터)|Atom]]과 [[비주얼 스튜디오 코드]]가 실기로 나와 있다. 단점은 구현 방식이 일단 브라우저 하나를 띄워놓고 시작하는 것이기 때문에 기본 용량이 크고 퍼포먼스가 떨어진다는 점. 이 부분은 PC의 평균 스펙이 올라가면 차차 해결될 듯하다. 위에서 예로 든 닷넷 플랫폼과 비교했을 때, 다양한 운영체제를 지원하는 크로스플랫폼 프레임워크라는 것이 상당한 장점이다. 필요하다면 프론트엔드에만 Electron을 쓰고, [[Inter-Process Communication|IPC]]와 [[FFI]] 혹은 [[WebAssembly|wasm]]을 이용해 백엔드는 C/C++ 등으로 대체하는 것도 가능하다. MS가 [[GitHub]]를 인수한 이후부터는 이 Electron을 밀어주고 있다. * 2010년대의 대세인 웹을 통해 UI를 구현할 수도 있다. 서버 통신이 필요없는 로컬 프로그램인데도 웹으로 구현된 애플리케이션이 점점 늘어나고 있으며, 시스템을 만져야 하거나 퍼포먼스가 필요한 부분은 따로 웹 API 서버 노릇을 하는 서비스 프로세스로 분리시킨 뒤 UI와 통신하는 식으로 해결한다.[* 위에 서술된 일렉트론도 내부적으로는 이런 구조이다.] 일례로 크루셜의 SSD 관리 프로그램([[http://www.crucial.com/usa/en/support-storage-executive|Crucial Storage Executive]])이 이런 식. 기존 프로그램의 UI와 코어부가 잘 분리돼 있다면 생각해볼만 하다. [[분류:라이브러리]][[분류:Microsoft]]