Почему не больше настольных приложений, написанных с помощью Qt? [закрыто]

202

Насколько я знаю и понял из моего опыта работы с Qt, это очень хорошая и простая в освоении библиотека. Он имеет очень хорошо разработанный API и является кроссплатформенным, и это только две из многих функций, которые делают его привлекательным. Мне интересно знать, почему больше программистов не используют Qt. Есть ли недостаток, который говорит против этого? Какая особенность делает другие библиотеки лучше, чем Qt? Вопрос связан с лицензированием?

Dehumanizer
источник
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, потому что он используется для курсов в колледже для новичков, а новые программисты получают больше шума, чем опытные)
Билли ONEAL
12
@ Джорджио: Хм, вы должны думать о таких вещах в C #. Понятие «кому это принадлежит» выходит далеко за рамки «кто звонит delete». Тот факт, что умные указатели делают это явным, не является недостатком языка; и если вы не думаете о таких вещах, вы будете генерировать мусор на любом языке высокого уровня, который я тоже видел.
Билли ОНил

Ответы:

177

На самом деле я не собираюсь это называть ответом, но по этим причинам я лично не использую Qt. Об этом можно сказать много хорошего, а именно то, что API работает большую часть времени и плавно соединяет платформы. Но я не использую Qt, потому что:

  1. В некоторых случаях это просто не выглядит как нативные программы. Разработка единого пользовательского интерфейса для всех платформ сама по себе не будет выглядеть правильно при перемещении с компьютера на компьютер по различным причинам визуального стиля. Например, на компьютерах Mac разделенные полосы обычно относительно толстые, а кнопки маленькие и округлены с помощью значков. На компьютерах с Windows разделенные полосы обычно узкие, а кнопки более текстовые с более квадратным дизайном. Тот факт, что вы можете написать один пользовательский интерфейс для каждой платформы, не означает, что вы должны делать это для большинства приложений.
  2. Qt не является библиотекой C ++. Это требует отдельного шага компиляции, что значительно усложняет процесс сборки по сравнению с большинством других библиотек.
  3. В результате (2) IDE и инструменты C ++ могут помечать выражения Qt как ошибки, потому что они не понимают специфику Qt. Это почти заставляет использовать QtCreator или текстовый редактор vim.
  4. Qt - это большое количество исходного кода, который должен присутствовать и предустанавливаться на любой машине, которую вы используете перед компиляцией. Это может значительно усложнить настройку среды сборки.
  5. Он доступен только в рамках LGPL, что затрудняет использование одного бинарного развертывания, когда нужно выпустить под более ограничительной или менее ограничительной лицензией.
  6. Он генерирует чрезвычайно большие скомпилированные двоичные файлы по сравнению с аналогично написанными «простыми старыми приложениями» (за исключением приложений, написанных для KDE).
Билли ОНил
источник
11
@Dehumanizer: есть лицензия LGPL, и есть коммерческая лицензия. Коммерческая лицензия со стороны лицензиата составляет тысячи долларов и не позволяет распространять ее и т. Д. Для проектов с открытым исходным кодом по либеральным лицензиям, таким как BSD, MIT или Boost, где авторы не зарабатывают кучу денег и желают для выпуска своего кода под свободной лицензией зависимость от LGPL нецелесообразна, но разработчики, как правило, не могут позволить себе коммерческое лицензирование.
Билли ОНил
27
№ 6 - главная причина, по которой я этого избегаю. Я имею в виду, что мне не нужна большая, неуклюжая программа, и мне не нравится привязываться к конкретной лицензии, но на самом деле отсутствие хорошего, естественного внешнего вида - вот что мешает мне. Последние версии OSX и Windows, в частности, проделали фантастическую работу по созданию своих собственных интерфейсов красивыми, быстрыми и функциональными, и я бы лучше использовал всю работу, которую они уже сделали для меня; Я считаю, что многие программы без естественного внешнего вида кажутся мне дешевыми и хакерскими (не всегда, но это немного раздражает).
Грег Джексон
16
Ваш номер 6 должен быть номер 1. Это является далеко самой большой проблемой с Qt. Во многих случаях он просто не использует нативные API. Мне нравится, что мое программное обеспечение выглядит нативно. Пользователям это тоже нравится. Я никогда не видел приложение Mac, созданное с помощью Qt, которое выглядело бы как приложение Mac. Ни у кого нет других пользователей Mac, и они придирчивы к такого рода вещам. Вы теряете все преимущества его «кроссплатформенности», если используете его только для создания приложений Linux, и это единственное место, где он выглядит нативно, потому что в действительности нет ничего нативного.
Коди Грей
41
кроме проблемы «родного» вида больше нет. Старая согласованность приложений Windows теперь сводит на нет все уникальные BLOB-объекты, свечения и анимации, которые есть у WPF и silverlight. Взгляните на панель управления Office или Windows 7, чтобы увидеть, как даже флагманский продукт MS имеет непоследовательный графический интерфейс. Пользователи Mac - ну, у вас есть очень верное мнение.
gbjbaanb
5
@TrevorBoydSmith: Извините, но вы не правы. Qt является единственной платформой, которая использует предварительную обработку. Период. Проверьте GNOME, FLTK, WX и друзей, и покажите мне шаг предварительной обработки. Вы не найдете его. Некоторые другие библиотеки поставляются с другими системами сборки, но, в конце концов, это библиотеки C ++, которые могут быть собраны любым компилятором C ++. Что касается «сырого win32, которого нет в моих причинах», то оно присутствует в моих причинах как № 5 и № 6.
Билли ONEAL
115

