Tại sao không có nhiều ứng dụng máy tính để bàn được viết bằng Qt? [đóng cửa]

Theo như tôi biết và đã hiểu theo kinh nghiệm của tôi với Qt, đó là một thư viện rất tốt và dễ học. Nó có API được thiết kế rất tốt và đa nền tảng, và đây chỉ là hai trong số nhiều tính năng làm cho nó hấp dẫn. Tôi muốn biết lý do tại sao nhiều lập trình viên không sử dụng Qt. Có một thiếu sót mà nói chống lại nó? Tính năng nào làm cho các thư viện khác tốt hơn Qt? Là vấn đề liên quan đến cấp phép?

Tôi thực sự không có ý định đây là một câu trả lời bash, nhưng đây là những lý do tôi không sử dụng cá nhân Qt. Có rất nhiều điều hay để nói về nó - cụ thể là API hoạt động hầu hết thời gian và nó làm liền mạch các nền tảng. Nhưng tôi không sử dụng Qt, bởi vì:

1. Trong một số trường hợp, nó trông không giống chương trình bản địa. Thiết kế một giao diện người dùng duy nhất cho tất cả các nền tảng vốn sẽ không phù hợp khi được chuyển từ máy này sang máy khác, vì nhiều lý do kiểu dáng trực quan khác nhau. Ví dụ, trên máy Mac, thanh chia thường tương đối dày và các nút nhỏ và tròn với các biểu tượng. Trên các máy Windows, thanh chia thường hẹp và các nút có nhiều chữ hơn, với thiết kế vuông hơn. Chỉ vì bạn có thể viết một UI cho mọi nền tảng không có nghĩa là bạn nên dùng cho hầu hết các ứng dụng.
2. Qt không phải là thư viện C ++. Nó đòi hỏi một bước biên dịch riêng biệt, làm cho quá trình xây dựng phức tạp hơn nhiều khi so sánh với hầu hết các thư viện khác.
3. Do (2), các công cụ và IDE của C ++ có thể gắn cờ các biểu thức Qt là lỗi, vì chúng không hiểu chi tiết cụ thể của Qt. Điều này gần như buộc sử dụng QtCreator hoặc một trình soạn thảo chỉ có văn bản như thế vim.
4. Qt là một lượng lớn nguồn, phải có mặt và được cài đặt sẵn trên bất kỳ máy nào bạn sử dụng trước khi biên dịch. Điều này có thể làm cho việc thiết lập một môi trường xây dựng tẻ nhạt hơn nhiều.
5. Nó chỉ khả dụng trong LGPL, điều này gây khó khăn khi sử dụng triển khai nhị phân đơn khi cần phát hành theo giấy phép hạn chế hơn hoặc ít hạn chế hơn.
6. Nó tạo ra các nhị phân được biên dịch cực lớn khi so sánh với các ứng dụng gốc "đơn giản ol" được viết tương tự (ngoại trừ các ứng dụng tất nhiên được viết cho KDE).

Như mọi người nói, mỗi công cụ phù hợp với từng vấn đề và tình huống ...

Nhưng nếu bạn là lập trình viên C ++, Qt là khuôn khổ của bạn. Không có đối thủ.

Chúng tôi phát triển một ứng dụng thương mại hình ảnh y tế phức tạp, và Qt giữ.

Tôi không nói rằng 'khuyết điểm' mà mọi người nói về nó là sai, nhưng tôi có cảm giác rằng họ đã không thử Qt trong một thời gian dài (nó liên tục cải thiện trên mỗi phiên bản mới ...) Và, chủ yếu là tất cả các vấn đề họ bình luận không phải là vấn đề nếu bạn quan tâm.

Sự không nhất quán của nền tảng UI: chỉ khi bạn sử dụng các tiện ích UI 'như hiện tại', không có tùy chỉnh hoặc nghệ thuật tùy chỉnh.

Quá tải tiền xử lý Qt: Chỉ khi bạn lạm dụng cơ chế khe tín hiệu hoặc kế thừa QObject, khi không thực sự cần.

Nhân tiện, chúng tôi vẫn viết các ứng dụng bằng C # .NET và đã thực hiện nó trong một thời gian dài. Vì vậy, tôi nghĩ rằng tôi có quan điểm enouch.

Như tôi đã nói, mỗi công cụ cho từng tình huống,

