ACE vs Boost vs POCO [закрыто]

96

Я довольно давно работаю с библиотеками Boost C ++ . Мне очень нравится библиотека Boost Asio C ++ для сетевого программирования. Однако я познакомился с двумя другими библиотеками: POCO и инфраструктурой адаптивной коммуникационной среды (ACE) . Я хотел бы знать хорошее и плохое в каждом из них.

рахул
источник
3
ACE - это «лучший швейцарский армейский нож сетевого программирования» для программирования на C ++, но в последний раз я проверил, что это тоже огромная зависимость от монстров.
нет

Ответы:

90

Как сказано в rdbound, Boost имеет статус "около STL". Так что, если вам не нужна другая библиотека, придерживайтесь Boost. Однако я использую POCO, потому что это дает некоторые преимущества для моей ситуации. Плюсы POCO IMO:

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

  • Более полная сетевая библиотека, чем boost::asio. тем не мениеboost::asio это также очень хорошая библиотека.

  • Включает в себя функции, которых нет в Boost, такие как XML и интерфейс базы данных, чтобы назвать несколько.

  • Он более интегрирован как одна библиотека, чем Boost.

  • Имеет чистый, современный и понятный код C ++. Мне это намного легче понять, чем большинство библиотек Boost (но я не эксперт по программированию шаблонов :)).

  • Его можно использовать на многих платформах.

Некоторые недостатки POCO:

  • Документация ограничена. Это несколько компенсируется тем, что исходный текст легко понять.

  • У него гораздо меньше сообщества и пользователей, чем, скажем, у Boost. Так что если вы зададите вопрос, например, о переполнении стека, ваши шансы получить ответ будут меньше, чем для Boost.

  • Еще неизвестно, насколько хорошо он будет интегрирован с новым стандартом C ++. Вы точно знаете, что для Boost это не проблема.

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

Некоторые ответы на комментарии Рахула:

  1. Не знаю, как универсальный и продвинутый. Библиотека потоков POCO предоставляет некоторые функции, которых нет в Boost: ActiveMethodи Activity, и ThreadPool. Потоки IMO POCO также проще использовать и понимать, но это субъективный вопрос.

  2. Сетевая библиотека POCO также обеспечивает поддержку протоколов более высокого уровня, таких как HTTP и SSL (возможно, тоже boost::asio, но я не уверен?).

  3. Справедливо.

  4. Интегрированная библиотека имеет то преимущество, что она имеет единообразное кодирование, документацию и общий "внешний вид".

  5. Кроссплатформенность - важная особенность POCO, но не преимущество по сравнению с Boost.

Опять же, вам, вероятно, следует рассматривать POCO только в том случае, если он предоставляет некоторые необходимые вам функции, а этого нет в Boost.

Дани ван дер Меер
источник
1
Из того немногого, что я узнал о POCO, все не складывается: 1. Поток ускорения кажется гораздо более универсальным и продвинутым. 2. В чем POCO более универсален? 3. Меня интересует только нетворкинг. XML и база данных меня не интересуют. 4. Объединены как одна библиотека? Я не уверен, хорошо это или плохо? 5. Я считаю, что Boost (и это касается и boost :: asio) также является кроссплатформенным.
rahul
@Rahul Я попытался ответить на некоторые ваши вопросы в ответе.
Дани ван дер Меер,
В последнее время я не смотрел на POCO, но когда я смотрел на него несколько лет назад, меня оттолкнул тот факт, что компоненты, похоже, используют смесь лицензий. Некоторые использовали лицензию Boost, другие - GPL. Для коммерческого использования некоторых средств шифрования требовалась лицензия. Я не знаю, какова текущая ситуация с лицензированием POCO, но я бы внимательно посмотрел на это, прежде чем использовать его.
Ferruccio
10
POCO полностью находится под лицензией Boost (для использования в будущем).
Брендан Лонг
1
Одним из преимуществ Poco является более быстрое время компиляции. Поскольку Boost обычно зависит от большого количества кода в заголовках, время компиляции может быть медленным. В poco есть более динамическое связывание, которое сокращает время компиляции. Существует также преимущество безопасности, так как пользователь может обновлять .so / .dll без необходимости перекомпилировать все.
ericcurtin
27

Я использовал все три, так что вот мои 0,02 доллара.

