태양 아래에는 완벽한 것이 없습니다. Qt도 예외는 아니며 제한이 있습니다. GUI 이외의 스레드에서 픽스맵을 사용할 수 없으며 채널당 16 비트 이미지 형식으로 QImage를 사용할 수 없습니다.
Qt의 한계로 인해 어떤 상황에서 디자인을 망쳐 놓았습니까?
가장 싫어하는 단점은 무엇입니까?
프로젝트에서 Qt를 사용하는 동안 피해야 할 설계 결정은 무엇입니까?
답변
아이러니하게도, Qt의 힘은 단점 중 하나라고 말합니다. 많은 강력한 구성과 확장 기능이 있으며 Qt로 작성한 코드는 “Qt 방식”으로 쉽게 강화됩니다. 기능을 다른 언어로 추출하려고하면 다시 작성해야 할뿐만 아니라 많은 Qt 관련 기술을 알아야합니다.
Qt의 폭은 프로그래머를 고용한다는 것은 Qt 경험이있는 사람에게 헌신하거나 해당 전문 지식에 대한 교육을 의미한다는 것을 의미합니다. 계약자를 빠른 속도로 얻는 것은 바닐라 C ++보다 어렵습니다.
Qt가 3.x에서 4.x로 변경되었을 때, 우리 팀은 거의 9 개월 동안 포트를 수행해야했으며 그 동안 새로운 기능이 거의 추가되지 않았습니다. 남은 시간 동안 개발 효율성을 높이기 위해 주요 업그레이드 비용을 보충하기를 희망합니다. (참고로, Qt의 장점을 생략했으며 그중 많은 것도 있습니다)
답변
Qt는 표준 C ++ 라이브러리를 사용하지 않지만 자체 QString, QVector, QMap 등을 가지고 있습니다.
이것은 중요한 디자인 결정을해야한다는 것을 의미합니다 : 어플리케이션의 어떤 부분이 QString을 사용하고 어떤 부분이 std :: string을 사용합니까?
일부 부분에서는 std :: string을 사용하고 다른 부분에서는 QString을 사용하면 경계에서 QString과 std :: string 사이를 변환해야합니다.
이러한 오버 헤드를 피하기 위해 애플리케이션 전체에서 QString을 사용하기로 결정할 수 있습니다. 그러나 Qt를 기반으로하지 않는 타사 라이브러리 (예 : 부스트)를 사용하는 것이 훨씬 어렵습니다.
(std :: map vs QMap, std :: vector vs QVector 등에도 동일하게 적용됨)
Qt 유형을 사용하는 부품과 STL을 사용하는 부품을 결정 하는 것은 중요한 의미를 갖는 주요 디자인 결정입니다. 그리고 Qt가 표준 C ++ 라이브러리를 사용하지 않기 때문입니다.
IMHO, 그 결정은 프로젝트에 따라 어느 쪽이든 진행될 수 있습니다. 따라서 피해야 할 질문에 대답 할 수 없습니다.
답변
이것은 질문에 직접 대답하지는 않지만 언급 할 가치가 있다고 생각합니다 .Qt의 가장 위험한 부분은 Nokia가 MSoft와 잘 지내고 있다는 것입니다.
답변
최근 QChar는 이름에도 불구하고 실제로 한 문자가 아니라 UTF-16 코드 단위에 해당한다는 것을 알았습니다. 따라서 문자 단위로 임의의 유니 코드 텍스트를 스캔하려면 문자 등을 결합하여 높고 낮은 대리모를 처리하는 알고리즘을 추가해야합니다.
