MFC, WTL, WPF, wxWidgets, Qt, GTK 의 특징은 무엇입니까?

WTL 은 프레임워크가 아닙니다. 단지 제네릭으로 Win API 층을 캡슐화했을 뿐, 디자인 아이디어는 MFC 의 영향에서 벗어나지 않았다. 실제로 제네릭을 UI 로 사용합니다.

프레임워크는 일종의 행동예술일 뿐, 계속 발전하면 소용이 없게 된다. 예를 들면 코드가 너무 복잡하고, 컴파일이 너무 느리며, 디버깅이 어렵다.

그리고 포장이 불완전하고, HWND HDC 와 같은 것들이 곳곳에서 볼 수 있습니다.

주요 용도는 작은 프로그램을 작성하거나 다른 UI 프레임워크의 백엔드 구현 부분으로 사용하는 것입니다. 예를 들어, 설치 제거 프로그램을 설치하는 작은 프레임워크를 썼는데, 아주 작고 관리 창을 만드는 부분은 WTL 입니다.

MS-VisualC++ 용 클래스 라이브러리 (Microsoft Foundation Class 의 약어)

고급 Win API 패키지입니다. WTL 패키지보다 더 철저해서 HWND 를 보기 힘듭니다.

HDC 는 고급 컨트롤, 범용 컨테이너, 입출력 액세스, 네트워크 프로토콜 등 다양한 유틸리티 클래스도 제공합니다. 또한 다음과 같은 몇 가지 기본 프레임워크를 제공합니다

Document/View 는 MVC 의 간소화된 버전으로 MV 만 있지만 데이터 관리 및 메시지 전송에 제약이 없어 Doc/View 가 난잡하게 되었습니다.

젠장. 특히 이벤트 처리 모델의 경우 메시지 매핑은 간단하고 오류가 발생하기 쉬운 방법이며, 유일한 장점은 성능이 좋다는 것입니다. VC++ 에서

MFC 가 1 에 등장했습니다. X 당시 전체 UI 커뮤니티의 디자인 아이디어는 비교적 뒤떨어졌고 (애플은 제외), MFC 는 vc++ 와 같은 무거운 호환 부담을 지고 있었다.

1.52 의 MFC 프로그램은 vc2003 에서 약간 수정하여 컴파일할 수 있으며, 이로 인해 MFC 는 후기에 개발되지 않고, 단지 오래된 사고방식을 따라 일부 세부 사항을 개선하고 일부 구성 요소를 추가했지만, 근본적인 설계가 있었다.

문제가 개선되지 않았다.

언어적자를 먹은 GTK, C 로 대상 지향을 쓰는 것은 정말 고통스럽다. 사상적으로는 MFC 보다 선진적이지만, 쓴 코드는 MFC 보다 훨씬 수다스럽다. MFC 보다 이벤트 처리에 더 많은 레이아웃과 신호/슬롯 개념이 있습니다.

WxWidgets,

이는 기본적으로 플랫폼 간 MFC 로, 플랫폼 간 차이를 추상화합니다. 사실, 대부분의 백엔드는 플랫폼 기본 API 에 의해 구현되며, 많은 컨트롤은 시스템 직접 기본입니다. 있다

WxWidgets 는 다음과 같은 용도로 사용됩니다

GTK+ 버전, 백엔드는 GTK+, wxWidgets 는 셸입니다. 이것이 wxWidgets 의 장점이기도 합니다. WxWidgets 컴파일된 프로그램 배포 패키지는 비교적 작고 성능이 좋습니다.

이것들은 모두 90 년대 UI 프레임워크의 기술적 측면으로, 지금까지 큰 진전이 없었다.

먼저 2 1 세기의 기술에 대해 이야기하겠습니다.

Qt,

90 년대에도 나왔지만 20 세기에는 큰 발전이 있었다. 출발점이 비교적 높다고 말해야 한다. 처음부터 크로스 플랫폼을 포지셔닝하는 것은 단순한 패키징 시스템 API 에 만족하지 않고, 오히려

전체 API 와 프레임워크를 직접 만들고 시스템 API 를 교체하기 위해 UI 를 만드는 것이 아니라 APP 개발에 사용되는 네트워크, 데이터베이스, 멀티미디어를 포함한 모든 것을 포함합니다.

스크립트 엔진 등. Signal/slot 은 Qt 에서 발명한 것으로 C++ 언어가 이벤트 알림 모델에서 가장 잘 구현됩니다. 심지어 C++ 표준에 써야 한다고 생각했는데 C++ 위원회도 고집이 센 것 같아요.

우리는 결코 GUI 를 쓰지 않는다.

초기 QT 에는 DirectUI 라는 개념이 없었고, 각 Q 위젯마다 기본 창이 하나씩 있었습니다. Qt4.4 부터 최상위 레벨만 있습니다.

QWidget 은 기본 창이고 하위 Widget 은 이질적입니다.

위젯은 기본 창에 해당하지 않는 추상 레이어일 뿐, DirectUI 의 개념을 구현하며, 창 계단식 투명도 효과와 같은 많은 그래픽 효과가 가능합니다.

QPA(Qt 플랫폼 추상화) 는 4.8 이후 구현되어 Qt 를 쉽게 마이그레이션할 수 있습니다. 현재 Qt 는 플랫폼을 가장 많이 지원하는 프레임워크 중 하나입니다.

초기 권한 부여 문제로 인해 Qt 는 오픈 소스 커뮤니티에 친절하지 않아 LGPL 모델로 바뀔 때까지 홍보가 바람직하지 않습니다. 만약 Qt 가 일찍 버텨낼 수 있다면, wxWidgets 는 생존공간이 없을 것 같다.

