Qt로 더 많은 데스크탑 앱이 작성되지 않는 이유는 무엇입니까? [닫은]


202

Qt에 대한 경험을 알고 이해 한 한, 매우 훌륭하고 배우기 쉬운 라이브러리입니다. API는 매우 잘 디자인되어 있으며 크로스 플랫폼이며,이 기능은 매력적인 여러 기능 중 두 가지에 불과합니다. 더 많은 프로그래머가 Qt를 사용하지 않는 이유를 알고 싶습니다. 그것에 대해 말하는 결함이 있습니까? Qt보다 다른 라이브러리를 더 잘 만드는 기능은 무엇입니까? 라이센스 관련 문제입니까?


60
네이티브 C ++입니다. 대부분의 개발자는 C #과 같은 고급 언어를 선호합니다.
user16764

15
이전 버전과의 호환성을 겸비한 양날의 칼은 Qt에 많은 시대적 변화, 고칠 수없는 결함 및 기타 열악한 행동을 남겼습니다.
edA-qa mort-ora-y

26
@ user16764 : "가장 많이"?
궤도에서 가벼움 경주

17
TIOBE 지수는 사용이 아니라 인기를 측정하기 때문에 실제로 정확한 척도라고 생각하지 않습니다. GitHub, Bitbucket, Codeplex 및 Sourceforge와 같은 오픈 소스 리포지토리의 코드 양을 비교하면보다 정확한 측정 결과를 얻을 수 있습니다. (그리고 더 정확한 측정은 C와 C ++를 # 1과 # 2 지점에 넣었다고 생각합니다. Java는 신입생 대학 과정에 사용되기 때문에 TIOBE 지수에 불공평 한 이점이 있으며, 새로운 프로그래머는 경험이있는 사람보다 더 많은 붐을 일으 킵니다)
Billy ONeal

12
@ Giorgio : 음, C #에서 그런 것들에 대해 생각해야합니다. "누가 이것을 소유 하는가"라는 개념은 "누가 부르는가"를 훨씬 뛰어 넘습니다 delete. 똑똑한 포인터가 명시 적이라는 사실은 언어 실패가 아닙니다. 그리고 그런 것들에 대해 생각하지 않는다면 당신은 내가 본 고급 언어로 쓰레기를 생성 할 것입니다.
Billy ONeal

답변:


177

나는 이것이 실제로 bashing 답변이 아니라고 생각하지만 이것이 개인적으로 Qt를 사용하지 않는 이유입니다. 그것에 대해 말할 좋은 점이 많이 있습니다. 즉, API가 대부분의 시간 동안 작동하며 플랫폼을 매끄럽게 연결합니다. 그러나 Qt를 사용하지 않습니다.

  1. 어떤 경우에는 네이티브 프로그램처럼 보이지 않습니다. 다양한 시각적 스타일링으로 인해 모든 플랫폼에 단일 UI를 설계하는 것은 본질적으로 기계에서 기계로 이동할 때 제대로 보이지 않습니다. 예를 들어, Mac 컴퓨터에서 분할 막대는 일반적으로 비교적 두껍고 버튼은 작고 아이콘이 둥근 형태입니다. Windows 시스템에서 분할 막대는 일반적으로 좁고 버튼은 더 정사각형 디자인으로 텍스트가 더 많습니다. 모든 플랫폼에 대해 하나의 UI를 작성할 수 있다고해서 대부분의 응용 프로그램에 필요한 것은 아닙니다.
  2. Qt는 C ++ 라이브러리가 아닙니다. 별도의 컴파일 단계가 필요하므로 대부분의 다른 라이브러리와 비교할 때 빌드 프로세스가 훨씬 복잡합니다.
  3. (2)의 결과로 C ++ IDE 및 도구는 Qt의 특성을 이해하지 못하므로 Qt 표현식을 오류로 플래그 할 수 있습니다. 이것은 거의 QtCreator 또는와 같은 텍스트 전용 편집기를 사용하도록 강요합니다 vim.
  4. Qt는 많은 양의 소스이며 컴파일하기 전에 사용하는 모든 머신에 존재하고 사전 설치되어 있어야합니다. 이것은 빌드 환경을 훨씬 더 지루하게 만들 수 있습니다.
  5. LGPL 하에서 만 사용 가능하므로보다 제한적이거나 덜 제한적인 라이센스로 릴리스해야 할 경우 단일 이진 배포를 사용하기가 어렵습니다.
  6. 유사하게 작성된 "plain ol '기본 응용 프로그램"(KDE 용으로 작성된 응용 프로그램 제외)과 비교할 때 컴파일 된 바이너리가 매우 큽니다.

11
@Dehumanizer : LGPL 라이센스와 상업용 라이센스가 있습니다. 상업용 라이센스는 라이센스 사용자의 일부로 수천 달러이며 재배포 등을 허용하지 않습니다. BSD, MIT 또는 Boost와 같은 자유 라이센스의 오픈 소스 프로젝트의 경우 작성자가 많은 돈을 벌지 않고 원하는 경우 자유 라이센스 하에서 코드를 릴리스하기 위해 LGPL에 대한 의존은 불합리하지만 문제의 개발자는 일반적으로 상용 라이센스를 감당할 수 없습니다.
Billy ONeal

27
# 6는 내가 피하는 가장 큰 이유입니다. 나는 크고 복잡한 프로그램을 원하지 않고 특정 라이센스에 구속되는 것을 좋아하지 않지만, 실제로는 나에게는 거래를 방해하는 좋은 기본 모양과 느낌이 부족합니다. 최신 버전의 OSX와 Windows는 특히 기본 인터페이스를 예쁘고 빠르며 기능적으로 만드는 환상적인 작업을 수행했으며, 이미 수행 한 모든 작업을 활용하고 싶습니다. 나는 기본 모양이없는 많은 프로그램이 나에게 저렴하고 해킹 감을 느낀다는 것을 알았습니다 (항상 그런 것은 아니지만 조금 나아지게합니다).
Greg Jackson

16
귀하의 숫자 6은 숫자 1 있었어야이입니다 지금까지 Qt를 가진 가장 큰 문제. 대부분의 경우 단순히 원시 API를 사용하지 않습니다. 나는 내 소프트웨어가 기본적으로 보이기를 좋아합니다. 그런 사용자도. Qt로 만든 Mac 응용 프로그램 인 Mac 응용 프로그램을 본 적이 없습니다. 다른 Mac 사용자도 없으며 그런 종류의 것들에 까다 롭습니다. Linux 응용 프로그램을 작성하는 데에만 사용하는 경우 "크로스 플랫폼"이라는 이점을 모두 잃게됩니다. Linux 응용 프로그램은 기본 응용 프로그램이 없기 때문에 기본 응용 프로그램으로 보이는 곳뿐입니다.
코디 그레이

41
'네이티브'룩의 문제를 제외하고는 더 이상 존재하지 않습니다. Windows 앱의 오래된 일관성은 이제 고유 한 얼룩, 광선 및 애니메이션 WPF 및 silverlight가 제공하는 모든 것의 난폭 화입니다. 오늘날 MS의 주력 제품이 GUI에 일관성이 없는지 확인하려면 Office 또는 Windows 7의 제어판을 살펴보십시오. 맥 사용자-글쎄, 당신은 거기에 매우 유효한 점이 있습니다.
gbjbaanb

5
@TrevorBoydSmith : 죄송합니다. 잘못되었습니다. Qt는 전처리를 사용하는 유일한 프레임 워크입니다. 기간. 그놈, FLTK, WX 및 친구를 확인하고 전처리 단계를 보여주세요. 당신은 하나를 찾을 수 없습니다. 다른 라이브러리는 다른 빌드 시스템과 함께 제공되지만, 결국 C ++ 컴파일러로 빌드 할 수있는 C ++ 라이브러리입니다. "원시 win32이 (가) 존재하지 않는 이유"에 관해서는, 제 이유는 # 5와 # 6입니다.
Billy ONeal

115

사람들이 말했듯이 각 도구는 각 문제와 상황에 적합합니다 ...

그러나 C ++ 프로그래머라면 Qt가 프레임 워크입니다. 라이벌이 없습니다.

우리는 복잡한 의료 이미징 상용 응용 프로그램을 개발하고 Qt는 계속합니다.

나는 사람들이 그것에 대해 말하는 '단점'이 거짓이라고 말하지는 않지만, 그들이 오랫동안 Qt를 시도하지 않았다는 느낌을 가지고 있습니다 (각각의 새로운 버전에서 지속적으로 개선됩니다 ...) 그리고 대부분 그들이 돌보는 모든 문제는 문제가되지 않습니다.

UI 플랫폼 불일치 : UI 위젯을 '있는 그대로'사용하고 사용자 정의 또는 사용자 정의 아트없이 사용하는 경우에만 해당됩니다.

Qt 전 처리기 과부하 : 실제로 필요하지 않은 신호 슬롯 메커니즘 또는 QObject 상속을 남용하는 경우에만 해당됩니다.

그건 그렇고, 우리는 여전히 C # .NET에서 응용 프로그램을 작성하고 오랫동안 수행했습니다. 그래서 나는 멍청한 관점을 가지고 있다고 생각합니다.

내가 말했듯이 각 상황에 맞는 도구는

그러나 Qt는 의심 할 여지없이 일관되고 유용한 프레임 워크입니다.


9
탁크 +1! 나는 단지 같은 것을 쓰고 싶었다. 가장 넌센스는 "비공개 소스 / 상업적 논증"입니다. 놀랍게도, 많은 사람들이 오픈 소스라는 용어를 이해하는 것이 얼마나 잘못입니까. Qt는 그것을 사용한 이후 오픈 소스였습니다 (1.4). 그리고 그것은 가장 공정한 라이센스를 가지고있었습니다 : Qt-> pay로 돈을 버십시오.
Valentin Heinitz

16
아, 그리고 난 정말 예술 50MB의과 : 비디오 자습서 및 데이터의 200 개 매크로 블럭 포함하는 응용 프로그램 10 메가 바이트 DLL을 추가하는 방법에 대해 걱정하지 않는다
Петър Петров을

9
Qt에 필요한 공간은 요즘 저렴합니다.
trusktr

5
이것은 Qt에 대한 나의 경험과 거의 일치합니다 (위젯 프레임 워크, 지금까지 심각한 문제에는 QML / QtQuick을 사용하지 않았습니다). 복잡한 UI 요구 사항으로 큰 응용 프로그램을 작성하는 것이 적합합니다. 일단 배우면 매우 생산적 일 수 있습니다. 빌드 시스템이 올바르게 설정된 경우 언급 된 단점 (mocing, ui 파일 등의 별도 컴파일 단계)은 문제가되지 않습니다. qmake 또는 cmake를 추천 할 수 있습니다.
Nils

Qt 5.8 이후에는 Qt Lite라는 프로젝트가 있습니다.이 프로젝트는 특정 요구에 따라 극도로 Qt를 최소화합니다. 이것은 상업적인 기능입니다.)
SMMousavi