nhưng Qt chắc chắn là một khuôn khổ nhất quán và hữu ích.

Trong tất cả những điều tôi không thích về Qt, thực tế là nó không chơi tốt với các mẫu khiến tôi bận tâm nhất. Bạn không thể làm điều này:

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

public signals:
  void something_happened(T);
};

Nó cũng không chơi tốt với bộ tiền xử lý. Bạn không thể làm điều này:

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

Điều đó, xen lẫn với thực tế là mọi thứ phản hồi tín hiệu phải là Q_OB DỰ ÁN, khiến Qt khó có thể làm việc cho một lập trình viên C ++. Mọi người đã sử dụng lập trình kiểu Java hoặc Python có lẽ thực sự tốt hơn.

Tôi thực sự đã dành rất nhiều thời gian và nỗ lực để nghiên cứu và tìm ra cách lấy lại sự an toàn của loại và kết nối tín hiệu Qt với bất kỳ đối tượng functor nào: http://crazyeddiecpp.blogspot.com/2011/01/quest-for-sane-signals -in-qt-bước-1.html

Loại điều tôi muốn làm là sự phát triển C ++ cơ bản hàng ngày được thực hiện bên cạnh không thể bởi mt Qt ... điều mà bản thân nó hoàn toàn không cần thiết ngày nay, nếu nó thực sự là như vậy.

Thành thật mà nói, tôi bị mắc kẹt bởi vì nếu bạn muốn thực hiện kiểm tra giao diện người dùng tự động, Qt gần như là trò chơi duy nhất trong thị trấn thiếu ... đó là năm 1980 (nó hoạt động rất khó khăn). Một số người có thể nói WX nhưng nó thậm chí còn có vấn đề nghiêm trọng hơn. GTKmm sẽ là lựa chọn đầu tiên của tôi nhưng vì tất cả đều là chủ sở hữu và không có khả năng truy cập ... không thể bị điều khiển bởi phần mềm kiểm tra tiêu chuẩn công nghiệp. Qt là đủ khó về vấn đề đó ( hầu như không hoạt động khi bạn sửa đổi plugin khả năng truy cập).

Một lý do để không sử dụng Qt là nếu bạn chỉ viết cho một kiến ​​trúc, chẳng hạn như Windows, bạn có thể muốn sử dụng C # /. NET (hoặc Ca cao trên Mac) vì họ sẽ luôn có thể tận dụng những tiếng chuông mới nhất - và -những gì của hệ điều hành.

Nếu bạn đang viết các ứng dụng đa nền tảng, thì bạn có thể đã được giao nhiều công nghệ khác như Java (tức là bạn làm việc trong "Cửa hàng Java"). Sự lựa chọn công nghệ của bạn có thể được quyết định bởi hệ sinh thái nơi bạn đang phát triển, chẳng hạn như API dành riêng cho ngôn ngữ. Trong các loại trường hợp này, giảm thiểu số lượng công nghệ có thể có lợi.

Một lý do thứ ba mà tôi có thể nghĩ đến là Qt dựa trên C ++ và C ++ là ngôn ngữ tương đối khó / nguy hiểm để lập trình. Tôi nghĩ đó là ngôn ngữ dành cho các chuyên gia. Nếu bạn cần phải có hiệu suất cao nhất và có khả năng tỉ mỉ, thì C ++ có lẽ vẫn là trò chơi hay nhất trong thị trấn. Trên thực tế, Qt cải thiện rất nhiều vấn đề quản lý bộ nhớ nếu bạn thiết lập mọi thứ nằm ngoài phạm vi. Ngoài ra, bản thân Qt cũng làm tốt công việc bảo vệ người dùng khỏi rất nhiều vấn đề khó chịu của C ++. Mỗi ngôn ngữ và khuôn khổ đều có ưu và nhược điểm của nó. Đây là một vấn đề rất, rất phức tạp thường có thể được tóm tắt bởi phần bổ sung thường thấy ở thực khách: Tốc độ, Chất lượng và Giá cả (nhưng bạn chỉ có thể chọn hai).

Mặc dù các quy tắc nói rằng tôi nên tiếp tục tập trung vào việc trả lời câu hỏi, tôi thực sự muốn bác bỏ một số vấn đề được đưa ra bởi Billy ONeal, người mà tôi nghĩ rằng một công việc tốt là tóm tắt những lý do thường được trích dẫn để không sử dụng Qt:

1. Qt thực sự là một tệp thư viện / khung / tiêu đề C ++. Nó được tăng cườngbởi một bộ xử lý macro (moc) cho phép tín hiệu và khe cắm, trong số nhiều thứ khác. Nó biến đổi các lệnh macro bổ sung (chẳng hạn như Q_OB DỰ ÁN) để các lớp có nội tâm và tất cả các loại tính năng khác mà bạn có thể nghĩ đến khi thêm chức năng Objective-C vào C ++. Nếu bạn biết đủ về C ++ để bị xúc phạm bởi sự thiếu tinh khiết này, tức là bạn là dân chuyên nghiệp, thì 1) không sử dụng Q_OB DỰ ÁN và ilk hoặc 2) của nó biết ơn vì nó làm điều này và lập trình xung quanh các trường hợp góc rất hạn chế nơi điều này gây ra một vấn đề. Dành cho những người nói "Sử dụng Boost cho tín hiệu và khe cắm!" sau đó tôi sẽ vặn lại rằng bạn đang trao đổi một "vấn đề" khác. Boost là rất lớn và nó có các vấn đề thường được trích dẫn như tài liệu kém, API khủng khiếp và nỗi kinh hoàng đa nền tảng (nghĩ rằng các trình biên dịch cũ như gcc 3.

2. Đối với hỗ trợ biên tập, điều này cũng theo sau 1, tôi phần nào đồng ý. Trên thực tế, Qt Creator là IMHO trình soạn thảo C ++ đồ họa tốt nhất, ngay cả khi bạn không sử dụng công cụ Qt. Nhiều lập trình viên chuyên nghiệp sử dụng emacs và vim. Ngoài ra, tôi nghĩ rằng Eclipse xử lý cú pháp bổ sung. Do đó, không có vấn đề với các macro Qt (Q_OB DỰ ÁN) hoặc bổ sung tín hiệu / vị trí. Bạn có thể sẽ không tìm thấy các macro này trong Visual Studio, bởi vì (tôi thừa nhận) chúng là những bổ sung cho C ++. Nhưng nhìn chung, mọi người C # /. NET sẽ không sử dụng Qt, vì thực tế là họ có rất nhiều chức năng được bao phủ bởi các kỹ thuật độc quyền của riêng họ.

3. Đối với kích thước của nguồn Qt, miễn là nó biên dịch qua đêm, ai quan tâm? Tôi đã biên dịch Qt 4 trên Macbook lõi kép của mình trong "ít hơn qua đêm". Tôi chắc chắn hy vọng đây không phải là điều thúc đẩy quyết định sử dụng hoặc không sử dụng một công nghệ cụ thể của bạn. Nếu đây thực sự là một vấn đề, thì bạn có thể tải xuống SDK được biên dịch sẵn cho Mac, Linux và Windows từ trang web Qt.

4. Cấp phép có sẵn trong ba lựa chọn: 1) Giấy phép độc quyền trong trường hợp bạn muốn sửa đổi Qt ITSELF và không chia sẻ, hoặc che giấu sự thật rằng một người đang sử dụng Qt và không sẵn sàng quy kết (có thể rất quan trọng đối với thương hiệu và hình ảnh!) 2 ) GPL và 3) LGPL. Vâng, có vấn đề với liên kết tĩnh (chuyển tất cả Qt thành nhị phân) - nhưng tôi nghĩ đó là nhiều hơn bởi vì người ta không thể nhìn vào bên trong và nhận thấy rằng bạn đang sử dụng Qt (ghi công!). Tôi đã cố gắng mua giấy phép độc quyền từ Digia và họ nói với tôi "vì những gì bạn đang làm, bạn thực sự không cần nó." Ồ Từ một doanh nghiệp đang kinh doanh bán giấy phép.

5. Kích thước của gói nhị phân / gói là do bạn phải phân phối công cụ Qt cho những người không có nó: Windows đã có? công cụ Visual Studio hoặc bạn phải cài đặt thời gian chạy. Mac đã đi kèm với lượng ca cao khổng lồ và có thể được liên kết động. Mặc dù tôi không phân phối nhiều nhưng tôi chưa bao giờ gặp vấn đề gì với việc phân phối tệp tĩnh ~ 50 megabyte (mà tôi có thể làm cho nhỏ hơn nữa với một số tiện ích nén / nén nhị phân như UPX). Tôi chỉ không quan tâm đủ để làm điều này, nhưng nếu băng thông là một vấn đề, tôi sẽ thêm một bước UPX vào tập lệnh xây dựng của mình.