Я действительно хочу проголосовать за Дуга Шмидта и уважать всю проделанную им работу, но, честно говоря, я нахожу ACE слегка глючной и сложной в использовании. Думаю, этой библиотеке нужна перезагрузка. Трудно сказать это, но я бы пока уклонился от ACE, если нет веских причин для использования TAO или вам не нужна единая база кода для запуска C ++ как в вариантах Unix, так и в Windows. TAO отлично подходит для решения ряда сложных проблем, но процесс обучения требует значительных усилий, и есть причина, по которой CORBA вызывает ряд критиков. Я думаю, просто сделайте свою домашнюю работу, прежде чем принимать решение о том, что использовать.

Если вы пишете код на C ++, мне кажется, что Boost - это не проблема. Я использую ряд низкоуровневых библиотек и считаю их необходимыми. Быстрый grep моего кода показывает shared_ptr, program_options, regex, bind, serialization, foreach, property_tree, filesystem, tokenizer, различные расширения итератора, alogrithm и mem_fn. В основном это низкоуровневые функции, которые действительно должны быть в компиляторе. Некоторые библиотеки ускорения носят очень общий характер; заставить их делать то, что вы хотите, может быть трудом, но это того стоит.

Poco - это набор служебных классов, которые обеспечивают функциональность для некоторых очень конкретных общих задач. Я считаю, что библиотеки хорошо написаны и интуитивно понятны. Мне не нужно тратить много времени на изучение документации или написание глупых тестовых программ. В настоящее время я использую Logger, XML, Zip и Net / SMTP. Я начал использовать Poco, когда libxml2 меня в последний раз раздражала. Есть и другие классы, которые я мог бы использовать, но не пробовал, например Data :: MySQL (мне нравится mysql ++) и Net :: HTTP (мне нравится libCURL). В конце концов, я попробую остальную часть Poco, но на данный момент это не является приоритетом.


источник
Хорошее описание, спасибо.
Амир Нагизаде
21

Многие пользователи POCO сообщают об использовании его вместе с Boost, поэтому очевидно, что у людей в обоих проектах есть стимулы. Boost - это коллекция качественных библиотек. Но это не каркас. Что касается ACE, я использовал его раньше, и дизайн мне не понравился. Вдобавок его поддержка старых несовместимых компиляторов уродливо сформировала кодовую базу.

Что действительно отличает POCO, так это масштабируемый дизайн и интерфейс с богатой доступностью библиотек, напоминающий те, что есть в Java или C #. На данный момент наиболее остро не хватает POCO асинхронного ввода-вывода.

Alex
источник
11

Я использовал ACE для очень высокопроизводительного приложения для сбора данных с ограничениями в реальном времени. Один поток обрабатывает ввод-вывод от более чем тридцати соединений сокетов TCP / IC и последовательного порта. Код работает как в 32-битной, так и в 64-битной Linux. Некоторые из многих классов ACE, которые я использовал, - это ACE_Reactor, ACE_Time_Value, ACE_Svc_Handler, ACE_Message_Queue, ACE_Connector. ACE был ключевым фактором успеха нашего проекта. Требуются значительные усилия, чтобы понять, как использовать классы ACE. У меня есть все книги, написанные об ACE. Всякий раз, когда мне приходилось расширять функциональность нашей системы, обычно требуется некоторое время, чтобы изучить, что делать, и тогда количество необходимого кода очень мало. Я нашел ACE очень надежным. Я также использую немного кода от Boost. Я не вижу такой же функциональности в Boost.

Боб
источник
10

Недавно я получил новую работу и работаю над проектом, в котором используются ACE и TAO. Что ж, могу сказать, что ACE и TAO работают и полностью выполняют свои задачи. Но общая организация и дизайн библиотек довольно устрашающие ...

Например, основная часть ACE состоит из сотен классов, начинающихся с «ACE_». Похоже, они десятилетиями игнорировали пространства имен.

Кроме того, многие имена классов ACE также не предоставляют полезной информации. Или вы можете угадать, какие классы нравятся ACE_Dev_Poll_Reactor_Notifyили ACE_Proactor_Handle_Timeout_Upcallможно использовать?