36

Qt에 대해 내가 싫어하는 모든 것 중에서 템플릿과 잘 어울리지 않는다는 사실이 가장 버그가 많습니다. 당신은 이것을 할 수 없습니다 :

template < typename T >
struct templated_widget : QWidget
{
  Q_OBJECT;

public signals:
  void something_happened(T);
};

또한 전처리 기와 잘 작동하지 않습니다. 당신은 이것을 할 수 없습니다 :

#define CREATE_WIDGET(name,type) \
struct name ## _widget : QWidget \
{ \
  Q_OBJECT; \
\
public signals: \
  void something_happened(type); \
}

즉, 신호에 응답하는 모든 것이 Q_OBJECT 여야한다는 사실과 함께 Qt는 C ++ 프로그래머가 작업하기가 어렵습니다. 사람들은 아마도 자바 나 파이썬 스타일 프로그래밍에 익숙 할 것이다.

실제로 유형 안전을 되찾고 Qt 신호를 functor 객체에 연결하는 방법을 연구하고 고안하는 데 많은 시간과 노력을 들였습니다. http://crazyeddiecpp.blogspot.com/2011/01/quest-for-sane-signals -in-qt-step-1.html

내가하고 싶은 일은 Qt moc에 의해 불가능한 옆에있는 기본적이고 일상적인 C ++ 개발입니다.