6. Điều gì định nghĩa "Cái nhìn và cảm nhận bản địa?" Tôi nghĩ rằng "hầu hết" sẽ đồng ý rằng Mac đến gần nhất với giao diện thống nhất. Nhưng ở đây tôi ngồi, nhìn vào Safari, iTunes, Aperture, Final Cut Pro, Pages, v.v. và chúng trông không có gì giống nhau mặc dù thực tế là chúng được sản xuất bởi nhà cung cấp hệ điều hành. Tôi nghĩ khía cạnh "cảm nhận" có liên quan hơn: kiểu dáng widget, khả năng phản hồi, v.v. Nếu bạn quan tâm đến khả năng đáp ứng, thì đây là một lý do tốt để sử dụng C ++ thay vì Java hoặc một số ngôn ngữ rất năng động khác. (Mục tiêu C cũng đá, nhưng tôi đang cố gắng xua tan những huyền thoại về Qt)

Tóm lại, đây là một vấn đề phức tạp. Nhưng tôi muốn chỉ ra rằng tôi nghĩ rằng có ít lý do hơn để "không sử dụng Qt" như người ta có thể nghĩ dựa trên những huyền thoại và thông tin lỗi thời trong thập kỷ.

Một số trong đó là cấp phép. Xem https://en.wikipedia.org/wiki/Qt_(software)#Licensing để biết một số lịch sử cấp phép. Cho đến năm 2000, những người quan tâm mạnh mẽ đến nguồn mở, đã không sử dụng Qt. Giai đoạn = Stage. (Trên thực tế, đây là động lực ban đầu cho sự phát triển của Gnome.) Cho đến năm 2005, những người muốn có thể phát hành phần mềm miễn phí cho Windows đã không sử dụng Qt. Ngay cả sau ngày đó, những người muốn có phần mềm miễn phí theo một thứ khác ngoài GPL, đơn giản là không có tùy chọn sử dụng Qt. Do đó, bất kỳ dự án phần mềm miễn phí nào cũ hơn những ngày đó, không thể sử dụng Qt. Và, tất nhiên, những người viết mã độc quyền đã phải trả tiền cho đặc quyền.

Hơn nữa, nó không phải là thiếu các lựa chọn khác. Ví dụ , WxWidgets , GTK + và Tk đều là các bộ công cụ đa nền tảng, mã nguồn mở.

Hơn nữa, trong một thời gian dài, Windows chiếm ưu thế trên máy tính để bàn đến nỗi rất nhiều phần mềm chỉ có nội dung để chạy trên Windows. Nếu bạn cài đặt Microsoft toolchain, việc sử dụng công cụ độc quyền của Microsoft sẽ dễ dàng hơn là lo lắng về bất cứ điều gì khác và rất nhiều lập trình viên đã làm điều đó.