Как говорят люди, каждый инструмент подходит для каждой проблемы и ситуации ...

Но если вы программист на C ++, Qt - ваш фреймворк. Нет соперника.

Мы разрабатываем комплексное коммерческое приложение для медицинской визуализации, и Qt держится.

Я не говорю, что «минусы», которые люди говорят об этом, являются ложными, но у меня есть ощущение, что они не пробовали Qt в течение длительного времени (он постоянно улучшается с каждой новой версией ...) И, в основном, все вопросы, которые они комментируют, не являются проблемой, если вы позаботитесь.

Несогласованность платформы пользовательского интерфейса: только если вы используете виджеты пользовательского интерфейса «как они есть», без каких-либо настроек или пользовательских рисунков.

Перегрузка препроцессора Qt: Только если вы используете механизм слотов сигналов или наследование QObject, когда в этом нет особой необходимости.

Кстати, мы до сих пор пишем приложения на C # .NET и занимаемся этим уже давно. Поэтому я думаю, что у меня есть перспектива.

Как я уже сказал, каждый инструмент для каждой ситуации,

но Qt, без сомнения, является последовательной и полезной основой.

Иниго
источник
9
+1 Так! Я просто хотел написать то же самое. Самая глупость - это «не открытый источник / коммерческий аргумент». Удивительно, насколько неправильно многие люди понимают термин Open-Source. Qt был открытым исходным кодом, так как я использую его (1.4). И раньше у него была самая справедливая лицензия: зарабатывать деньги с помощью Qt -> pay.
Валентин Хайниц
16
Да, и я действительно не забочусь о добавлении 10 МБ библиотек DLL в приложение, содержащее 50 МБ графики и еще 200 МБ видеоуроков и данных :)
Петър Петров
9
Пространство, необходимое для Qt, в наши дни дешевое.
trusktr
5
Это в значительной степени соответствует моему опыту работы с Qt (каркас виджетов, я до сих пор не использовал QML / QtQuick для чего-либо серьезного). Подходит для написания больших приложений со сложными требованиями к пользовательскому интерфейсу. Как только вы изучите это, вы можете быть очень продуктивным. Упомянутые минусы (отдельный этап компиляции для перемещения, пользовательские файлы и т. Д.) Не являются проблемой, если система сборки правильно настроена. Я могу порекомендовать либо qmake, либо cmake.
Нильс
Начиная с 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 ++. Люди привыкли к программированию в стиле Java или Python, вероятно, на самом деле лучше.

На самом деле я потратил много времени и усилий на исследование и разработку способа вернуть безопасность типов и подключить сигнал Qt к любому объекту-функтору: http://crazyeddiecpp.blogspot.com/2011/01/quest-for-sane-signals -в-кварта шаг-1.html

То, что я хочу сделать, - это базовая, повседневная разработка на C ++, которую Qt moc делает практически невозможной ... что само по себе совершенно не нужно в наши дни, если это вообще было так.

Честно говоря, я застрял с этим, потому что, если вы хотите проводить автоматическое тестирование пользовательского интерфейса, Qt является практически единственной игрой в городе, кроме MFC ... которая так 1980 года (это ужасно тяжело работать в этом дерьме). Кто-то может сказать, WX, но у него есть еще более серьезные проблемы. GTKmm был бы моим первым выбором, но так как он все нарисован владельцем и не обеспечивает доступность ... не может управляться стандартным программным обеспечением тестирования. Qt достаточно сложен в этом отношении ( едва работает, когда вы изменяете плагин доступности).