솔직히 말해서, 자동화 된 UI 테스트를 원한다면 Qt는 MFC가 부족한 도시에서 유일하게 유일한 게임이기 때문에 1980 년입니다 (그래서 정말 열심히 일하는 것입니다). 일부는 WX라고 말할 수도 있지만 더 심각한 문제가 있습니다. GTKmm은 나의 첫 번째 선택 이었지만, 모든 소유자가 작성하고 접근성을 제공하지 않기 때문에 업계 표준 테스트 소프트웨어로 구동 할 수 없습니다. Qt는 그 점에서 충분히 어렵습니다 ( 접근성 플러그인을 수정할 때 거의 작동 하지 않습니다 ).


1
관심이 없다면 WX의 주요 문제점으로 무엇을보고 있습니까?
톰 앤더슨

7
@Tom-특히 새로운 것들에 대한 잘못된 문서. AUI 구성 요소는 큰 섹션이 누락되어 거의 문서화되지 않으므로 프로덕션 환경에서 사용하기가 어렵습니다. 이벤트 프로세스에 대한 문서는 최소한 win32에서 수행되는 경로와 관련하여 근본적으로 오류가 있습니다. 컴퓨터에서 소리를 지르면서 많은 시간을 보냈습니다. "이것은 작동해야합니다 !!!" WX가 문서를 따르지 않고 내가하고있는 일이 결코 작동하지 않는다는 것을 알기 위해 깊은 처리 코드로 들어가기 전에.
Edward Strange

1
또한 속성 그리드 라이브러리를 메인 라인에 수용함으로써 혼란을 겪었습니다. 필자는이 라이브러리를 사용했으며,이를 작성한 프로그래머 (예를 들어 생성자에서 가상 함수라고 함)를위한 지식 부족과 더불어 수많은 기본 설계 결함을 보여주었습니다. 그것과 AUI의 열악한 상태는 열악한 표준 경향을 보여 주었다. 정적 이벤트 테이블을 좋아하는 팬은 아니지만 적어도 이벤트에 응답하는 다른 방법이 있습니다 .WX는 어쨌든 흥미 진진한 MFC와는 다릅니다.
Edward Strange

감사. 나는 그것을 조금만 사용했고 wxPython API를 통해 꽤 좋았습니다. 나는 그것이 악의 일부를 숨길 것이라는 점을 이해할 수 있지만, 나는 더 심각한 문제에 맞서기 위해 깊이 관여하지 않았다는 것을 이해할 수 있습니다. 내가 알아야 할 것.
톰 앤더슨

1
신호에 응답하는 모든 것은 Q_OBJECT 여야합니다. 요즘 아닙니다 ... 이제 정적 함수, 함수 및 람다 함수도 신호에 응답 할 수 있습니다 (함수 포인터를 슬롯으로 사용할 수 있음). 비 QObject 클래스는 std :: bind를 사용하여 연결하여 인스턴스 멤버를 함수 포인터로 변환하면 멤버 슬롯을 가질 수 있습니다.
Vinícius A. Jorge

28

Qt를 사용하지 않는 한 가지 이유는 Windows와 같은 하나의 아키텍처에만 작성하는 경우 C # /. NET (또는 Mac의 Cocoa)을 사용하여 최신 종을 활용할 수 있기 때문입니다. -OS의 휘파람.

크로스 플랫폼 앱을 작성하는 경우 Java와 같은 다른 기술 (예 : "Java Shop"에서 작업)에 이미 많은 투자가있을 수 있습니다. 언어 별 API와 같이 개발중인 에코 시스템에 따라 기술 선택이 결정될 수 있습니다. 이러한 종류의 경우 기술 수를 최소화하는 것이 유리할 수 있습니다.

내가 생각할 수있는 세 번째 이유는 Qt가 C ++을 기반으로하고 있으며 C ++은 프로그래밍하기가 비교적 어렵거나 위험한 언어이기 때문입니다. 전문가 용 언어라고 생각합니다. 최고의 성능이 필요하고 세심한주의를 기울일 수 있다면 C ++은 아마도 여전히 최고의 게임입니다. 실제로 Qt는 범위를 벗어나도록 설정하면 많은 메모리 관리 문제를 개선합니다. 또한 Qt 자체는 많은 C ++ 문제로부터 사용자를 격리시키는 좋은 일을합니다. 모든 언어와 프레임 워크에는 장단점이 있습니다. 일반적으로 식당에서 흔히 볼 수있는 추가, 속도, 품질 및 가격으로 요약 할 수있는 매우 복잡한 문제입니다 (하지만 두 개만 선택할 수 있음).

