Portable Components, кроссплатформенная библиотека для C++

[RNZ]

Пару дней назад ковырял эту либу — понравилась. А тут статейка — спасибо! ))

[Riateche]

Есть ли у этой библиотеки какие-нибудь плюсы по сравнению с Qt? Я вижу, у них довольно сильно пересекается функциональность.

[Monnoroch]

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

[mt_]

Тогда, стОит рассмотреть ещё U++. Он отвечает всем указанным критериям при, скажем так, более компактном коде.

[Gorthauer87]

Ни разу не встречал её в дикой природе, да и гуй там совсем уж формошлепный на выходе.

[mt_]

U++ — библиотека на любителя, но крайне гибкая и мощная, если научиться пользоваться.
В остальном — просто не хочу оффтопить. И гуй, и поддержка всего от быстрых контейнеров до SSL, там не просто есть, а очень сильно есть. )

[gridem]

Использую U++ в своих проектах. Могу сказать, что на первый взгляд U++ выглядит достаточно простовато, однако, когда начинаешь копать детали, то понимаешь, что библиотека очень мощная и необычная. Чего стоит pick семантика, которая необходима для получения более быстрого кода, встроенный lock-free аллокатор с возможностью отлова утечек памяти. И все это уже встроено в библиотеку!

[mt_]

Сюда же сверхбыстрые строки и контейнеры, нативная поддержка json, xml и прочего.
А так же, моя библиотека сверхбезопасной многопоточности на sequential processes.
Извините, не удержался.)

[mordet]

Как я был бы рад обзорной статье об U++…

[mt_]

В фреймворк заложено такое количество интересных идей, что одной статьёй вряд ли можно будет просто их адекватно перечислить.
Только что написал статью, посвящённую идеологии управления ресурсов в U++. За счёт неё удаётся побеждать всю или почти всю головную боль с утечками памяти.

[Paul]

LGPL тоже позволяет коммерческое использование, если что.

[PavloG]

К сожалению для разработки под iOS использовать LGPL нельзя — так как apple не дает возможности делать динамические библиотеки

[kekekeks]

Эм. Они именно запретили их использовать подгрузку исполняемого кода из других файлов в том же бандле, или же просто нет технической возможности? Если второе, то почему до сих пор не написан лоадер?

[NickLion]

Ради справедливости, LGPL можно линковать статически при условии распространения объектных файлов. Но да, по факту в данном случае LPGL почти невозможно использовать.

[nephrael]

Я думаю их не корректно сравнивать, ввиду того, что Qt является тяжёлой универсальной библиотекой ориентированной на создание клиентских приложений с GUI, в то время как POCO является легковесной и ориентирована на сетевое программирование.
Однако если сравнивать QtCore и POCO Foundation (ядра Qt и POCO), то тут несомненно первый плюс — шаблонная магия POCO вместо moc у QT, остальное — дело вкуса. Я считаю, что и на Qt можно создать профессиональный продукт, и на POCO, просто такие вещи как создание высоконагруженных и высоконадежных процессинг серверов я бы доверил именно POCO.

[Gorthauer87]

Сигналы слоты в новом Qt5 тоже на шаблонах делаются, хотя старый синтаксис оставлен. В результате слотом может быть обьявлена любая вообще функция, вне зависимости от того, есть moc или нет его.
Вот для сигналов по прежнему moc нужен, как нужен он для интроспекции нормальной и для биндингов к другим ЯП.

[f0b0s]

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

[ruzzz]

Есть одна особенность этой библиотеки: весь unicode представлен с помощью std::string, внутри которых лежат строки utf-8. Используя внутри юникодный winapi, poco автоматом делает преобразование. Для классов которые работают с именами файлов — poco не принимает std::wstring или wchar_t*. В помощь есть класс UnicodeConverter.

[Nomad1]

Скажите, неймспес std и классы string, vector, istream тут именно от PoCo? Или используется хитрая мешанина с STL? Выглядят они откровенно чужеродными, да и смысла нет использовать сразу две кросс-платформенные библиотеки и/или два синтаксиса.

Ощущения от статьи: интересно, надо будет попробовать. Не раскрыта работа с коллекциями, XML, смутило разное форматирование параметров в format, Statement, PatternFormatter, но это не беда. Также появилось легкое предчуствие, что портирование таого зверя на новые ОС далеко не тривиально и если надо запустить код на каких-нибудь QNX/BeOS/iOS, то придется слать письма счастья разработчикам и ждать долгими зимними вечерами.

