А еще не маловажный фактор это соотношение цена/качество. В свою очередь цена это совокупность человекочасов и стоимости этого самого человекочаса. Возьмем дву программистов: винАПИшник и Qt-шник. Будем считать что оба имеют одинаковую производительность, делают одинаковый процент ошибок и оценивают свое время одинаково. Как вы считаете кто из них быстрее напишет какое-нибудь ГУЕвое приложение? Я думаю, вы не будете спорить что на Qt это гораздо быстрее и займет гораздо меньше кода. То есть это:
а) будет дешевле
б) будет меньше ошибок в коде
Следовательно мы получим гораздо меньшую цену и более высокое качество.
Неужели вы считаете что программист должен каждый раз изобретать велосипеды? Тогда может стоит писать на асме всегда? ведь можно сделать все быстро, но вот только за какое время. Те же самые питон и руби это идеальные языки для написание фронтендов к каким-либо консольным утилитам. На них можно писать быстро и при этом достаточно безошибочно.
Если проект небольшой и однократный, то зачем тогда вообще нужен Qt. Если же вы используете Qt как основной рабочий инструмент, то без разницы какого размера проекты, деньги на лицензию вы отобьете очень быстро.
Вы меня прям все дальше и дальше удивляете;))) Что значит «Какое дело мне, пользователю до change request»??? Как раз таки пользователю самое прямое дело до change request, так как именно пользователь их отправляет разработчику.
Сильно сомневаюсь что это произойдет. Да и зачем? Если нужна либа, чтобы писать что-то для себя/друзей/внутреннего использования в фирме, то подойдет и ГПЛ версия. А если нужно писать что-то закрытое на коммерческой основе, то почему бы и не купить лицензию?
Пользователям нужен не только быстрый продукт, но еще и регулярно обновляемый продукт. А чем красивее написан код, тем проще поддерживать это приложение.
Сплеш-скрин для тяжелых приложений это панацея юзабилити. Только благодаря нему можно понять что приложение запускается, а не зависло где-то на пути, если у этого приложения очень большая фаза инициализации.
Вы знаете что такое Эльбрус? по сути это русский СПАРК-компьютер с четырьмя процами, каждый из которых по цифрам равен примерно второму пентиуму, а на деле первому.
Дак вот на этом Эльбрусе куте приложения имеют очень даже хороший отклик (причем не блокноты, а серьезные приложения работающие с сетью, с тяжелыми математическими алгоритмами, имеющие десятка два окон)
Вы про масштабируемость и реиспользование ничего не слышали?
Понятное дело что речь не идет про крохотные программки, которые пишутся для однократного использования. Я говорю про обычные приложения, которые развиваются. Если все писать монолитно, то любой change request может обернуться крайним геморроем для программиста, если же использовать нормальное проектирование ПО, то любое изменение в приложение сильно облегчается.
Ну вы бы еще разные языки сравнивали по тому как они Хелло Ворлд пишут;)
Уж если сравнивать то высоко нагруженные приложения, а там процент на использование ГУЯ очень невелик по сравнению с остальными затратами ресурсов и то что отрисовка кутешного ГУЯ слегка медленнее чем какого-нибудь другого (кстати сравнивать надо тоже с кросс-платформенными либами) уже не имеет никакого значения. А С++ он везде С++.
Что значит безумные цены? вы про три килобакса на девелопера? В Европе и США (про Россию я не говорю) тот же самый фрилансер, отобъет эти деньги за 2-3 более-менее нормальных заказа. По вашему это большая стоимость?
В Qt есть не только сигнал-слот но и евенты, которые корректно работают в многопоточных приложениях. Я например всегда пользуюсь сигналами для ГУЯ и евентами для синхронизации потоков.
По поводу использования QCoreApplication::processEvents(). Честно говоря никогда не использовал, потому что всегда выделяю ГУЕвый поток и доп поток для всего остального (или несколько потоков).
это самые обычные интерпретируемые языки сверх-высокого уровня.
а) будет дешевле
б) будет меньше ошибок в коде
Следовательно мы получим гораздо меньшую цену и более высокое качество.
Никто не спорит что приложение не должно виснуть. Я говорю про ощущение пользователя, когда он нажал на иконку, а сразу нифига не появилось.
Error: Search is presently down. Try again later.
Дак вот на этом Эльбрусе куте приложения имеют очень даже хороший отклик (причем не блокноты, а серьезные приложения работающие с сетью, с тяжелыми математическими алгоритмами, имеющие десятка два окон)
Понятное дело что речь не идет про крохотные программки, которые пишутся для однократного использования. Я говорю про обычные приложения, которые развиваются. Если все писать монолитно, то любой change request может обернуться крайним геморроем для программиста, если же использовать нормальное проектирование ПО, то любое изменение в приложение сильно облегчается.
Уж если сравнивать то высоко нагруженные приложения, а там процент на использование ГУЯ очень невелик по сравнению с остальными затратами ресурсов и то что отрисовка кутешного ГУЯ слегка медленнее чем какого-нибудь другого (кстати сравнивать надо тоже с кросс-платформенными либами) уже не имеет никакого значения. А С++ он везде С++.
По поводу использования QCoreApplication::processEvents(). Честно говоря никогда не использовал, потому что всегда выделяю ГУЕвый поток и доп поток для всего остального (или несколько потоков).