Но зачем вообще здесь кресты?

серверное приложение с использованием графического фреймворка

А кто сказал, что Qt — это исключительно графический фреймворк? Нравится — делай, ничего такого сверхстрашного в этом нет.

Уже есть прецеденты.

man quasselcore

кто-то на лоре даже приводил историю успеха по этому поводу

Да я и простенький http-сервер видел, можно загуглить

Во всех нормальных дистрах qt уже давно поделён на отдельные компоненты и вполне можно поставить core и прочие нужные пакеты без gui и прочих не нужных, что тебе, собственно, и требуется.

Qt
графического фреймворка

/0

Кроме очевидного, какие недостатки будут у такой программы?

Какие недостатки вам очевидны?! ЗЫ если руки не из зада, проблем не вижу.

Во всех нормальных дистрах qt уже давно поделён на отдельные компоненты и вполне можно поставить core и прочие нужные пакеты без gui и прочих не нужных, что тебе, собственно, и требуется.

Скажу больше, у меня даже работает. На серве где графического вообще ничего нету. USE="-X" глобально.

серверное приложение с использованием графического фреймворка, ага

new project -> console app //как то так

Кроме очевидного

Какого очевидного

какие недостатки будут у такой программы?

Возможно только немного большый размер (при статической компиляции), так как в сокеты будут включены ф-ции, которые ты не будешь использовать (в этом не уверен). Как вариант, скопировать класс и оставить только те, что тебе нужно.

Я просто скастую это здесь...

Mystra_x64

Возможно только немного большый размер (при статической компиляции), так как в сокеты будут включены ф-ции, которые ты не будешь использовать (в этом не уверен). Как вариант, скопировать класс и оставить только те, что тебе нужно.

Погоды не сделает. Может только если запустить over9000 приложений на оперативе даст ощутимый эффект.... А дисковое пространство так эпично экономить точно ни к чему )))

Пишу небольшую клиент-серверную игрушку j4f на кутях. Всем доволен, но для реального проекта лучше использовать более «серверные» языки, тот-же эрланг, например.

Чем лучше-то?

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

+ в бороду!

Чем лучше-то?

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

но лучше прелинк и динамическая линковка.

и теперь: а на эрланге есть удобные сокеты?

так и делаю )))

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

Если тебе знакомы кресты, а эрланг нет? Думаю по времени будет всё с точность до наоборот...

и теперь: а на эрланге есть удобные сокеты?

С сокетами в эрланге только поверхностно работал, но кутишным явно не уступают. Единственный плюс qt в этом плане - свой протокол, который не надо заного изобретать.

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

Qt сейчас намного больше, чем графический фреймворк. Написанный на Qt сервер будет обладать огромным перимуществом - кроссплатформенность.

А грамотно написанное приложение работает ооочень шустро.

Вспомнил: есть ограничения по использованию QObject-based классов и в многопоточном приложении: методы объекта обязаны вызываться в том же потоке, где был создан объект.

Кроме очевидного, какие недостатки будут у такой программы?

Торвальдс, увидев твою программу, потеряет еще пять волосин и три других поседеет.

если скорость некритична
распарелливанием

ВИП же?

В Qt удобные сокеты. Мне лично понравились

В Qt очень медленные сокеты.

не осилил BSD сокеты напрямую юзать? Фуу как не стыдно :)

ВИП же?

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

есть ограничения по использованию QObject-based классов

какие?

методы объекта обязаны вызываться в том же потоке, где был создан объект.

и кто такие обязательства выписал?

В Qt удобные сокеты

а ещё сигналы

какие недостатки будут у такой программы

те, которые запилишь лично ты :)

PS от Qt ещё никто не умирал

а на эрланге есть удобные сокеты?

на эрланге вся сетевая часть на порядки удобнее

и кто такие обязательства выписал?

да вот выписали:

As mentioned above, developers must always be careful when calling objects' methods from other threads. Thread affinity does not change this situation. Qt documentation marks several methods as thread-safe. postEvent() is a noteworthy example.

A thread-safe method may be called from different threads simultaneously. In cases where there is usually no concurrent access to methods, calling non-thread-safe methods of objects in other threads may work thousands of times before a concurrent access occurs, causing unexpected behavior.

отсюда: http://doc.qt.nokia.com/4.7-snapshot/thread-basics.html#qobject-and-threads

Для хороших сокетов есть 100500 других либ. Используй POCO - там есть сокеты и куча другой функциональности, которая может быть нужна, если ты делаешь сетевое приложение.

Давай перейдем к общему. «Сервер на C++!?!»

Как минимум, если сокет (QTcpSocket) создан в одном потоке, а poll происходит в другом, не срабатывает оповещение о приходе данных. И это ограничения архитектуры Qt4. Собстаенно и нефиг путать данные потоков так-то.

Тащить Qt только ради сокетов - некрасивая, плохая идея.

Не на C++, а на C++ + Qt.

Кроссплатформенность же.

Так-то да, библиотека разбита на довольно крупные модули. Также при использовании QtNetwork обязательно потянется QtCore (куда ж без него).

Вот если использовать всю мощь тулкита, то оно того стоит наверное. Но зависит от задачи.

QtCore весит 3 Мб. Если оно будет линковаться динамически, все норм. Если статически - может быть многовато.

Кроссплатформенность же. Нет смысла катать еще одну обертку, умеющую на одной платформе юзать сокеты BSD, а на другой - WINSOCK.

Может, использовать Vala? Нормальный современный язык без крестопроблем, из зависимостей - только glib.

А может, использовать нормальные кресты с glibmm?

Нет смысла катать еще одну обертку, умеющую на одной платформе юзать сокеты BSD, а на другой - WINSOCK.

там обёртка на полкопейки

Обертка для сокетов, обертка для взаимодействия с базой, обертка обертка, обертка.

ПРоще использовать хороший готовый тулкит для таких вещей. Если не надо специальные хитрые оптимизации использовать.

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

Я понимаю, что идея плоха в корне

Чем плоха? Нормальная идея. Qt - отличный фреймворк и он не только гуёвый. Другое дело - что если нужен Ъ-хайлоад - то будут проблемы, тут лучше на чистом С.

«Чуть что, так сразу косой» ©

>В Qt удобные сокеты. Мне лично понравились.
Если будешь пользоваться, возможно ещё передумаешь :} Лично я не в курсе деталей, но в симуляторе покемон онлайна заменили его чем-то другим (SFML?). А там всего-то с тысячу пользователей онлайн на сервер.

Читать научись... Сабж есть рекомендация (ВНИМАНИЕ не требование и не обязывание) использовать не потокобезопасные методы только из того треда к которому относится объект. КО одсказывает, что это и так очевидность. Ну а во втором обзаце КО петросянит на тему того, что потокобезопасные методы можно юзать как в бошку взбредёт. Слова обязан/обязательно/етц я не вижу.

Как минимум, если сокет (QTcpSocket) создан в одном потоке, а poll происходит в другом, не срабатывает оповещение о приходе данных. И это ограничения архитектуры Qt4. Собстаенно и нефиг путать данные потоков так-то.

И где тут «ограничения по использованию QObject-based классов» или «методы объекта обязаны вызываться в том же потоке, где был создан объект»?!