Эдвард Стрендж
источник
1
Из интереса, что вы видите в качестве основных проблем с WX?
Том Андерсон
7
@Tom - плохая документация, особенно для новых вещей. Компоненты AUI практически не документированы с отсутствием больших разделов, что затрудняет их использование в производственной среде. Документация для процесса события в основном ошибочна в отношении пути, по которому идет, по крайней мере на win32. Потратил много времени, крича на компьютер: «Это должно работать!» прежде чем углубляться в код глубокой обработки, выясните, что то, что делает WX, не следует документам, и то, что я делал, НИКОГДА не сработало.
Эдвард Стрендж,
1
Я также был обеспокоен принятием библиотеки сетки свойств в основную линию. Я использовал эту библиотеку, и она показала множество фундаментальных недостатков дизайна в дополнение к фактической нехватке знаний от имени программиста, который ее написал (например, называемых виртуальными функциями в конструкторах). Это, и плохое состояние AUI, показали тенденцию к худшим стандартам. Я также не большой поклонник статических таблиц событий, хотя, по крайней мере, есть другой способ реагировать на события ... в отличие от MFC, который в любом случае слишком интересен для WX.
Эдвард Стрендж,
Благодарю. Я использовал его только немного, и через API wxPython, где это выглядело довольно хорошо. Я могу оценить, что это скрыло бы часть зла, но также и то, что я недостаточно глубоко вовлечен, чтобы столкнуться с более серьезными проблемами. Что-то, что я должен знать.
Том Андерсон
1
все, что реагирует на сигнал, должно быть Q_OBJECT, нет в настоящее время ... Теперь статические функции, функции и даже лямбда-функции могут отвечать на сигнал (вы можете использовать указатели функций в качестве слотов). Классы No-QObject могут также иметь слоты-члены, если вы подключаетесь к ним с помощью std :: bind для преобразования члена экземпляра в указатель на функцию.
Виниций А. Хорхе
28

Одна из причин не использовать Qt состоит в том, что если вы пишете только для одной архитектуры, такой как Windows, вы можете использовать C # / .NET (или Cocoa на Mac), потому что они всегда смогут воспользоваться преимуществами последних звонков-и - свистит из ОС.

Если вы пишете кроссплатформенные приложения, то вы, возможно, уже в значительной степени наделены другой технологией, такой как Java (т.е. вы работаете в «магазине Java»). Ваш выбор технологии может быть продиктован экосистемой, в которой вы разрабатываете, такой как специфичные для языка API. В подобных случаях минимизация количества технологий может быть полезной.

Третья причина, о которой я могу подумать, заключается в том, что Qt основан на C ++, а C ++ является сравнительно сложным / опасным языком для программирования. Я думаю, что это язык для профессионалов. Если вам нужна максимальная производительность и способность быть дотошным, то C ++, вероятно, все еще остается лучшей игрой в городе. На самом деле, Qt облегчает многие проблемы управления памятью, если вы настраиваете их на выпадение из области видимости. Кроме того, сам Qt хорошо защищает пользователя от многих неприятных проблем C ++. У каждого языка и основы есть свои плюсы и минусы. Это очень, очень сложный вопрос, который обычно можно суммировать с помощью надстройки, часто встречающейся в закусочных: скорость, качество и цена (но вы можете выбрать только два).