규칙에 따라 계속 질문에 대답해야한다고 말하지만, Billy ONeal이 제기 한 몇 가지 문제를 반박하고 싶습니다.

  1. Qt는 실제로 C ++ 라이브러리 / 프레임 워크 / 헤더 파일입니다. 그것은됩니다 증강많은 것들 중에서 신호와 슬롯을 가능하게하는 매크로 프로세서 (moc)에 의해. 추가 매크로 명령 (예 : Q_OBJECT)을 변환하여 클래스에 내성 및 C ++에 Objective-C 기능을 추가하는 것으로 생각할 수있는 다른 모든 장점이 있습니다. C ++에 대해 순도 부족으로 인해 기분이 상할 정도로 충분히 알고 있다면, 즉 당신은 전문가입니다 .1) Q_OBJECT와 그 ilk를 사용하지 마십시오. 이것이 문제를 일으키는 곳. "신호 및 슬롯에 부스트 사용"이라고 말하는 사람들에게 그때 나는 당신이 하나의 "문제"를 다른 것으로 교환하고 있다는 것을 반박 할 것입니다. 부스트는 거대하고 문서화 불량, 끔찍한 API 및 플랫폼 간 공포 (gcc 3과 같은 오래된 컴파일러를 생각하십시오)와 같이 일반적으로 인용되는 자체 문제가 있습니다.

  2. 편집자 지원을 위해 이것은 1부터 따릅니다. 다소 동의합니다. 실제로 Qt Creator는 Qt를 사용하지 않더라도 IMHO 최고의 그래픽 C ++ 편집기 기간입니다. 많은 전문 프로그래머는 emacs와 vim을 사용합니다. 또한 Eclipse가 추가 구문을 처리한다고 생각합니다. 따라서 Qt 매크로 (Q_OBJECT) 또는 신호 / 슬롯 추가에 문제가 없습니다. Visual Studio에서는 이러한 매크로를 찾지 못할 것입니다. 왜냐하면 C ++에 추가 된 것이기 때문입니다. 그러나 C # /. NET 사람들은 독자적인 기술로 다루어 진 많은 기능을 가지고 있기 때문에 Qt를 사용하지 않을 것입니다.

  3. Qt 소스의 크기와 관련하여 밤새 컴파일되는 한 누가 걱정합니까? 듀얼 코어 Macbook에서 Qt 4를 "밤새 미만"으로 컴파일했습니다. 나는 이것이 이것이 특정 기술을 사용하거나 사용하지 않기로 결정한 원인이 아니기를 바랍니다. 이것이 실제로 문제가되는 경우 Qt 웹 사이트에서 Mac, Linux 및 Windows 용 사전 컴파일 된 SDK를 다운로드 할 수 있습니다.

  4. 라이센스는 세 가지 선택으로 제공됩니다. 1) Qt ITSELF 를 수정 하고 공유하지 않는 경우를위한 독점 라이센스 Qt를 사용하고 있고 속성을 제공하지 않으려는 사실을 숨기거나 숨기는 경우 (브랜딩 및 이미지에 매우 중요 할 수 있습니다!) 2 ) GPL 및 3) LGPL. 예, 정적 링크 (이진으로 모든 Qt를 롤링)하는 데 문제가 있습니다.하지만 내부를 들여다 볼 수 없으며 Qt (속성!)를 사용하고 있음을 알기 때문에 더 많은 것으로 생각됩니다. Digia의 독점 라이센스를 구입하려고했는데 "내가하는 일에 대해서는 실제로 필요하지 않습니다"라고 말했습니다. 와. 라이센스를 판매하는 사업에서.

  5. 바이너리 / 번들의 크기는 Qt를 가지고 있지 않은 사람들에게 Qt를 배포해야하기 때문입니다 .Windows에 이미 있습니까? Visual Studio 물건 또는 런타임을 설치해야합니다. Mac은 이미 엄청난 Cocoa와 함께 제공되며 동적으로 연결될 수 있습니다. 나는 많은 배포를하지는 않지만 ~ 50 메가 바이트 정적 파일을 배포하는 데 많은 문제를 발견하지 못했습니다 (UPX와 같은 일부 바이너리 스트리퍼 / 압축 유틸리티로 더 작게 만들 수 있음). 나는 이것을하기에 충분히 신경 쓰지 않지만 대역폭이 문제가된다면 UPX 단계를 빌드 스크립트에 추가 할 것입니다.

  6. "네이티브 룩앤필"을 정의하는 것은 무엇입니까? "가장"은 Mac이 통일 된 모양과 느낌에 가장 가깝다는 데 동의 할 것입니다. 그러나 저는 Safari, iTunes, Aperture, Final Cut Pro, Pages 등을보고 앉아 있으며 OS 공급 업체가 만든 사실에도 불구하고 아무것도 보이지 않습니다. 위젯 스타일링, 응답 성 등 "느낌"측면이 더 관련이 있다고 생각합니다. 응답성에 관심이 있다면 Java보다는 C ++을 사용하는 다른 이유나 다른 매우 역동적 인 언어가 여기에 있습니다. (목표 C도 흔들리지 만 Qt에 대한 신화를 없애려고합니다)

요약하면 복잡한 문제입니다. 그러나 나는 신화와 10 년 전의 정보를 바탕으로 생각할 수 있기 때문에 "Qt를 사용하지 않는"이유가 적다고 생각하고 싶다.


1
내가 얻지 못하는 것은 이러한 크로스 플랫폼 라이브러리가 단순히 랩퍼 기능이 아니거나 더 나은 이유가 아닙니다. Cocoa, Win32, KDE / Gnome 기능이 제대로 작동하면 모든 기능을 갖춘 최상의 UI를 보장합니다.
MarcusJ

2
@MarcusJ 하나의 툴킷 주위에 래퍼를 작성하는 것은 분명 사소한 것이 아니며 4 이상은 신경 쓰지 않아도됩니다. 그러나 그것이 쉽다고 생각되면 시도해보십시오. 조건부 전처리 만 사용하여이 작업을 수행 할 수 있다는 아이디어는 ... 농담해야합니다.
underscore_d

@MarcusJ libui 는 정확히입니다 (KDE 지원이 없지만).
Demi

Qt / QML을 .NET과 함께 사용할 수 있다고 덧붙이고 싶습니다. C ++를 만질 필요는 없습니다. github.com/qmlnet/qmlnet PS : 저는 저자입니다.
Paul Knopf

26

