А я начал с Qt

Другие названия методов, неконсистентные с STL

Вернее, перешёл с Delphi

Непонятный qobject

Чувствуешь себя как в джаве

И с тех пор всё, отличное от Qt кажется ужасным

Чувствуешь себя как в джаве

Да ну

http://doc.qt.io/qt-5.6/signalsandslots.html

спасибо, посмотрю

Непонятный qobject

А, так вам не нравится Qt ввиду непонимания его архитектуры?

Терпеть не могу джаву

И с тех пор всё, отличное от Qt кажется ужасным

Импритинг. Лоренца почитай.

А, так вам не нравится Qt ввиду непонимания его архитектуры?

Вот вот

При чем здесь непонимание?

Я хорошо знаю плюсы.

Код которые пишется на кьюти это уже не плюсы практически.

Другая парадигма.

Я, если честно тоже не знаю, нашел пример, и заюзал, толком не разобравшись. Нужно было с манами получше ознакомитьс. В общем поспешишь - людей насмешишь.

а откуда пример?

Если бы я хотел сигналы слоты я бы писал на обджектив си

а откуда пример?

отсюда http://doc.qt.io/qt-5/qnetworkaccessmanager.html

Я хорошо знаю плюсы.

Это мы уже поняли ? Однако, речь о Qt. Не был бы он таким хорошим, не стал бы популярным, имхо.

Речь не об этом. Кьюти хорош для гуёв. Наверное. Но для всего остального он не нужен.

Я не понимаю зачем его пользовать для сети.

Для стэндалоун приложений, где гуй не нужен, к примеру

И так далее.

У кьюти была своя замечательная узкая область.

Речь не об этом. Кьюти хорош для гуёв. Наверное. Но для всего остального он не нужен.

А, если в этом смысле, абсолютно согласен. Нужно было объяснить ? Для каждой задачи свой инструментарий.

Писать сеть на кьюти и привыкать к этому — очень плохая практика.

Писать сеть на кьюти и привыкать к этому — очень плохая практика.

и на чем ее писать на asio?

Он для гуев, да, но не подключать же доп. библиотеки для сети, если qt умеет с ней работать

У меня свой взгляд на чем её писать, но вообще говоря да, при выборе между кьюти и асио, асио предпочтительнее

Он для гуев, да, но не подключать же доп. библиотеки для сети, если qt умеет с ней работать

Сейчас объясню. Я всегда вижу проблему такую: чем более универсальный инструмент, тем более он во-первых негибкий, во-вторых менее производительный.

Нужно же оценивать объективно, нужна ли скорость разработки (стоит ли тратиться на изучение новых библиотек), производительность работы ПО и т.д.

Использование кьюти заставляет меня писать всё в стиле кьюти. В то время как сеть я предпочел бы писать в одном стиле. Гуи в другом, бизнес-логику в третьем

В этом проявляется негибкость.

А потеря производительности проявляется в том, что более общее решение всегда содержит лишние случаи, которые тебе не нужны в работе

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

Это c++-way

Я вообще негативно отношусь к сторонним зависимостям. Даже к бусту. Но я подхожу разумно.

Понятно что мультииндекс я велосипедить не буду

С другой стороны фанбои библиотек тащат их в проект увеличивая время сборки, размер и проьоемы с лицензиями

Когда этого можно и не делать.

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

Когда у меня была возможность самому с нуля задизайнить всё что надо.

Начиная с 11-х плюсов меня устраивает stl целиком и полностью. Сейчас я могу написать практически любой сложности проект с минимальными зависимостями.

Кстати, в том чтоткасается гуи, я предпочитаю html-based дизайн. Потому что программисты верстать не умеют.

Зато умеют дизайнеры и html им как родной.

И этот тренд мне нравится. Как гуи в скайпе, как гуи в антивирусах и так далее.

Насчет перегруженности полностью согласен. Qt действительно тянет и-то что нужно и чего не надо. А как насчет кросплатформенности? Вот я искал библиотеки для написания гуя, из популярных нашел лишь qt и wxwidgets. Остальное либо под одну платформу, либо ноунейм.