Хотя правила говорят, что я должен сосредоточиться на ответе на этот вопрос, я хочу опровергнуть некоторые из вопросов, поднятых Билли Онилом, который, я думаю, хорошо справляется с обобщением часто цитируемых причин, по которым не следует использовать Qt:

  1. Qt действительно является C ++ библиотекой / framework / заголовочными файлами. Он дополненмакропроцессором (moc), который включает сигналы и слоты, среди прочего. Он преобразует дополнительные макрокоманды (такие как Q_OBJECT), так что у классов есть самоанализ и всевозможные другие полезности, о которых вы можете подумать как о добавлении функциональности Objective C в C ++. Если вы знаете достаточно о C ++, чтобы обижаться из-за отсутствия чистоты, то есть вы профессионал, то 1) не используйте Q_OBJECT и тому подобное или 2) будьте благодарны за это и программируйте в очень ограниченных случаях где это вызывает проблему. Для людей, которые говорят: «Используйте Boost для сигналов и слотов!» тогда я бы сказал, что вы обмениваете одну «проблему» на другую. Boost огромен, и у него есть свои часто упоминаемые проблемы, такие как плохая документация, ужасные API и кроссплатформенные ужасы (подумайте о старых компиляторах, таких как gcc 3).

  2. Для поддержки редактора это также следует из 1, я несколько согласен. На самом деле, Qt Creator - ИМХО лучший графический редактор C ++, даже если вы не используете материал Qt. Многие профессиональные программисты используют emacs и vim. Кроме того, я думаю, что Eclipse обрабатывает дополнительный синтаксис. Таким образом, нет проблем с макросами Qt (Q_OBJECT) или добавлениями сигналов / слотов. Вы, вероятно, не найдете эти макросы в Visual Studio, потому что (я признаю) они являются дополнениями к C ++. Но, в общем и целом, люди из C # / .NET в любом случае не собираются использовать Qt из-за того, что они обладают большой функциональностью, покрытой их собственными проприетарными методами.

  3. Что касается размера источника Qt, если он компилируется за ночь, кого это волнует? Я скомпилировал Qt 4 на своем двухъядерном Macbook «меньше, чем за ночь». Я, конечно, надеюсь, что это не то, что движет вашим решением использовать или не использовать определенную технологию. Если это действительно проблема, то вы можете скачать предварительно скомпилированные SDK для Mac, Linux и Windows с веб-сайта Qt.

  4. Лицензирование доступно в трех вариантов: 1) Фирменные лицензии в случае , если вы хотите изменить Qt самих и не делиться, или скрыть тот факт , что один использует Qt и не готов дать атрибуции (может быть очень важно для брендинга и изображений) 2! ) GPL и 3) LGPL. Да, есть проблемы со статическим линкованием (сворачивание всего Qt в двоичный файл) - но я думаю, что это больше, потому что нельзя заглянуть внутрь и заметить, что вы используете Qt (атрибуция!). Я пытался купить проприетарную лицензию у Digia, и они сказали мне: «за то, что ты делаешь, тебе это действительно не нужно». Ух ты. От бизнеса, который занимается продажей лицензий.

  5. Размер двоичного файла / пакета связан с тем, что вы должны распространять материал Qt людям, у которых его нет: Windows уже есть? Visual Studio материал или вы должны установить во время выполнения. Mac уже поставляется с огромным Какао и может быть динамически связан. Хотя я не занимаюсь распространением, я никогда не сталкивался с проблемой распространения статического файла размером ~ 50 мегабайт (который я могу сделать еще меньше с помощью некоторых утилит для бинарного удаления / сжатия, таких как UPX). Мне просто все равно, чтобы сделать это, но если бы пропускная способность была проблемой, я бы добавил шаг UPX в мой скрипт сборки.

  6. Что определяет "Родной взгляд и чувство?" Я думаю, что «большинство» согласится с тем, что Mac ближе всего подходит к единому внешнему виду. Но здесь я сижу, глядя на Safari, iTunes, Aperture, Final Cut Pro, Pages и т. Д., И они ничем не похожи, несмотря на то, что они сделаны производителем ОС. Я думаю, что аспект «чувствовать» является более актуальным: стилизация виджетов, отзывчивость и т. Д. Если вы заботитесь об отзывчивости, то здесь есть веская причина использовать C ++, а не Java или какой-либо другой высокодинамичный язык. (Цель C тоже потрясающая, но я пытаюсь развеять мифы о Qt)

Таким образом, это сложный вопрос. Но я хотел бы отметить, что я думаю, что есть меньше причин «не использовать Qt», как можно подумать, основываясь на мифах и устаревшей информации.

Эрик Браун
источник
1
Чего я не понимаю, так это того, что эти кроссплатформенные библиотеки не являются просто функциями-обертками или даже лучше; if defs вокруг функций Какао, Win32, KDE / Gnome, обеспечивая лучший интерфейс, со всеми его функциями.
MarcusJ
2
@MarcusJ Написать обертку вокруг одного инструментария явно нетривиально, не говоря уже о 4 или более - но если вы думаете, что это так просто, вы можете попробовать. Что касается идеи, что это может быть достигнуто с помощью только условной предварительной обработки ... вы, должно быть, шутите, верно?
underscore_d
@MarcusJ libui - это именно то, что нужно (но без поддержки KDE).
Деми
Я хочу добавить, что теперь вы можете использовать Qt / QML с .NET. Вам не нужно трогать C ++. github.com/qmlnet/qmlnet PS: я автор.
Пол Кнопф
26

Частично это лицензирование. См. Https://en.wikipedia.org/wiki/Qt_(software)#Licensing для некоторых из истории лицензирования. До 2000 года люди, которые сильно интересовались открытым исходным кодом, не использовали Qt. Период. (Это было, по сути, первоначальной мотивацией для разработки Gnome.) До 2005 года люди, которые хотели иметь возможность выпускать бесплатное программное обеспечение для Windows, не использовали Qt. Даже после этой даты люди, которые хотели свободного программного обеспечения под чем-то иным, чем GPL, просто не имели возможности использовать Qt. Таким образом, любой проект свободного программного обеспечения, который старше этих дат, не может использовать Qt. И, конечно, люди, пишущие собственный код, должны были заплатить за эту привилегию.

