Комментарии 40
Пару дней назад ковырял эту либу — понравилась. А тут статейка — спасибо! ))
Есть ли у этой библиотеки какие-нибудь плюсы по сравнению с Qt? Я вижу, у них довольно сильно пересекается функциональность.
Лиценция, позволяющая коммерческое использование, отсутствие необходимости в MOC, и, может быть, некоторая легковесность, хотя это спорный вопрос.
Тогда, стОит рассмотреть ещё U++. Он отвечает всем указанным критериям при, скажем так, более компактном коде.
Ни разу не встречал её в дикой природе, да и гуй там совсем уж формошлепный на выходе.
U++ — библиотека на любителя, но крайне гибкая и мощная, если научиться пользоваться.
В остальном — просто не хочу оффтопить. И гуй, и поддержка всего от быстрых контейнеров до SSL, там не просто есть, а очень сильно есть. )
В остальном — просто не хочу оффтопить. И гуй, и поддержка всего от быстрых контейнеров до SSL, там не просто есть, а очень сильно есть. )
Использую U++ в своих проектах. Могу сказать, что на первый взгляд U++ выглядит достаточно простовато, однако, когда начинаешь копать детали, то понимаешь, что библиотека очень мощная и необычная. Чего стоит pick семантика, которая необходима для получения более быстрого кода, встроенный lock-free аллокатор с возможностью отлова утечек памяти. И все это уже встроено в библиотеку!
Сюда же сверхбыстрые строки и контейнеры, нативная поддержка json, xml и прочего.
А так же, моя библиотека сверхбезопасной многопоточности на sequential processes.
Извините, не удержался.)
А так же, моя библиотека сверхбезопасной многопоточности на sequential processes.
Извините, не удержался.)
Как я был бы рад обзорной статье об U++…
В фреймворк заложено такое количество интересных идей, что одной статьёй вряд ли можно будет просто их адекватно перечислить.
Только что написал статью, посвящённую идеологии управления ресурсов в U++. За счёт неё удаётся побеждать всю или почти всю головную боль с утечками памяти.
Только что написал статью, посвящённую идеологии управления ресурсов в U++. За счёт неё удаётся побеждать всю или почти всю головную боль с утечками памяти.
LGPL тоже позволяет коммерческое использование, если что.
К сожалению для разработки под iOS использовать LGPL нельзя — так как apple не дает возможности делать динамические библиотеки
Эм. Они именно запретили их использовать подгрузку исполняемого кода из других файлов в том же бандле, или же просто нет технической возможности? Если второе, то почему до сих пор не написан лоадер?
Ради справедливости, LGPL можно линковать статически при условии распространения объектных файлов. Но да, по факту в данном случае LPGL почти невозможно использовать.
Я думаю их не корректно сравнивать, ввиду того, что Qt является тяжёлой универсальной библиотекой ориентированной на создание клиентских приложений с GUI, в то время как POCO является легковесной и ориентирована на сетевое программирование.
Однако если сравнивать QtCore и POCO Foundation (ядра Qt и POCO), то тут несомненно первый плюс — шаблонная магия POCO вместо moc у QT, остальное — дело вкуса. Я считаю, что и на Qt можно создать профессиональный продукт, и на POCO, просто такие вещи как создание высоконагруженных и высоконадежных процессинг серверов я бы доверил именно POCO.
Однако если сравнивать QtCore и POCO Foundation (ядра Qt и POCO), то тут несомненно первый плюс — шаблонная магия POCO вместо moc у QT, остальное — дело вкуса. Я считаю, что и на Qt можно создать профессиональный продукт, и на POCO, просто такие вещи как создание высоконагруженных и высоконадежных процессинг серверов я бы доверил именно POCO.
Сигналы слоты в новом Qt5 тоже на шаблонах делаются, хотя старый синтаксис оставлен. В результате слотом может быть обьявлена любая вообще функция, вне зависимости от того, есть moc или нет его.
Вот для сигналов по прежнему moc нужен, как нужен он для интроспекции нормальной и для биндингов к другим ЯП.
Вот для сигналов по прежнему moc нужен, как нужен он для интроспекции нормальной и для биндингов к другим ЯП.
Все руки не доходили посмотреть.
Многое, конечно, уже есть в новом стандарте (генераторы случайных чисел, многопоточность причем с барьерами, кортежи, регулярки), но вот работа с динамическими библиотеками и процессами, сжатие через потоки, кодирование текста (хотя тут все равно без ICU с ее таблицами на 14 мб не обойтись) и всякие сетевые штуки — это сладко-сладко, да.
Многое, конечно, уже есть в новом стандарте (генераторы случайных чисел, многопоточность причем с барьерами, кортежи, регулярки), но вот работа с динамическими библиотеками и процессами, сжатие через потоки, кодирование текста (хотя тут все равно без ICU с ее таблицами на 14 мб не обойтись) и всякие сетевые штуки — это сладко-сладко, да.
Есть одна особенность этой библиотеки: весь unicode представлен с помощью std::string, внутри которых лежат строки utf-8. Используя внутри юникодный winapi, poco автоматом делает преобразование. Для классов которые работают с именами файлов — poco не принимает std::wstring или wchar_t*. В помощь есть класс UnicodeConverter.
Скажите, неймспес std и классы string, vector, istream тут именно от PoCo? Или используется хитрая мешанина с STL? Выглядят они откровенно чужеродными, да и смысла нет использовать сразу две кросс-платформенные библиотеки и/или два синтаксиса.
Ощущения от статьи: интересно, надо будет попробовать. Не раскрыта работа с коллекциями, XML, смутило разное форматирование параметров в format, Statement, PatternFormatter, но это не беда. Также появилось легкое предчуствие, что портирование таого зверя на новые ОС далеко не тривиально и если надо запустить код на каких-нибудь QNX/BeOS/iOS, то придется слать письма счастья разработчикам и ждать долгими зимними вечерами.
Ощущения от статьи: интересно, надо будет попробовать. Не раскрыта работа с коллекциями, XML, смутило разное форматирование параметров в format, Statement, PatternFormatter, но это не беда. Также появилось легкое предчуствие, что портирование таого зверя на новые ОС далеко не тривиально и если надо запустить код на каких-нибудь QNX/BeOS/iOS, то придется слать письма счастья разработчикам и ждать долгими зимними вечерами.
По поводу пространств имен: строки, вектора и потоки — все тут STL. POCO сама по себе построена на STL и не дублирует её функционал, поэтому особых накладных расходов на использование 2ух библиотек одновременно нет.
По поводу некоторой незаконченности статьи — так и задумано, тема привлекла внимание к себе и все пропуски в этой статье будут, конечно же, заполнены.В данный момент я уже пишу статью по Application'ов, после этого будет и все остальное.
Насчет переносимости — это вечная проблема, насколько мне известно, сейчас только тандем Win/Lin/Mac ведет себя одинаково процентов на 90%.
По поводу некоторой незаконченности статьи — так и задумано, тема привлекла внимание к себе и все пропуски в этой статье будут, конечно же, заполнены.В данный момент я уже пишу статью по Application'ов, после этого будет и все остальное.
Насчет переносимости — это вечная проблема, насколько мне известно, сейчас только тандем Win/Lin/Mac ведет себя одинаково процентов на 90%.
только тандем Win/Lin/Mac ведет себя одинаково процентов на 90%
Так мало? Или статистика отфанарная?
Так мало? Или статистика отфанарная?
Статистика из личного опыта. На FreeBSD жалуются, что не заводится. На QNX пробовал собрать, не получилось, бросил и особо не вникал в проблему.
А у этого тандема периодически случаются косяки и скорей всего я занизил число опираясь на багтрекер. Так что статистика скорее не отфанарная, а субъективная.
А у этого тандема периодически случаются косяки и скорей всего я занизил число опираясь на багтрекер. Так что статистика скорее не отфанарная, а субъективная.
Я бы поправил пример с мьютексами, потому-что в приведенном примере мьютексы не выполняют свою роль — они ничего не защищают.
Очень аккуратно выглядит, хотя почти всё это есть в Qt, поэтому думаю в сочетании с Qt это все будет излишеством, но как легковесная замена Бусту думаю сгодится.
блин, что ж они не используют правила именования как в STL и Boost (там все маленькими буквами)?
Ну и имхо у немцев ОГРОМНЫЕ проблемы с архитектурами софта. Глядя на кривость API KDE (проектировали немецкие студенты), убогость и кривизну OpenOffice — есть ощущение что это у них в крови, и что POCO — такая же по-немецки кривая.
Ну и имхо у немцев ОГРОМНЫЕ проблемы с архитектурами софта. Глядя на кривость API KDE (проектировали немецкие студенты), убогость и кривизну OpenOffice — есть ощущение что это у них в крови, и что POCO — такая же по-немецки кривая.
У них это корпоративный стиль.
Недавно начал использовать POCO в рабочем проекте в качестве легковесной альтернативы Qt и собственным велосипедам. Пока всем доволен, но целостного мнения ещё не сложилось.
Буду рад, если публикации по библиотекам будут время от времени появляться на Хабре :)
Буду рад, если публикации по библиотекам будут время от времени появляться на Хабре :)
НЛО прилетело и опубликовало эту надпись здесь
Если на Windows, то компилируем POCO утилитой buildwin.cmd (к примеру так buildwin 100 build shared debug x64 nosamples), заранее нужна скомпилированая библиотека OpenSSL. Далее создаем проект. В файл проекта вписываем пути к include директориями POCO и OpenSSL в переменную INCLUDEPATH, подключить либы через переменную LIBS, и соответственно при запуске в PATH должны находится пути к местам, где лежат либы POCO и OpenSSL
Подробней по переменным на доках Qt
Подробней по переменным на доках Qt
НЛО прилетело и опубликовало эту надпись здесь
Может это POCO_STATIC?
Я собрал так:
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
Кстати собираю инклуды в коневой папке я вот так: «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/
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Portable Components, кроссплатформенная библиотека для C++