Tôi đồng ý với gần như tất cả các lý do được thảo luận ở trên, tuy nhiên, rất nhiều người ở đây đã nói rằng họ sẽ không sử dụng Qt vì có thêm chi phí mà nó mang lại. Tôi không đồng ý với điều đó bởi vì tất cả các ngôn ngữ phổ biến nhất hiện nay (Java, C # và Python) đều mang một chút chi phí hợp lý.

Thứ hai, Qt làm cho việc lập trình với C ++ trở nên dễ dàng và đơn giản đến mức nó bù đắp cho các tài nguyên bổ sung mà nó sử dụng. Tôi đã bắt gặp khá nhiều ứng dụng bảng điều khiển được viết bằng Qt thay vì C ++ tiêu chuẩn vì chúng có thể được viết dễ dàng.

Tôi có thể nói rằng năng suất của Qt lớn hơn C / C ++ nhưng kém hơn các ngôn ngữ như Python.

Đây thực sự không phải là một nỗ lực để bắt đầu một cuộc chiến lửa, tôi chỉ muốn giải quyết một số điểm.

Có lẽ lý do thực sự khiến Qt không được sử dụng rộng rãi hơn là C ++ và càng ít người sử dụng c ++ cho các ứng dụng máy tính để bàn.

Qt không phải là thư viện C ++. Nó đòi hỏi một bước biên dịch riêng biệt, làm cho quá trình xây dựng phức tạp hơn nhiều khi so sánh với hầu hết các thư viện khác.

Phần bổ trợ cho studio trực quan thực hiện điều này một cách tự động cũng như quy trình tạo dòng lệnh riêng của Qt. Trình biên dịch tài nguyên được sử dụng để xây dựng các hộp thoại cho MFC cũng là một bước riêng biệt nhưng đó vẫn là c ++.

Qt là một lượng lớn nguồn, phải có mặt và được cài đặt sẵn trên bất kỳ máy nào bạn sử dụng trước khi biên dịch. Điều này có thể làm cho việc thiết lập một môi trường xây dựng tẻ nhạt hơn nhiều.

Có một bản tải xuống nhị phân cho mỗi phiên bản của studio hình ảnh và bản dựng từ nguồn là một lệnh duy nhất. Tôi không thấy kích thước nguồn SDK rất nhiều trong những ngày này. Visual studio hiện cài đặt tất cả các lib C ++ thay vì cho phép bạn chọn và chọn, do đó, kích thước cài đặt của trình biên dịch là> 1Gb.

Nó chỉ khả dụng trong LGPL, điều này gây khó khăn khi sử dụng triển khai nhị phân đơn khi cần phát hành theo giấy phép hạn chế hơn hoặc ít hạn chế hơn.

LGPL chỉ áp dụng cho lib, nó không ảnh hưởng đến mã của bạn. Vâng, điều đó có nghĩa là bạn phải gửi DLL chứ không phải là một tệp nhị phân (trừ khi bạn trả tiền), nhưng trong một thế giới nơi bạn cần tải xuống thời gian chạy Java hoặc bản cập nhật .Net cho một ứng dụng nhỏ thì đây không phải là vấn đề lớn. Nó cũng ít gặp sự cố hơn trên các nền tảng với một ABI duy nhất để các ứng dụng Qt khác có thể chia sẻ các lib.

Trong một số trường hợp, nó trông không giống chương trình bản địa. Thiết kế một giao diện người dùng duy nhất cho tất cả các nền tảng vốn sẽ không phù hợp khi được chuyển từ máy này sang máy khác, vì nhiều lý do kiểu dáng trực quan khác nhau.

Nó được cho là sử dụng các vật dụng và chủ đề bản địa. Tôi phải thừa nhận tôi chủ yếu làm các ứng dụng kỹ thuật để người dùng của tôi không quá quan tâm đến phong cách. Đặc biệt trên các cửa sổ thời trang mới để có mọi thứ theo phong cách riêng như một widget điện thoại thông minh có nghĩa là ngày càng có ít tiêu chuẩn hơn.

Lý do rất đơn giản: nó không có sự ràng buộc tốt với tất cả các ngôn ngữ chính và nó không phải lúc nào cũng phù hợp với công việc trong tay.

Sử dụng các công cụ thích hợp cho công việc. Nếu tôi đang viết một ứng dụng dòng lệnh đơn giản, tại sao tôi lại làm hỏng nó với Qt chỉ vì lợi ích của nó?

Như một câu trả lời tổng quát hơn (mà tôi có thể đưa ra vì tôi có liên quan ở đây), một số lập trình viên sẽ không bao giờ bỏ qua và quyết định sử dụng nó. Trong một số trường hợp, không có lý do cụ thể nào khác ngoài lập trình viên chưa bao giờ tìm thấy nhu cầu về nó và xem xét nó.

Các khung như Qt phù hợp khi bạn quan tâm nhiều hơn đến sản phẩm của mình trông giống nhau trên tất cả các nền tảng so với sản phẩm của bạn nhìn đúng trên tất cả các nền tảng. Ngày càng thường xuyên hơn, những loại ứng dụng này đang chuyển sang các công nghệ dựa trên web.

Tôi đồng ý rằng Qt là một khung làm việc tốt. Tuy nhiên, có một số vấn đề tôi gặp phải:

1. Nó được viết bằng C ++, một ngôn ngữ thực sự cấp thấp. Thực tế là C ++ sẽ khiến mọi lập trình viên Qt giảm năng suất đáng kể so với các Framework được viết bằng các ngôn ngữ khác. Thịt bò chính của tôi với C ++ là ngôn ngữ phát triển GUI là nó không có khái niệm quản lý bộ nhớ tự động, điều này khiến quá trình phát triển dễ bị lỗi hơn rất nhiều. Nó không phải là nội tâm, khiến cho việc gỡ lỗi khó khăn hơn rất nhiều. Hầu hết các bộ công cụ GUI chính khác có một số khái niệm về quản lý bộ nhớ tự động và hướng nội.
2. Mọi bộ công cụ đa nền tảng đều gặp phải vấn đề là nó chỉ có thể thực hiện mẫu số chung ít nhất trong tất cả các nền tảng được hỗ trợ. Điều đó và các hướng dẫn giao diện người dùng khác nhau trên các nền tảng khác nhau rất nhiều câu hỏi về tính mong muốn của GUI đa nền tảng nói chung.
3. Qt tập trung rất nhiều vào việc mã hóa tất cả giao diện người dùng của bạn. Mặc dù bạn có thể sử dụng QtDesigner để xây dựng một số phần của giao diện người dùng của mình, nhưng nó thực sự thiếu so với Trình tạo giao diện (Ca cao / Obj-C) hoặc các công cụ .Net.
4. Mặc dù Qt không có nhiều chức năng ứng dụng cấp thấp, nhưng nó không thể so sánh với việc có một khung làm việc được điều chỉnh bằng tay cho một nền tảng nhất định. Các thư viện hệ điều hành gốc cho cả Windows và OSX mạnh hơn đáng kể so với triển khai của Qt. (Nghĩ khung âm thanh, truy cập hệ thống tệp cấp thấp, v.v.)

Điều đó nói rằng, tôi thích sử dụng PyQt để tạo mẫu ứng dụng nhanh hoặc ứng dụng nội bộ. Sử dụng Python để thực hiện tất cả các mã hóa làm giảm bớt các mối quan tâm với C ++ và thực sự làm cho Qt trở thành một nơi rất dễ chịu.

Chỉnh sửa, để đáp ứng với một số ý kiến:

Khi tôi viết về Qt được viết bằng C ++, tôi không phàn nàn nhiều về bản thân Qt, nhưng nhiều hơn về môi trường mà nó sống. Đúng là Qt quản lý tài nguyên của chính nó rất tốt, nhưng tất cả đều liên quan đến GUI của bạn - nhưng- Mã không phải Qt cũng phải được viết bằng C ++. Ngay cả ở đó, Qt cung cấp nhiều công cụ hay, nhưng cuối cùng, bạn phải đối phó với C ++ ở cấp độ đó. Qt làm cho C ++ có thể chịu được, nhưng nó vẫn là C ++.

Về phần hướng nội, điều tôi muốn nói là đây: Các trường hợp khó nhất để gỡ lỗi là khi bạn có một con trỏ tới một đối tượng không hành xử theo cách bạn nghĩ. Với C ++, trình gỡ lỗi của bạn có thể có thể nhìn vào bên trong đối tượng đó một chút (nếu nó có thông tin loại tại điểm thwt), nhưng ngay cả điều đó không phải lúc nào cũng hoạt động. Mặt khác, ca cao trong tình huống tương tự. Trong Ca cao / Obj-C, bạn sẽ có thể gửi tin nhắn ('chức năng gọi') đến một đối tượng ngay trong trình gỡ lỗi. Bạn có thể thay đổi trạng thái đối tượng, bạn có thể truy vấn nó cho các thuộc tính của nó, bạn có thể hỏi nó về loại và tên hàm của nó ... Điều này có thể giúp việc gỡ lỗi thuận tiện hơn rất nhiều. Qt / C ++ không có gì thậm chí gần với điều đó.

Tôi thực sự thích Qt, nhưng nó hơi nặng đối với nhiều ứng dụng. Đôi khi bạn không cần mức độ phức tạp đó. Đôi khi bạn chỉ cần một cái gì đó đơn giản mà không cần tất cả chi phí của Qt. Không phải mọi ứng dụng đều cần phải hướng sự kiện và C ++ cung cấp một bộ mẫu hợp lý. Boost cung cấp một bộ rất tốt khác và bao gồm rất nhiều chức năng cấp thấp (tệp, ổ cắm, con trỏ được quản lý, v.v.) mà QT thực hiện.

Các ứng dụng khác có các yêu cầu cấp phép không hoạt động tốt với giấy phép thương mại của GPL, LGPL hoặc Qt. GPL không phù hợp với phần mềm thương mại. LGPL không phù hợp với phần mềm được liên kết tĩnh và giấy phép thương mại phải trả tiền - điều mà nhiều người không sẵn sàng trả.

Một số có cân nhắc về bảo mật hoặc tính ổn định không cho phép các thư viện phức tạp như Qt.

Bạn cần chạy moc để xử lý trước các nguồn của bạn. Đó không phải là một vấn đề lớn, nhưng nó có thể gây khó khăn cho người dùng mới. Rất nhiều lập trình viên nghĩ rằng bạn cần sử dụng qmake với Qt, nhưng đó là một cách hiểu sai. Có thể cắm Qt vào các hệ thống xây dựng khác khá dễ dàng.

Một số mục tiêu rất hạn chế bộ nhớ hoặc CPU.

Có một số vấn đề nền tảng cụ thể trong đó. Hầu hết các gotchas là không có giấy tờ. Xây dựng một ứng dụng đủ lớn và bạn sẽ gặp phải chúng và tự hỏi chuyện gì đang xảy ra (từ chối trách nhiệm, lần cuối cùng tôi sử dụng Qt trong cơn giận dữ là hơn 18 tháng trước, vì vậy nó có thể đã được cải thiện).

Chỉ có C ++. Các ràng buộc ngôn ngữ khác tồn tại, nhưng chúng có xu hướng che giấu hoặc phơi bày kém rất nhiều chức năng mà bạn muốn Qt cho.

Có rất nhiều lý do để không sử dụng Qt, đó là lý do tại sao có những lựa chọn thay thế. Nếu tất cả những gì bạn có là một cái búa thì mọi vấn đề sẽ trông giống như một cái đinh.

Điều quan trọng nhất nhưng không được đề cập. Trong dự án lớn, một điều gây ra rất nhiều vấn đề và mã không cần thiết. Cơ chế khe tín hiệu của Qt không hiệu quả. Các widget Qt không cung cấp các tín hiệu cần thiết cho các widget đơn giản. Ví dụ: bạn không thể đặt tín hiệu cho onHover, onMouse Entry, onMouseLeave, onKeyRelazed, onLostF Focus, onGainF Focus, v.v.

Có, bạn có thể sử dụng các sự kiện NHƯNG !!! bạn đã tạo lớp mới cho mỗi widget với sự kiện tùy chỉnh. Đây là mất hiệu quả rất lớn;

• Bạn đã viết lại từng sự kiện đối tượng widget tùy chỉnh có những thay đổi nhỏ.
• Bạn mất tất cả những thứ Qt Designer. Bạn phải quảng bá mọi widget với các sự kiện tùy chỉnh.
• Dự án trở nên lớn hơn và khó để duy trì.
• Bạn bắt đầu không thích qt vì điều này. Và bắt đầu nói về cách .net cung cấp cho các đại biểu, cách nó tốt hơn nhiều so với khe tín hiệu, cách các thành phần .net (widget) thường cung cấp mọi sự kiện mà bạn có thể tưởng tượng. Và vân vân.

Một trong những trường đại học của tôi đã viết lớp hộp tổ hợp mới cho mỗi tiện ích hộp tổ hợp vì anh ta phải sử dụng một số sự kiện không có tín hiệu. Câu chuyện có thật...

Tuy nhiên, Qt là khung UI C ++ tốt nhất cho đến nay với những thăng trầm.

theo quan điểm của riêng tôi, học lập trình C ++ đơn giản hơn việc rơi vào các ngôn ngữ khác che giấu sự phức tạp của chúng và lập trình viên không biết điều gì thực sự xảy ra trong nền. Mặt khác, Qt, thêm một số lợi ích so với C ++, để làm cho nó ở cấp độ cao hơn C ++ bản địa. Do đó, Qt C ++ là một khuôn khổ tuyệt vời cho những ai muốn phát triển các nhiệm vụ cấp thấp, hoặc các nhiệm vụ cấp cao, với cách thức tương tự. C ++ là (bởi một số thực tiễn) một ngôn ngữ phức tạp và đơn giản. Phức tạp cho người muốn không thử thách với nó, đơn giản cho người thích nó. Đừng để nó phức tạp!

Lý do thực tế không phải là kỹ thuật.

Mọi người xảy ra khác nhau. Vì vậy, sự lựa chọn của họ. Đồng nhất không phải là một tính năng của con người.