Кроме того, документации по ACE действительно не хватает, поэтому, если вы не хотите изучать ACE сложным путем (это действительно сложно без хорошей документации ..), я бы НЕ рекомендовал использовать ACE, если вам действительно не нужно TAO для CORBA , если вы не нужна CORBA, используйте современные библиотеки ..

Смерлин
источник
7

Библиотеки сокетов ACE надежны. Если вы пытаетесь портировать стандартную реализацию сокетов, вы не ошибетесь. Код ACE придерживается жесткой парадигмы разработки. Конструкции более высокого уровня немного запутаны в использовании. Жесткая парадигма вызывает некоторые аномалии с обработкой исключений. Существуют или используются ситуации, когда пары строковых значений, передаваемые в исключение, когда одна из пар имеет значение null, вызывают выброс исключения в исключении, которое вас сбивает с толку. Глубина разделения классов утомительна при отладке. Я никогда не пробовал другие библиотеки, поэтому не могу дать толкового комментария.

Дэн
источник
6

Boost имеет статус «почти STL» из-за большого количества людей в комитете по стандартам C ++, которые также являются разработчиками Boost. Poco и ACE не пользуются этим преимуществом, и, судя по моему анекдотическому опыту, Boost более распространен.

Однако POCO в целом больше сосредоточена на вещах сетевого типа. Я придерживаюсь Boost, поэтому ничем не могу вам помочь, но плюс Boost - это (относительно) широкое использование.

rlbond
источник
4

Boost - это здорово, я слышал только хорошее о POCO (но никогда не использовал), но мне не нравится ACE, и я бы избегал его в будущем. Хотя вы найдете поклонников ACE, вы также найдете много недоброжелателей, которых вы не склонны получать с помощью boost или poco (IME), для меня это дает четкий сигнал, что ACE - не лучший инструмент (хотя он делает то, что говорит на жестяной банке).

Патрик
источник
10
ACE существует уже очень давно, и на протяжении многих лет ему приходилось поддерживать множество устаревших платформ. Это одна из причин, почему, например, это не такой современный Boost. Большое количество чрезвычайно полезных исследований и литературы вышло из ACE (см. Резюме Дуга Шмидта), которые другие смогли использовать и развить. Естественно, другие будут учиться на ошибках, сделанных в старых библиотеках, и улучшать их. Другие также придумают совершенно новые способы делать подобные вещи. Не будьте слишком суровы с ACE. Я также большой поклонник Boost. По общему признанию, я никогда не использовал POCO.
Void
6
ACE был запущен в то время, когда компиляторы были очень несовместимы (стандарта еще не существовало), а шаблоны были полным кошмаром (1996/1997), а существовала сотня Unix-подобных платформ. Я оценивал ACE + TAO для проекта - в конце концов мы остановились на OmniORB, TAO был настолько незрелым, что ломался с каждым новым выпуском. С другой стороны, ACE был рок. Это показывает его возраст с точки зрения настройки библиотеки, но он прочный и имеет большое количество поклонников. Однако я немного боялся доброжелательного диктатора - если Шмидт когда-нибудь вскочит, ACE может стать проблемой. У меня нет такого чувства с Boost.
Chris K
3

Из них я когда-либо использовал только ACE. ACE - отличная платформа для кроссплатформенных корпоративных сетевых приложений. Он чрезвычайно универсален и масштабируем и поставляется с TAO и JAWS для быстрой и эффективной разработки ORB и / или веб-приложений.

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

Однако он несколько тяжелый, поэтому для небольших приложений это может быть излишним. Читая резюме по POCO, кажется, что они стремятся к системе, которая может работать на встроенных системах, поэтому я предполагаю, что ее можно использовать гораздо проще. Теперь я могу покрутить его: P

Джеральд
источник
0

Я думаю, это действительно вопрос мнения, вряд ли есть правильный ответ.

По моему опыту написания переносимого серверного кода Win32 / Linux (15+ лет), я лично считаю boost / ACE излишне раздутыми и вносит опасности обслуживания (также известные как «ад dll») из-за небольшого преимущества, которое они дают.

ACE также кажется ужасно устаревшим, это «библиотека c ++», написанная «программистами на c» в 90-х годах, и, на мой взгляд, это действительно заметно. Так получилось, прямо сейчас я реинжинирую проект, написанный на Pico, мне кажется, что он полностью следует идее ACE, но, говоря более современным языком, не намного лучше.

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

ао
источник