그 중 일부는 라이센스입니다. 일부 라이센스 기록 은 https://en.wikipedia.org/wiki/Qt_(software)# 라이센스를 참조 하십시오 . 2000 년까지, 오픈 소스에 관심이있는 사람들은 Qt를 사용하지 않았습니다. 기간. (실제로 이것은 Gnome 개발의 원래 동기였습니다.) 2005 년까지 Windows 용 무료 소프트웨어를 출시하려는 사람들은 Qt를 사용하지 않았습니다. 그 이후에도 GPL 이외의 소프트웨어로 자유 소프트웨어를 원하는 사람들은 Qt를 사용할 수 없었습니다. 따라서 그 날짜보다 오래된 무료 소프트웨어 프로젝트는 Qt를 사용할 수 없습니다. 물론, 독점 코드를 작성하는 사람들은 특권을 지불해야했습니다.

또한 다른 옵션이 부족한 것처럼 보이지 않습니다. 예를 들어 WxWidgets , GTK +Tk 는 모두 오픈 소스 크로스 플랫폼 툴킷입니다.

게다가 오랫동안 Windows는 데스크톱에서 지배적이어서 많은 소프트웨어가 Windows에서만 실행되는 콘텐츠였습니다. Microsoft 툴체인을 설치하면 다른 것에 대해 걱정하는 것보다 Microsoft의 독점적 인 것을 사용하는 것이 더 쉽고 많은 프로그래머가 그렇게했습니다.


1
@btilly : GTK +는 크로스 플랫폼입니다. 예를 들어 Pidgin IM 클라이언트는 GTK +로 작성되었습니다.
Billy ONeal

1
그러나 Windows에서 '어떻게'실행될 수 있습니다.)
Dehumanizer

6
Windows에 김프를 설치하고 살펴보십시오.
user281377

2
예, 김프는 Windows에서 잘 작동하지만 Windows 7 UI 모양과 느낌에는 맞지 않습니다.
Alan B

5
Pidgin은 아마도 Windows에서 GTK의 더 좋은 예일 것입니다. 그것은 멋진 일을하지는 않지만 10 년 이상 지속될 수 있습니까?
Brendan Long

14