[nephrael]

По поводу пространств имен: строки, вектора и потоки — все тут STL. POCO сама по себе построена на STL и не дублирует её функционал, поэтому особых накладных расходов на использование 2ух библиотек одновременно нет.

По поводу некоторой незаконченности статьи — так и задумано, тема привлекла внимание к себе и все пропуски в этой статье будут, конечно же, заполнены.В данный момент я уже пишу статью по Application'ов, после этого будет и все остальное.

Насчет переносимости — это вечная проблема, насколько мне известно, сейчас только тандем Win/Lin/Mac ведет себя одинаково процентов на 90%.

[NickLion]

только тандем Win/Lin/Mac ведет себя одинаково процентов на 90%
Так мало? Или статистика отфанарная?

[nephrael]

Статистика из личного опыта. На FreeBSD жалуются, что не заводится. На QNX пробовал собрать, не получилось, бросил и особо не вникал в проблему.
А у этого тандема периодически случаются косяки и скорей всего я занизил число опираясь на багтрекер. Так что статистика скорее не отфанарная, а субъективная.

[NickLion]

Т.е. получается, что кроссплатформенность существенно хромает. Не радует :( А как дела обстоят с различными компиляторами не подскажете?

[nephrael]

В основном — порты GCC на разные платформы и Вендовый MSVC. Но я не думаю, что нельзя использовать другие. Как никак писалось с соблюдением стандартов и по сути нужны только C++03 совместимый компилятор, STL, а также для потоков и сокетов либо POSIX API, либо WinAPI.

[prograholic]

Я бы поправил пример с мьютексами, потому-что в приведенном примере мьютексы не выполняют свою роль — они ничего не защищают.

[nephrael]

Спасибо за замечание, поправил код.

[Gorthauer87]

Очень аккуратно выглядит, хотя почти всё это есть в Qt, поэтому думаю в сочетании с Qt это все будет излишеством, но как легковесная замена Бусту думаю сгодится.

[brainplus]

блин, что ж они не используют правила именования как в STL и Boost (там все маленькими буквами)?

Ну и имхо у немцев ОГРОМНЫЕ проблемы с архитектурами софта. Глядя на кривость API KDE (проектировали немецкие студенты), убогость и кривизну OpenOffice — есть ощущение что это у них в крови, и что POCO — такая же по-немецки кривая.

[PavloG]

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

[nephrael]

У них это корпоративный стиль.

[himem]

Недавно начал использовать POCO в рабочем проекте в качестве легковесной альтернативы Qt и собственным велосипедам. Пока всем доволен, но целостного мнения ещё не сложилось.

Буду рад, если публикации по библиотекам будут время от времени появляться на Хабре :)

[nephrael]

Если на Windows, то компилируем POCO утилитой buildwin.cmd (к примеру так buildwin 100 build shared debug x64 nosamples), заранее нужна скомпилированая библиотека OpenSSL. Далее создаем проект. В файл проекта вписываем пути к include директориями POCO и OpenSSL в переменную INCLUDEPATH, подключить либы через переменную LIBS, и соответственно при запуске в PATH должны находится пути к местам, где лежат либы POCO и OpenSSL
Подробней по переменным на доках Qt

[ruzzz]

Может это POCO_STATIC?

[nephrael]

Я собрал так:

POCO_PATH =     c:/mingw/poco
OSSL_PATH =     c:/openssl/
INCLUDEPATH +=  $$POCO_PATH/include $$OSSL_PATH/include
LIBS +=         -L$$POCO_PATH/lib64/ -L$$OSSL_PATH/lib/ \
                -lPocoCryptod -lPocoFoundationd -lPocoUtild \
                -llibeay32mdd -lssleay32mdd -lws2_32 -liphlpapi

[nephrael]

Кстати собираю инклуды в коневой папке я вот так: «cp -r */include .» (cp из msys)

Либо можно заменить инклуд так

INCLUDEPATH +=  $$POCO_PATH/CppUnit/include/	\
        $$POCO_PATH/Crypto/include/	\
        $$POCO_PATH/Data/include/	\
        $$POCO_PATH/Foundation/include/	\
        $$POCO_PATH/Net/include/	\
        $$POCO_PATH/Util/include/	\
        $$POCO_PATH/XML/include/	\
        $$POCO_PATH/Zip/include/