Кроссплатформенное приложение-сервис. На чем писать?

Question

[Сергей Савостин]

Подскажите пожалуйста как проще всего создать приложение-сервис (без GUI, разве что кнопка старт/стоп) для как можно большего количества платформ с минимальными затратами на допиливание под конкретную платформу?
Интересует Win, *nix, MacOS, iOS, Android.
Из функциональности будет сетевой доступ (клиент и сервер), многопоточность, SQLite. В качестве аналога — torrent-клиент с web-интерфейсом.

Язык желательно C++.
Может кто знает какой open source проект похожий чтоб подсмотреть как сделано.

Comments

[Сергей Савостин]

Да, забыл, поменьше бы, понативнее. Т.е. Qt не совсем то.

[Сергей Савостин]

На текущий момент вижу только MinGW на С++: pthreads, sockets, mongoose.
Но не уверен на счет iOS и Android.

Answer 1

[timka05]

Посоветую Java. Если знаете Си, то с синтаксисом Явы проблем не будет. Многопоточность, SQLite, все дела.
Для примера можно глянуть на торрент-клиент Vuze ( www.vuze.com/ ), исходники его открыты — можно изучать сколько угодно.

Сам сейчас пишу кроссплатформенное GUI приложение на JavaSE

Comments

[Сергей Савостин]

И как у нас Java на Win сможет сервисом работать? Что-то я такого не встречал…

[timka05]

На вскидку:
Делаем java приложение как windows-сервис
habrahabr.ru/sandbox/49165/

можно, все работает вполне отлично.

UPD.
mtaalamu.ru/blog/coding/1391.html
edn.embarcadero.com/article/32068

[Сергей Савостин]

Ого. У меня простенькая утилитка… Тогда уж Qt…

[Сергей Савостин]

Да еще и Windows Server 2008

[agmt]

Неужели на яве так уж проще писать, чем на Qt? И у Qt, кстати, скоро появится официальная поддержка Android, iOS (уже слито в основную ветку что есть).

Answer 2

[Александр Юдаев]

Какая-то непонятная формулировка задачи.
Если говорить о сервисах (службах) в Windows и демонах в Linux, то можно использовать либо QtService, либо mono-service на C#. Но что-то мне подсказывает, что эти решения не будут работать на iOS и Android (хотя ручаться не могу).
Вообще, службы винды — достаточно специфичная штука, и если вдруг вы потом захотите через нее как-то обращаться к GUI, то ничего не выйдет.

Можно взять какую-нибудь библиотеку (POCO, например) и написать на ней обычное приложение, которое будет работать в фоне.

Comments

[Сергей Савостин]

Вопрос собственно не в том, как сделать сервис или демон. Это скорее описание как быдет выглядеть приложение. Т.е. отсутствие GUI. Если это будет сервис в Win, то маленькое дополнительное приложение с иконкой в трее по управлению им — не проблема.
Вопрос больше программерский. Т.е. какие есть технологии/библиотеки, которые работают примерно одинаково на «всех» платформах.

[Александр Юдаев]

Для написания кроссплатформенного софта на C++ я предпочитаю использовать Qt. Геморроя нет или почти нет.
Mono зарекомендовала себя как отличная платформа для разработки кроссплатформенных приложений на C#.

Если приложение действительно очень маленькое, то почему бы не взять просто библиотеку boost, POCO или что-нибудь еще, где есть потоки, треды, работа с sql, и написать это руками? Все более-менее серьезные библиотеки могут компилироваться всеми популярными компиляторами и работать во всех популярных окружениях.

[Сергей Савостин]

Меня больше волнует граница между {Win,*nix, MacOS} и {iOS, Android}
Если в первой группе все более-менее понятно и, как мне кажется, скомпилируется из одних исходников, как я уже писал, тем же MinGW (pthreads, sockets, mongoose), то так ли легко те же исходники скомпилируются для второй группы? Скажем тот же boost…
Qt все же великоват :(

[Александр Юдаев]

boost как раз максимально кроссплатформенный, за него бы я волноваться не стал. Есть, например, вот такие проекты.

[Sergei Borisov]

Если таки С++ и что-то типа сервиса (хотя зачем сервису кнопка?) :) то присоединяюсь к совету про POCO. Хотя в моем опыте использования была какая-то эпическая проблема, поиск которой занял несколько дней. За давностью лет (это было 4 года назад) уже не вспомню что именно, но причина была в отличиях реализации STL и компилятора VisualC++ vs GCC. То есть, и там и там код компилировался корректно, но вел себя по разному. Поэтому использование одинаковой фреймворки для разных платформ не гарантирует идентичности работы кода. Тестировать все равно надо.