위에서 논의한 거의 모든 이유에 동의하지만 여기에 많은 사람들이 추가 오버 헤드로 인해 Qt를 사용하지 않을 것이라고 말했습니다. 오늘날 모든 가장 일반적인 언어 (Java, C # 및 Python)가 상당히 많은 오버 헤드를 가지고 있기 때문에 이에 동의하지 않습니다.

둘째, Qt는 C ++로 프로그래밍하는 것을 매우 쉽고 간단하게하여 사용하는 추가 리소스를 보충합니다. 나는 쉽게 작성할 수 있기 때문에 표준 C ++ 대신 Qt로 작성된 콘솔 응용 프로그램을 많이 보았습니다.

Qt의 생산성은 C / C ++의 생산성보다 크지 만 Python과 같은 언어보다는 적습니다.


2
C ++ 14에서 OK를 코딩 할 수 있기 때문에 개인의 경험과 관련이 있다고 생각합니다. 그러나 Qt 코드를 볼 때마다 동일한 언어로 인식하기가 어려워 야합니다. 이것이 당신이 암시하는 만장일치의 생산성 향상 기라고 생각하지 마십시오.
underscore_d

1
@underscore_d 분명히 C ++을 잘 알고 Qt를 잘 모른다면 후자에 대해 더 생산적이지 않을 것입니다. 그러나 C ++과 Qt를 모두 알게되면 프레임 워크는 실제로 많은 것을 쉽고 빠르게 구현할 수있게합니다 (C ++ 11, 14 등이 간격을 채우고 있지만 아직은 완전하지는 않습니다).
ymoreau

11

이것은 실제로 화염 전쟁을 시작하려는 시도가 아니며, 나는 단지 몇 가지 요점을 다루고 싶었습니다.

아마도 Qt가 더 널리 사용되지 않는 진짜 이유는 C ++이고 데스크탑 응용 프로그램에 c ++을 사용하는 사람들이 적기 때문입니다.

Qt는 C ++ 라이브러리가 아닙니다. 별도의 컴파일 단계가 필요하므로 대부분의 다른 라이브러리와 비교할 때 빌드 프로세스가 훨씬 복잡합니다.

Visual Studio 용 vs-addin은 Qt의 자체 명령 줄 만들기 프로세스와 마찬가지로 자동으로 수행합니다. MFC 대화 상자를 작성하는 데 사용되는 리소스 컴파일러는 별도의 단계이지만 여전히 c ++입니다.

Qt는 많은 양의 소스이며 컴파일하기 전에 사용하는 모든 머신에 존재하고 사전 설치되어 있어야합니다. 이것은 빌드 환경을 훨씬 더 지루하게 만들 수 있습니다.

각 버전의 Visual Studio에는 바이너리 다운로드가 있으며 소스 빌드는 단일 명령입니다. 요즘 SDK 소스 크기가 그렇게 많은 것을 보지 못합니다. Visual Studio는 이제 선택 및 선택을 허용하지 않고 모든 C ++ 라이브러리를 설치합니다. 결과적으로 컴파일러의 설치 크기는> 1Gb입니다.

LGPL 하에서 만 사용 가능하므로보다 제한적이거나 덜 제한적인 라이센스로 릴리스해야 할 경우 단일 이진 배포를 사용하기가 어렵습니다.

LGPL은 lib에만 적용되며 코드에는 영향을 미치지 않습니다. 예, 단일 바이너리가 아닌 DLL을 제공해야 함을 의미하지만 (비용을 지불하지 않는 한) 작은 유틸리티를 위해 Java 런타임 또는 .Net 업데이트를 다운로드 해야하는 세계에서는 그렇게 큰 문제가 아닙니다. 다른 Qt 앱이 라이브러리를 공유 할 수 있도록 단일 ABI가있는 플랫폼에서는 문제가 적습니다.

어떤 경우에는 네이티브 프로그램처럼 보이지 않습니다. 다양한 시각적 스타일링으로 인해 모든 플랫폼에 단일 UI를 설계하는 것은 본질적으로 기계에서 기계로 이동할 때 제대로 보이지 않습니다.

기본 위젯과 테마를 사용해야합니다. 사용자가 스타일에 대해 너무 걱정하지 않도록 대부분 기술적 인 앱을 사용한다는 점을 인정해야합니다. 특히 Windows에서는 스마트 폰 위젯으로 모든 스타일을 갖도록하는 새로운 방식이 어쨌든 표준의 수가 줄어든다는 것을 의미합니다.


1
상당수의 대규모 소프트웨어 회사가 C ++로 상업용 응용 프로그램을 작성하지만 QT를 사용하는 많은 사람은 알지 못합니다. 따라서 C ++이 아닌 개발자가 QT를 피할 수 있음을 이해하지만 C ++ 앱을 작성할 때도 QT를 피해야하는 다른 이유가 있습니다. 사실, 내가 찾을 수없는 크로스 플랫폼 언어와 GUI 툴킷은 실제로 없습니다. 크로스 플랫폼 개발은 그냥 평범한 일이며, 잘하는 것이 결코 쉽지 않거나 자유롭지 않으며 QT가 약속 한 약속 (GUI를 한 번 쓰고 어디서나 재사용 할 수 있음)은 충분하지 않은 것 같습니다.
Warren P

대부분의 데스크톱 C ++ 소프트웨어는 20 년 전에 시작했기 때문에 MFC에 있거나 20 년 전에 시작된 내부 툴킷을 사용하여 MFC (예 : MS-Office 또는 Autocad)를 피합니다. WPF를 사용하여 C ++ / CLR로 작성된 것이 의심됩니다. 그러나 크로스 플랫폼을 고려하지 않아도 Qt가 최고의 (또는 최악의!) 데스크탑 툴킷입니다. 대부분의 사람들처럼 우리는 웨비 프론트 엔드 (아마도 QtQuick / QML에서)와 C ++ 서버 백엔드를 향해 이동하고있다 - 아마 Qt는 신호 / 슬롯하지만 GUI를 사용하는
마틴 베켓

동의한다. 최악입니다. 그리고 Windows 전용 앱에서도 MFC 문제보다 QT 문제를 디버그하고 싶습니다.
워렌 P

@ WarrenP-예 MFC에서 누락 된 모든 항목에 대한 codeproject 검색을 놓치지 않습니다. 그러나 MSFT가 새로 발견 한 네이티브 코드에 대한 사랑으로 GUI를 더 쉽게 작성하기 위해 많은 노력을 기울이지 않았습니다.
Martin Beckett

7

그 이유는 간단합니다. 모든 주류 언어에 대한 구속력이 없으며, 당면한 일에 항상 마 법적으로 적합한 것은 아닙니다 .

작업에 적합한 도구를 사용하십시오. 간단한 명령 줄 응용 프로그램을 작성하는 경우 Qt를 사용하여 왜 그것을 부풀 릴까요?

더 일반적인 답변 (여기서 내가 관련이 있기 때문에 줄 수 있음)으로, 일부 프로그래머는 결코 그것을 포기하지 않고 사용하기로 결정했을 것입니다. 어떤 경우에는 프로그래머가 그것을 필요로하지 않고 조사한 것 이외의 특별한 이유가 없습니다.


1
그러나 Qt는 콘솔 응용 프로그램 만 작성할 수있는 기능을 제공합니다. 그렇지 않습니까?
Dehumanizer

9
@ Dehumanizer : 나는 모른다. 그러나 왜 작은 유틸리티 도구로 사용합니까? 표준 C ++로 응용 프로그램을 간단하게 작성할 수 있다면 어떤 이점이 있습니까? 라이브러리를 사용해야하는 이유를 찾고있는 것 같습니다 .
궤도에서 가벼움 경주

12
@ Dehumanizer : 내가 말했듯이, 그것은 거꾸로 접근입니다. 도서관에 대한 필요성을 알게되면 알게 될 것입니다. 그리고 나서 몇 가지를 시도해보고 여러분의 필요에 더 잘 맞는 것을 볼 수 있습니다. 유스 케이스없을 때 라이브러리에 대한 의견을 모으는 것은 어리석은 일입니다.
궤도에서 가벼움 경주

3
"간단한 명령 줄 응용 프로그램을 작성하는 경우 Qt를 사용하여 Qt로 부풀린 이유는 무엇입니까?"Qt-Doxygen :-)으로 작성된 매우 유명한 비 GUI 도구가 적어도 하나 있습니다.
Valentin Heinitz

4
예를 들어 @Dehumanizer는 파일, xml, 유니 코드, json, regexp, 동시성, 데이터베이스 등을 매우 빠르게 처리해야하며 12 개의 타사 라이브러리를 다운로드, 채택, 유지하고 싶지 않습니다.
Valentin Heinitz

5

Qt와 같은 프레임 워크는 제품이 모든 플랫폼에서 올바르게 보이는 것보다 모든 플랫폼 에서 동일하게 보이는 제품에 더 관심이있는 경우에 적합 합니다. 요즘 이러한 종류의 응용 프로그램은 웹 기반 기술로 이동하고 있습니다.


4