Кроме того, это не так, как будто есть нехватка других вариантов. Например, WxWidgets , GTK + и Tk - это кроссплатформенные наборы инструментов с открытым исходным кодом.

Кроме того, долгое время Windows была настолько доминирующей на настольных компьютерах, что многие программы содержали контент только для Windows. Если вы устанавливаете набор инструментов Microsoft, проще просто использовать проприетарные вещи Microsoft, чем беспокоиться о чем-то другом, и многие программисты так и сделали.

btilly
источник
1
@btilly: GTK + является кроссплатформенным. Например, клиент Pidgin IM написан на GTK +.
Билли ОНил
1
Хорошо, однако, можно «как-то» запустить на Windows :)
Dehumanizer
6
Просто установите GIMP на Windows и посмотрите.
user281377
2
Да, и GIMP хорошо работает на Windows, но он определенно не вписывается в интерфейс Windows 7.
Алан Б
5
Pidgin, вероятно, является лучшим примером GTK для Windows. Это не делает ничего особенного, но подходит и может быть 10 или более лет?
Брендан Лонг
14

Я согласен почти со всеми причинами, описанными выше, однако многие люди здесь сказали, что они не будут использовать Qt из-за дополнительных издержек, которые он несет с собой. Я не согласен с этим, потому что все наиболее распространенные на сегодняшний день языки (Java, C # и Python) несут немалые накладные расходы сами.

Во-вторых, Qt делает программирование на C ++ настолько простым и понятным, что компенсирует дополнительные ресурсы, которые он использует. Я встречал довольно много консольных приложений, написанных на Qt, а не на стандартном C ++, из-за легкости их написания.

Я бы сказал, что производительность Qt выше, чем у C / C ++, но меньше, чем у таких языков, как Python.

WKS
источник
2
Я предполагаю, что все это связано с индивидуальным опытом, потому что я могу кодировать ОК на C ++ 14, но каждый раз, когда я смотрю на какой-то код Qt, мне приходится прищуриться, чтобы признать его тем же языком ... так что я определенно не понимаю не думаю, что вы подразумеваете здесь единодушное повышение производительности.
underscore_d
1
@underscore_d, очевидно, если вы очень хорошо знаете C ++ и не знаете Qt, вы не будете более продуктивны с последним. Но когда вы знакомитесь и с C ++, и с Qt, фреймворк действительно облегчает и ускоряет реализацию многих вещей (C ++ 11, 14 и т. Д. Заполняют пробел, но еще не полностью).
ymoreau
11

Это действительно не попытка развязать пламенную войну, я просто хотел бы остановиться на некоторых моментах.

Вероятно, настоящая причина того, что Qt не так широко используется, заключается в том, что это C ++, и все меньше людей используют c ++ для настольных приложений.

Qt не является библиотекой C ++. Это требует отдельного шага компиляции, что значительно усложняет процесс сборки по сравнению с большинством других библиотек.

Vs-addin для visual studio делает это автоматически, как и собственный процесс создания в Qt. Компилятор ресурсов, используемый для создания диалогов для MFC, также является отдельным шагом, но это все еще c ++.

Qt - это большое количество исходного кода, который должен присутствовать и предустанавливаться на любой машине, которую вы используете перед компиляцией. Это может значительно усложнить настройку среды сборки.

Существует бинарная загрузка для каждой версии visual studio, а сборка из исходного кода - это одна команда. Я не вижу, что размер исходного кода SDK так важен в наши дни. Visual Studio теперь устанавливает все библиотеки C ++, а не позволяет вам выбирать, и в результате размер компилятора составляет> 1 ГБ.

Он доступен только в рамках LGPL, что затрудняет использование одного бинарного развертывания, когда нужно выпустить под более ограничительной или менее ограничительной лицензией.

LGPL относится только к lib, это не влияет на ваш код. Да, это означает, что вы должны поставлять DLL, а не один двоичный файл (если вы не платите), но в мире, где вам нужно загрузить среду выполнения Java или обновление .Net для крошечной утилиты, это не такая уж большая проблема. Это также меньше проблем на платформах с одним ABI, так что другие приложения Qt могут делиться библиотеками.

В некоторых случаях это просто не выглядит как нативные программы. Разработка единого пользовательского интерфейса для всех платформ сама по себе не будет выглядеть правильно при перемещении с компьютера на компьютер по различным причинам визуального стиля.

Предполагается использовать родные виджеты и темы. Я должен признать, что я делаю в основном технические приложения, поэтому мои пользователи не слишком заботятся о стиле. Особенно в Windows новая мода на то, чтобы все стилизовалось под виджет для смартфона, означает, что в любом случае стандарта становится все меньше и меньше.

Мартин Беккет
источник
1
Многие крупные компании-разработчики программного обеспечения создают коммерческие приложения на C ++, но я не знаю многих, кто использует QT. Поэтому, хотя я понимаю, что разработчики, не использующие C ++, могут избегать QT, есть и другие причины избегать QT, даже когда вы пишете приложение для C ++, это может показаться. На самом деле, нет никакого кроссплатформенного языка и инструментария GUI, с которым я не могу придраться. Похоже, что кросс-платформенная разработка - просто ПРОСТО ЖЕСТКО, и что делать это хорошо никогда не бывает легко и бесплатно, и что обещание, которое дает QT (написать свой графический интерфейс один раз и использовать этот графический интерфейс везде), недостаточно.
Уоррен П
Большая часть программного обеспечения C ++ для настольных компьютеров находится либо в MFC, потому что оно было запущено 20 лет назад, либо использует внутренний инструментарий, запущенный 20 лет назад, чтобы избежать MFC (например, MS-Office или Autocad). Я сомневаюсь, что очень много написано на C ++ / CLR с WPF. Но даже без учета кроссплатформенности я считаю Qt лучшим (или наименее худшим!) Настольным инструментарием. Как и большинство людей, мы движемся к веб-интерфейсу (возможно, в QtQuick / QML) и серверной части C ++ - которая, вероятно, будет использовать сигналы / слоты Qt, но без графического интерфейса
Мартин Беккет
Я согласен. Наименее худшее. И даже в приложениях только для Windows я предпочел бы отлаживать проблемы QT, а не проблемы MFC.
Уоррен П
@WarrenP - да, я не пропускаю поиск кода проекта по всем материалам, отсутствующим в MFC. Но благодаря новой находящейся в MSFT любви к нативному коду - они не сделали ничего, чтобы упростить написание графического интерфейса.
Мартин Беккет
7

Причина проста: у него нет хороших привязок ко всем основным языкам, и это не всегда волшебно подходит для работы под рукой.

Используйте правильный инструмент для работы. Если я пишу простое приложение для командной строки, зачем мне это раздувать с помощью Qt просто ради этого?

В качестве более общего ответа (который я могу дать, потому что я здесь уместен), некоторые программисты просто никогда не пойдут на это и решат его использовать. В некоторых случаях нет особой причины, кроме того, что программист никогда не находил в этом необходимости и не изучал ее.

Гонки легкости на орбите
источник
1
Но Qt предоставляет возможность писать только консольное приложение. Не так ли?
дегуманизатор
9
@Dehumanizer: понятия не имею. Но зачем мне использовать его для небольшого утилиты? Какую пользу это принесет мне, когда я смогу написать приложение на стандартном C ++? Кажется, вы ищете причину для использования библиотеки , которая является обратным способом программирования.
Гонки легкости на орбите
12
@Dehumanizer: как я уже сказал, это обратный подход. Когда вы обнаружите необходимость в библиотеке, вы узнаете, а затем вы можете пойти и попробовать несколько и посмотреть, что лучше соответствует вашим потребностям. Попытка собрать мнение о библиотеке, когда у вас нет варианта использования, является глупой задачей.
Гонки легкости на орбите
3
«Если я пишу простое приложение для командной строки, зачем мне его раздувать с Qt просто ради этого», есть по крайней мере один очень известный инструмент без
графического интерфейса,
4
@Dehumanizer, например, когда вам приходится иметь дело с файлами, XML, Unicode, JSON, RegeXP, Concurency, базами данных и т. Д., Очень быстро и не хотите загружать, принимать, поддерживать десятки сторонних библиотек.
Валентин Хайниц
5

Каркасы как Qt подходят , когда вы больше озабочены ваш продукт ищет то же самое на всех платформах , чем с вашего продукта , глядя прямо на всех платформах. В наши дни все чаще такие приложения переходят на веб-технологии.

Калеб
источник
4

Я согласен с тем, что Qt - хорошая среда для работы. Тем не менее, у меня есть ряд проблем:

  1. Он написан на C ++, который является языком действительно низкого уровня. Один только тот факт, что это C ++, сделает каждого программиста Qt значительно менее продуктивным по сравнению с Frameworks, написанным на других языках. Моя главная претензия к C ++ как к языку разработки GUI состоит в том, что в нем практически отсутствует понятие автоматического управления памятью, что делает процесс разработки намного более подверженным ошибкам. Это не интроспективно, что делает отладку намного сложнее. Большинство других основных инструментов GUI имеют некоторое представление об автоматическом управлении памятью и самоанализе.
  2. Каждый кроссплатформенный инструментарий страдает от проблемы, заключающейся в том, что он может реализовать наименьший общий знаменатель из всех поддерживаемых платформ. Это, а также различные рекомендации по пользовательскому интерфейсу на разных платформах в значительной степени ставят под сомнение целесообразность кроссплатформенных графических интерфейсов в целом.
  3. Qt очень сильно сконцентрирован на кодировании всего вашего пользовательского интерфейса. Несмотря на то, что вы можете использовать QtDesigner для создания некоторых частей вашего пользовательского интерфейса, он серьезно отсутствует по сравнению, скажем, с (Cocoa / Obj-C) Interface Builder или инструментами .Net.
  4. Несмотря на то, что Qt включает в себя множество низкоуровневых функциональных возможностей приложения, его нельзя сравнить с наличием платформы, адаптированной для конкретной платформы. Собственные библиотеки операционной системы для Windows и OSX значительно более мощные, чем реализации Qt. (Вспомните звуковые рамки, низкоуровневый доступ к файловой системе и т. Д.)

Тем не менее, я люблю использовать PyQt для быстрого прототипирования приложений или собственных приложений. Использование Python для выполнения всего кодирования облегчает проблемы с C ++ и фактически делает Qt очень приятным местом.


Отредактируйте в ответ на некоторые комментарии:

Когда я писал о том, что Qt написан на C ++, я не столько жаловался на сам Qt, сколько на среду, в которой он живет. Это правда, что Qt очень хорошо управляет своими собственными ресурсами, но все ваши GUI-связанные, но- код not-Qt также должен быть написан на C ++. Даже там Qt предоставляет много хороших инструментов, но в конечном итоге вам придется иметь дело с C ++ на этом уровне. Qt делает C ++ переносимым, но это все еще C ++.

Что касается самоанализа, то я имею в виду следующее: самые сложные случаи для отладки - это когда у вас есть указатель на какой-то объект, который ведет себя не так, как вы думаете. С C ++ ваш отладчик может немного заглянуть внутрь этого объекта (если в нем есть информация о типе на данный момент), но даже это не всегда работает. Взять, с другой стороны, Какао в той же ситуации. В Cocoa / Obj-C вы сможете отправлять сообщения («функции вызова») объекту прямо в отладчике. Вы можете изменить состояние объекта, запросить его атрибуты, запросить его тип и имена функций ... Это может сделать отладку намного удобнее. Qt / C ++ не имеет ничего даже близко к этому.

bastibe
источник
11
1. Qt заботится об управлении памятью самостоятельно, вам не нужно вызывать «delete» после каждого «new». 1a. C ++ НЕ является языком низкого уровня, это язык высокого уровня с низкоуровневыми «способностями». 3. Я согласен, но Qt предоставляет возможность создавать пользовательский интерфейс одновременно с QtDesigner и с «простым кодом». 4. Согласитесь еще раз, но Qt также предоставляет возможность использовать нативные API.
дегуманизатор
11
на ваш взгляд № 1. Я думаю, что в c ++ действительно есть полуавтоматическое управление памятью: если вы используете умные указатели, такие как std :: auto_ptr или boost :: shared_ptr и т. д., вам, как правило, не нужно заботиться об освобождении памяти. Контейнеры такого типа можно создавать и для других ресурсов (файлов, системных ресурсов, которые должны быть освобождены). Использование RAII-паттерна очень помогает в управлении памятью, и по мере того, как оно перерастает в вас, вам не нужно беспокоиться о памяти.
Deo
8
«Тот факт, что это C ++, сделает каждого программиста Qt значительно менее продуктивным по сравнению с Frameworks, написанным на других языках». [нужная цитата]
Натан Осман
4
@ SK-логика: хотя я думаю, что понимаю все слова в вашем третьем предложении, я понятия не имею, что вы говорите. Что такое «уровень ограничения абстракции»? В этом отношении ваше первое предложение является ложным, учитывая определение Википедии «язык низкого уровня».
Дэвид Торнли
6
@ SK-logic: Шаблонное метапрограммирование завершено по Тьюрингу, и есть люди, достаточно умные и знающие, чтобы воспользоваться этим. RAII не большая сборка мусора, но тот факт, что он работает для всех видов ресурсов, более или менее компенсирует это. Теперь, в частности, какая абстракция работает в Java, но не в C ++?
Дэвид Торнли
3

Мне действительно нравится Qt, но он немного тяжеловесен для многих приложений. Иногда вам просто не нужен этот уровень сложности. Иногда вам просто нужно что-то простое без всяких накладных расходов на Qt. Не каждое приложение должно быть управляемым событиями, и C ++ предоставляет разумный набор шаблонов. Boost предоставляет еще один очень хороший набор и включает в себя множество низкоуровневых функций (файлов, сокетов, управляемых указателей и т. Д.), Которые делает QT.

Другие приложения имеют лицензионные требования, которые плохо сочетаются с GPL, LGPL или коммерческой лицензией Qt. GPL не подходит для коммерческого программного обеспечения. LGPL не подходит для статически связанного программного обеспечения, а коммерческая лицензия стоит денег - то, что многие не хотят платить.

У некоторых есть соображения безопасности или стабильности, которые не позволяют использовать сложные библиотеки, такие как Qt.

Вам нужно запустить moc для предварительной обработки ваших источников. Это не большая проблема, но она может быть сложной для нового пользователя. Многие программисты думают, что вам нужно использовать qmake с Qt, но это неправильно. Можно довольно легко подключить Qt к другим системам сборки.

Некоторые цели очень ограничены в памяти или процессоре.

Там есть некоторые специфичные для платформы ошибки. Большинство этих ошибок недокументированы. Создайте достаточно большое приложение, и вы столкнетесь с ним и будете удивляться, что происходит (отказ от ответственности, последний раз, когда я использовал Qt в гневе, было более 18 месяцев назад, поэтому, возможно, он улучшился).

Это только C ++. Существуют другие языковые привязки, но они, как правило, скрывают или плохо раскрывают многие функции, для которых вы хотите использовать Qt.

Есть много причин не использовать Qt, поэтому есть альтернативы. Если у вас есть только молоток, то каждая проблема будет выглядеть как гвоздь.

Адам Хос
источник
3

Самое важное, но не упомянутое. В большом проекте одна вещь вызывает столько проблем и ненужного кода. Механизмы слотов сигналов Qt неэффективны. Qt widgets не предоставляет необходимые сигналы для простых виджетов событий. Например, вы не можете установить сигналы для onHover, onMouseEnter, onMouseLeave, onKeyReleased, onLostFocus, onGainFocus и т. Д. Даже самый сложный виджет, такой как QTreeWidget, предоставляет один или два ультра простых бесполезных сигнала.

Да, вы можете использовать события, НО !!! у вас есть новый класс для каждого виджета с пользовательским событием. Это огромная эффективность, потерянная;

  • Вы переписали каждое настроенное событие объекта виджета с небольшими изменениями.
  • Вы теряете все вещи Qt Designer. Вы должны продвигать каждый виджет с помощью пользовательских событий.
  • Проект стал больше и его сложнее поддерживать.
  • Вы начали не любить qt из-за этого. И начинаем говорить о том, как .net предоставляет делегатов, как он намного лучше, чем сигнальный слот, как компоненты .net (виджеты) обычно предоставляют каждое событие, которое вы можете себе представить. И так далее.

Один из моих колледжей написал новый класс со списком для каждого виджета со списком, потому что ему пришлось использовать какое-то не сигнальное событие. Правдивая история...

Тем не менее, Qt является лучшим C ++ UI-фреймворком на данный момент со взлетами и падениями.

Obrix
источник
Что касается событий и создания новых классов: вы можете использовать фильтры событий в классах, которые должны реагировать на них.
MrFox
«Да, вы можете использовать события, НО !!! у вас есть новый класс для каждого виджета с пользовательским событием. - НЕ СОВСЕМ. Я просто заканчиваю с bool eventFilter, который обрабатывает несколько виджетов, а затем устанавливаюEventFilter (this) на все дочерние виджеты. И это не теряет эффективности и производительности программирования! На самом деле я никогда не использую «Продвигаемые виджеты» ... Я опускаю просто пустой пустой виджет, устанавливаю его как eventFilter и переопределяю большинство моих событий в моем основном классе cpp. Попробуйте, не больно :) Вы можете настроить почти ВСЕ в Qt, не создавая новые классы каждый раз
Петър Петров
3

По моему мнению, изучение программирования на C ++ проще, чем попадание в другие языки, которые скрывают их сложность, и программист не знает, что на самом деле происходит в фоновом режиме. Qt, с другой стороны, добавляет некоторые преимущества по сравнению с C ++, чтобы сделать его более высоким уровнем, чем нативный C ++. Таким образом, Qt C ++ является отличной средой для тех, кто хочет разрабатывать задачи низкого уровня или задачи высокого уровня одинаковым образом. C ++ (по некоторым практикам) сложный и простой язык. Комплекс для тех, кто хочет с этим не бороться, простой для тех, кто любит это. Не оставляй это из-за сложности!

user100691
источник
2

Фактическая причина не техническая.

Люди бывают разные. Как и их выбор. Равномерность - это не человеческая черта.

mouviciel
источник
Поэтому все люди ходят на ногах? Ну, те, у кого есть ноги, по крайней мере ...
Dtech