Нет ничего идеального под солнцем. Qt не является исключением, и у него есть ограничения: мы не можем использовать растровые изображения в потоке, отличном от GUI, мы не можем использовать QImage с форматом изображения 16 бит на канал и т. Д.
Какие ситуации заставили вас испортить дизайн из-за ограничений Qt?
Какие самые ненавистные причуды?
Каких дизайнерских решений следует избегать при использовании Qt в своих проектах?
qt
design-decisions
лозы
источник
источник
theчтоcornersздесь, конечно , нетQt, но это только мое интуитивное чувство, так как я русский :)Ответы:
Как ни странно, я бы сказал, что сила Qt также является одним из недостатков. Существует так много мощных конструкций и расширений, что код, который вы пишете в Qt, легко укореняется в «Qt way». Попытка извлечь функциональность на другой язык не только означает переписывание, вам нужно знать много специфичных для 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, например boost.
(Обратите внимание, что то же самое относится к std :: map против QMap, std :: vector против QVector и т. Д.)
Решение о том, какие части используют типы Qt, а какие используют STL, является важным конструктивным решением, имеющим серьезные последствия. И только потому, что Qt отказывается использовать стандартную библиотеку C ++.
ИМХО, это решение может пойти в любую сторону, в зависимости от проекта. Поэтому я не могу ответить на ваш вопрос, какой из них следует избегать.
источник
Это не дает прямого ответа на вопрос, но я думаю, что стоит упомянуть: возможно, самый «опасный» аспект Qt - это то, что Nokia оказалась в постели с MSoft ...
источник
Недавно я обнаружил, что QChar, несмотря на свое имя, на самом деле соответствует не одному символу, а единице кода UTF-16. Таким образом, когда вы хотите сканировать произвольный текстовый символ Unicode за символом, вы должны добавить алгоритмы для работы с высокими и низкими суррогатами, комбинирования символов и тому подобного.
источник