Qt가 작업하기에 좋은 프레임 워크라는 데 동의합니다. 여전히 많은 문제가 있습니다.

  1. 그것은 실제로 저수준 언어 인 C ++로 작성되었습니다. C ++이라는 사실만으로도 모든 Qt 프로그래머는 다른 언어로 작성된 프레임 워크에 비해 생산성이 크게 떨어집니다. GUI 개발 언어로 C ++을 사용하는 주된 이유는 자동 메모리 관리라는 개념이 없기 때문에 개발 프로세스가 오류가 발생하기 쉽다는 것입니다. 내성적이지 않기 때문에 디버깅이 훨씬 어려워집니다. 다른 주요 GUI 툴킷은 대부분 자동 메모리 관리 및 자체 검사라는 개념을 가지고 있습니다.
  2. 모든 크로스 플랫폼 툴킷은 지원되는 모든 플랫폼 중 최소 공통 분모 만 구현할 수 있다는 문제로 어려움을 겪고 있습니다. 즉, 다른 플랫폼에서 다른 UI 지침은 크로스 플랫폼 GUI의 전체적인 요구에 매우 의문을 제기합니다.
  3. Qt는 모든 UI를 코딩하는 데 중점을 둡니다. QtDesigner를 사용하여 UI의 일부를 빌드 할 있지만 (Cocoa / Obj-C) Interface Builder 또는 .Net 도구와 비교할 때 심각하게 부족합니다.
  4. Qt에는 많은 저수준 응용 프로그램 기능이 포함되어 있지만 특정 플랫폼에 적합한 프레임 워크를 갖는 것과 비교할 수는 없습니다. Windows 및 OSX 용 기본 운영 체제 라이브러리는 Qt의 구현보다 훨씬 강력합니다. (오디오 프레임 워크, 저수준 파일 시스템 액세스 등을 고려하십시오.)

즉, 빠른 응용 프로그램 프로토 타이핑 또는 사내 응용 프로그램에 PyQt를 사용하는 것이 좋습니다. Python을 사용하여 모든 코딩을 수행하면 C ++의 문제가 완화되고 실제로 Qt는 매우 쾌적한 곳이됩니다.


일부 의견에 대한 답변으로 수정 :

Qt가 C ++로 작성되는 것에 대해 썼을 때, Qt 자체에 대해 불평하지 않고 Qt 자체가 살고있는 환경에 대해 더 많이 불평했습니다. Qt는 자체 리소스를 잘 관리하지만 모든 GUI 관련- 비 Qt 코드도 C ++로 작성해야합니다. 심지어 Qt는 많은 훌륭한 도구를 제공하지만 궁극적으로 그 수준에서 C ++를 처리해야합니다. Qt는 C ++를 견딜 수있게하지만 여전히 C ++입니다.

내성에 관해서는, 이것이 의미하는 바는 다음과 같습니다. 디버그하기 가장 어려운 경우는 생각하는 방식으로 작동하지 않는 객체에 대한 포인터가있는 경우입니다. C ++을 사용하면 디버거가 해당 객체 내부를 조금 볼 수 있지만 (thwt 지점에서 유형 정보가있는 경우) 항상 작동하지는 않습니다. 반면에 같은 상황에서 코코아를 섭취하십시오. Cocoa / Obj-C에서는 디버거 내에서 객체로 메시지 ( '호출 함수')를 보낼 수 있습니다. 객체 상태를 변경하고, 속성을 쿼리하고, 유형 및 함수 이름을 요청할 수 있습니다. 이렇게하면 디버깅이 훨씬 편리해집니다. Qt / C ++에는 그와 비슷한 것이 없습니다.


11
1. Qt는 자체적으로 메모리 관리를 관리하므로 각 '새'후에는 '삭제'를 호출하지 않아도됩니다. 1a. C ++은 저수준 언어가 아니며 저수준 '능력'을 갖춘 고수준 언어입니다. 3. 동의하지만 Qt는 QtDesigner와 '일반 코드'를 동시에 사용하여 UI를 만들 것을 제공합니다. 4. 다시 동의하지만 Qt는 기본 API 사용을 제공합니다.
Dehumanizer

11
c ++에는 반자동 메모리 관리가 있다고 생각합니다. std :: auto_ptr 또는 boost :: shared_ptr 등과 같은 스마트 포인터를 사용하면 일반적으로 메모리 해제에 신경 쓸 필요가 없습니다. 이러한 종류의 컨테이너는 다른 리소스 (파일, 해제해야하는 시스템 리소스)를 위해 만들 수 있습니다. RAII 패턴을 사용하면 메모리 관리에 큰 도움이되며 메모리가 커질수록 메모리에 대해 걱정할 필요가 없습니다.
deo

8
"C ++이라는 사실만으로도 모든 Qt 프로그래머는 다른 언어로 작성된 프레임 워크에 비해 생산성이 크게 떨어질 것입니다." [인용 필요]
Nathan Osman

4
@ SK-logic : 세 번째 문장의 모든 단어를 이해한다고 생각하지만, 당신이 무슨 말을하는지 모르겠습니다. "추상화 수준"이란 무엇입니까? "저수준 언어"에 대한 Wikipedia 정의를 고려할 때 첫 번째 문장은 거짓입니다.
David Thornley

6
@ SK-logic : 템플릿 메타 프로그래밍은 Turing-complete이며,이를 활용하기에 충분히 똑똑하고 지식이있는 사람들이 있습니다. RAII는 가비지 수집이 크지 않지만 모든 종류의 리소스에서 작동한다는 사실이 그 정도를 차지합니다. 자, 구체적으로 Java에서는 어떤 종류의 추상화가 작동하지만 C ++에서는 작동하지 않습니까?
David Thornley

3

나는 Qt를 정말로 좋아하지만 많은 응용 프로그램에는 약간 무겁습니다. 때로는 그 정도의 복잡성이 필요하지 않습니다. 때로는 Qt의 모든 오버 헤드없이 간단한 것이 필요합니다. 모든 응용 프로그램이 이벤트 중심 일 필요는 없으며 C ++은 합리적인 템플릿 세트를 제공합니다. Boost는 또 다른 매우 훌륭한 세트를 제공하며 QT가 수행하는 많은 저수준 기능 (파일, 소켓, 관리되는 포인터 등)을 포함합니다.