Господа, чтоб в php запользовать функцию mail() на сервере нужен какой-нить mta, или интерпретатор сам сможет отправить почту?? Питон сам может, а в похапе как? У меня просто чувак спросил, а я хз что ответить

Интерпретатор php тырит настройки из php.ini, берет модуль почты, и шлет по смтп/или другому протоколу

Насчет перегруженности полностью согласен. Qt действительно тянет и-то что нужно и чего не надо. А как насчет кросплатформенности? Вот я искал библиотеки для написания гуя, из популярных нашел лишь qt и wxwidgets. Остальное либо под одну платформу, либо ноунейм.

Поэтому я выше страшивал про отпиливание лишнего кода из Qt с сохранением лицензии.

Насчет перегруженности полностью согласен. Qt действительно тянет и-то что нужно и чего не надо. А как насчет кросплатформенности? Вот я искал библиотеки для написания гуя, из популярных нашел лишь qt и wxwidgets. Остальное либо под одну платформу, либо ноунейм.

Есть кроссплатформенные html движки. Htmlayout, sciter, awesomium

Они позволяют тебе оформлять гуй в виде html-я и связывать DOM с плюсовым кодом.

Есть возможность вообще делать веб-консоль.

Для этого нужно только lightweight http сервер разврнуть.

На этом подходе есть Wt бибилиотека

Но она большая.

Я обычно сам делаю. Хттп сервер поднять с обработчиком джсона на плюсах для меня дело часа.

Вот это интересно. C html работать намного удобнее. Я правильно понимаю, для дизайна ведь можно будет использовать css?

Да

И даже js.

Вполне отличный подход. Я тоже склоняюсь к тому, чтобы интерфейс был на HTML. Получить хороший результат проще и быстрее, чем на какой-нибудь библиотеке вроде Qt. Может с QtQuick это и быстро, но все же.

Htmlayout збс вещь

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

На Dr. Web пока работал имел дело там и с HTMLayout, на нем там пользовательский гуй сделан в стендэлоуне. И с Wt, на нем сделан энтрепрайз сьют, а я писал на нём внутреннюю контрольную панель для облачного сервиса.

А на кросплатформенные приложения на иос/андроид qtquick не годится?

Сейчас все поклонники Qt пойдут в HTML ?

Сейчас все поклонники Qt пойдут в HTML ?

чет нет

ERROR: S client not available

не тянет

Ну это пока.

за 5 лет хтмл+жс настолько задолбал, что ну его нах

Просто я видел воркфлоу исправления багов в гуи в компании с кьюти, и его же в компании с хтмлем

В кьюти баг на гуи заводится на дизайнера юай, он его перезаводит на программиста объясняя что надо сделать, а вечнозанятыф программист потом что-то правит, иногда неправильно.

В случае html баг заведенный на дизайнера им же самим тут же правится в html-е и без пересборки попадает в новый билд ресурсов.

для этого всеж qml и завезли

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

дизайнер != верстальщик

Согласен. Верстальщика.

к тому что всё же некоторое разделение обязанностей есть, но тут всё конечно от конторы зависит

Ну да. Обычно "дизайнер ui" и верстальщик это одно и то же лицо.

я с Qt не работал ниразу, там так же как под андроидом интерфейс в xml ?

понятно, лучше погуглю:)

я с Qt не работал ниразу, там так же как под андроидом интерфейс в xml ?

если брать классический подход, и через дизайнер, то в xml сохранит, потом генерит С++ код

спасибо

То есть пересборка требуется.

Qtшники! Прошу подскажите На кросплатформенные приложения на иос/андроид qtquick не годится?

Qtшники! Прошу подскажите На кросплатформенные приложения на иос/андроид qtquick не годится?

Он ни на что пока не годится. Багов много

По поводу сети на Qt

Удобно

Кроссплатформенно и не надо лишние библиотеки тащить

А кьюти это не бибилиотеку тащить?

И да, я уже сказал про импритинг.

Её всё равно же тащить

Для gui

Как выясняется не обязательно.

А библиотек сетевых куча разных

И удобство это очень субъективный критерий.

Я и асио видел и zeromq

И черта в ступе.

А библиотек сетевых куча разных

То есть тащить и Qt и сетевую?