QT 에도 몇 가지 단점이 있습니다. 너무 크지만 스스로 자를 수 있습니다. 배포 패키지를 압축한 후 Qt 라이브러리를 2.5MB 로 자를 수 있습니다.

WPF,

마이크로소프트가 이겼어요

Form 의 생각이 막다른 골목에 들어간 후, 나는 마침내 올바른 방식으로 UI 라이브러리를 개발하기로 결심했다. 2 1 세기의 UI 는 분명히 이미 정의되었고, 결코 코드로 쓸 수 없기 때문에 XAML 이 원인이다.

강력한 정의 도구는 UI 레이아웃을 정의할 뿐만 아니라 그래픽 애니메이션 효과 및 메시지 응답 방법도 포함할 수 있습니다. 우수한 언어인 C# 으로 더욱 강력해졌습니다. 하지만 문제는 분명합니다. 너무 큽니다.

개발에는 방대한 IDE 와 디자인 도구뿐만 아니라 발표된 설치 패키지도 방대하기 때문에 현재 그와 함께 범용 소프트웨어 클라이언트를 쓰는 사람은 거의 없으며, 대부분 기업 프로젝트를 할 때 전용 클라이언트를 쓰는 경우가 많다.

약 4 ~ 5 년 전, 저는 WPF 로 QQ 를 썼는데, 기본 기능만으로는 C++ 클라이언트보다 훨씬 크고 느리게 실행되었습니다. 주로 메모리 소비가 너무 많았는데, 당시 WPF 최적화가 충분하지 않았습니다.

마지막으로, 나는 UI 쿠의 진정한 왕 코코아를 보충하고 싶다.

애플의 성공에는 여러 가지 이유가 있는데, 그 중 하나는 코코아이다. 코코아의 이념은 매우 앞서서 아주 일찍 나왔다. 나는 Qt 와 WPF 가 코코아에서 많은 생각을 가지고 있다고 의심한다.

명시적 UI 는 xib 를 통해 UI 의 대부분의 세부 사항을 정의할 수 있으며, 바로 볼 수 있는 시각적 디자인 도구를 제공합니다.

엄격한 MVC, 그리고 정의가 매우 명확하고 분업이 명확하다.

Signal/slot, 이 이름은 아니지만, 아이디어는 마우스를 드래그하여 연결할 수 있다는 것입니다.

ARC, 클로저 및 반사가 제공되어 UI 개발에 큰 편의를 제공합니다. 물론 Objective-C 언어 덕분입니다.

Borland 의 부엉이와 VCL 을 더했습니다.

저는 Borland C++3.0 과 델파이1.0 을 사용하기 시작했습니다. 당시 Borland 는 매우 유망해 보였다. 불행히도, 일련의 의사결정 실수로 인해 회사는 현재 거의 사라지고 있다. 학생들은 더 이상 이 구덩이로 뛰지 마라.

OWL 은 MFC 와 경쟁 관계에 있었고 디자인 아이디어도 비슷했습니다. 개인적으로는 OWL 의 API 디자인이 더 우아하다고 생각하지만, OWL 은 시장에서 MFC 에 의해 완전히 패배했다.

델피

RAD (Rapid Application Development) 분야에서는 BS 아키텍처가 CS 아키텍처를 대체할 때까지 오랫동안 적수가 없었습니다. 델파이는 간단하고 개발 속도가 빠른 것이 특징이다. 기본적으로 사용할 수 있는 앱을 간단히 쓰다.

말하자면, 지금까지 그보다 더 빠른 것은 없을지도 모르지만, 단점은 추함이다. 기본적으로 대부분의 델파이 앱은 컨트롤 더미로 쌓여 있어 보기 좋지 않다. 또한 파스칼 언어의 제한으로 인해 일치시킬 수 없습니다.

많은 C/C++ 코드 융합이 있습니다. C++

Builder, 하지만 Builder 에서 간단하고 빠른 장점은 사라졌습니다. Borland 의 C++ 컴파일러가 점점 더 나빠지면서 오픈 소스 프로젝트는 이 컴파일러와 호환되지 않습니다.

VCL 은 완전히 UI 라이브러리가 아니라 COM ActiveX 와 유사한 구성 요소 인터페이스 사양 세트입니다. Delphi 와 C++builder 는 모두 이 사양을 기반으로 기본 라이브러리를 구축합니다.

UI 라이브러리는 몇 권의 책에서 토론할 수 있는 큰 화제이다. 나는 단지 내 감정을 여기에 썼을 뿐이다.

각 라이브러리의 장점과 단점을 단순히 논의하는 것은 의미가 없습니다. 특정 응용 프로그램 장면에 넣으려면 각 라이브러리에는 좋은 장면이 있습니다.

Windows 의 작은 프로그램만 추구하고 WTL 로 단점을 실현하면 시각 효과가 오히려 흐흐흐흐흐흐흐흐흐흐흐흐흐흐흐흐흐흐흐흐흐흐.

더 크고 더 잘 볼 수 있다면, 그것은 Qt 입니다.

크기에 전혀 신경 쓰지 않는다면, 시각적인 효과만 화려하면 WPF 를 사용하세요. 개발 도구의 가격도 고려한다면 토호들은 WPF 를 선택할 것이다.

MFC 는 기존 엔지니어가 다른 것을 사용할 수 없거나 역사적인 레거시 코드를 사용할 수 없는 한 닭갈비입니다.

크로스 플랫폼이 필요한 경우 Qt, wxWidgets, GTK+ 는 현재 Qt 에 비해 장점이 없습니다.

IOS 안드로이드라면 게임을 쓰지 않는 한 기본 UI 라이브러리를 사용하는 것이 좋습니다.