다른 응용 프로그램에는 GPL, LGPL 또는 Qt의 상용 라이센스로는 적합하지 않은 라이센스 요구 사항이 있습니다. GPL은 상용 소프트웨어에 적합하지 않습니다. LGPL은 정적으로 링크 된 소프트웨어에는 적합하지 않으며 상업용 라이센스 비용은 많은 비용을 지불하지 않는 비용입니다.

일부는 Qt와 같은 복잡한 라이브러리를 허용하지 않는 보안 또는 안정성 고려 사항이 있습니다.

소스를 사전 처리하려면 moc를 실행해야합니다. 그것은 큰 문제는 아니지만 새로운 사용자에게는 어려울 수 있습니다. 프로그래머의 많은 당신이 생각하는 필요 Qt를 함께 qmake를 사용하는,하지만 그건 잘못된 이름입니다. Qt를 다른 빌드 시스템에 매우 쉽게 연결할 수 있습니다.

일부 대상은 메모리 또는 CPU 제약이 있습니다.

거기에는 플랫폼 별 문제가 있습니다. 이러한 문제는 대부분 문서화되지 않았습니다. 충분히 큰 응용 프로그램을 빌드하면 응용 프로그램이 실행되고 무슨 일이 일어나고 있는지 궁금해 할 것입니다 (면책 조항, 분노에 Qt를 사용한 마지막 시간은 18 개월 이상이므로 개선되었을 수 있습니다).

C ++ 전용입니다. 다른 언어 바인딩도 있지만 Qt에 필요한 많은 기능을 숨기거나 노출시키는 경향이 있습니다.

Qt를 사용하지 않는 데는 많은 이유가 있기 때문에 대안이 있습니다. 당신이 가진 모든 망치라면 모든 문제는 못처럼 보일 것입니다.


3

가장 중요하지만 언급되지 않은 것. 큰 프로젝트에서 한 가지 문제는 너무 많은 문제와 불필요한 코드를 유발합니다. Qt의 신호 슬롯 메커니즘은 비효율적입니다. Qt 위젯은 이벤트 단순 위젯에 필요한 신호를 제공하지 않습니다. 예를 들어 onHover, onMouseEnter, onMouseLeave, onKeyReleased, onLostFocus, onGainFocus 등에 대한 신호를 설정할 수 없습니다. QTreeWidget과 같은 가장 복잡한 위젯조차도 하나 또는 두 개의 매우 간단한 쓸모없는 신호를 제공합니다.

예, 이벤트를 사용할 수 있습니다. 그러나 !!! 사용자 정의 이벤트를 사용하여 각 위젯에 대해 새 클래스를 작성했습니다. 이것은 엄청난 효율성 손실입니다.

  • 약간의 변경 사항이있는 각 사용자 정의 위젯 오브젝트 이벤트를 다시 작성했습니다.
  • 당신은 모든 Qt 디자이너 물건을 잃게됩니다. 맞춤 이벤트로 모든 위젯을 홍보해야합니다.
  • 프로젝트가 커지고 유지하기가 어려워졌습니다.
  • 이 때문에 qt를 싫어하기 시작했습니다. .net이 델리게이트를 제공하는 방법, 신호 슬롯보다 훨씬 더 나은 방법, .net 컴포넌트 (위젯)가 일반적으로 상상할 수있는 모든 이벤트를 제공하는 방법에 대해 이야기하기 시작했습니다. 그리고 등등

우리 대학 중 한 명이 신호가 아닌 이벤트를 사용해야했기 때문에 각 콤보 상자 위젯마다 새로운 콤보 상자 클래스를 작성했습니다. 실화 ...

그러나 Qt는 현재까지 다운 및 업을 갖춘 최고의 C ++ UI 프레임 워크입니다.


이벤트 및 새 클래스 생성과 관련하여 : 이벤트 필터는 이에 반응해야하는 클래스에서 사용할 수 있습니다.
MrFox

"예, 이벤트를 사용할 수 있습니다. 그러나 사용자 정의 이벤트로 각 위젯에 대해 새 클래스를 작성했습니다. 이는 효율성이 크게 저하됩니다." - 정확히. 방금 여러 위젯을 처리하는 bool eventFilter로 끝나고 모든 하위 위젯에 eventEvent (this)를 설치합니다. 그리고 이것은 효율성과 프로그래밍 성능을 잃지 않습니다! 실제로 나는 "프로모션 위젯"을 사용하지 않습니다 ... 나는 평범한 빈 위젯을 떨어 뜨리고 이것을 eventFilter로 설치하고 대부분의 이벤트를 메인 cpp 클래스 내에서 다시 구현합니다. 시도해 보지 않아도 :) 매번 새로운 클래스를 만들지 않고도 Qt에서 거의 모든 것을 사용자 정의 할 수 있습니다.
Петър Петров

3

내 생각으로는 C ++ 프로그래밍을 배우는 것은 복잡한 언어를 숨기는 다른 언어에 빠지는 것보다 간단하며 프로그래머는 실제로 백그라운드에서 어떤 일이 발생하는지 알지 못합니다. 반면에 Qt는 C ++에 비해 몇 가지 이점을 추가하여 네이티브 C ++보다 높은 수준으로 만듭니다. 따라서 Qt C ++는 저수준 작업 또는 고수준 작업을 동일한 방식으로 개발하려는 사람들에게 훌륭한 프레임 워크입니다. C ++은 (일부 사례에서는) 복잡하고 간단한 언어입니다. 도전하고 싶지 않은 사람에게는 복잡하고 그것을 좋아하는 사람에게는 간단합니다. 복잡하기 때문에 두지 마십시오!


2

실제 이유는 기술적 인 것이 아닙니다.

사람들은 달라집니다. 그들의 선택도 마찬가지입니다. 균일 성은 인간의 기능이 아닙니다.


왜 모든 사람들이 다리를 밟고 있습니까? 적어도 다리가있는 사람들은 ...
dtech
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.