ACE проти Boost проти POCO [закрито]


96

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


3
ACE - це "кінцевий мережевий програмувальний швейцарський армійський ніж" для програмування на C ++, але останнє, що я перевірив, це також була величезна залежність монстра сама по собі.
немає

Відповіді:


90

Як сказав rdbound, Boost має статус "близько STL". Тож якщо вам не потрібна інша бібліотека, дотримуйтесь Boost. Однак я використовую POCO, оскільки він має певні переваги для моєї ситуації. Хороші речі POCO IMO:

  • Краща бібліотека потоків, особливо реалізація Active Method. Мені також подобається той факт, що ви можете встановити пріоритет потоку.

  • Повніша мережева бібліотека, ніж boost::asio. Однак boost::asioце також дуже хороша бібліотека.

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

  • Він інтегрований як одна бібліотека, ніж Boost.

  • Він має чистий, сучасний і зрозумілий код С ++. Мені це набагато легше зрозуміти, ніж більшість бібліотек Boost (але я не фахівець з програмування шаблонів :)).

  • Його можна використовувати на багатьох платформах.

Деякі недоліки POCO:

  • Він має обмежену документацію. Це дещо компенсується тим фактом, що джерело легко зрозуміти.

  • Він має набагато меншу спільноту та базу користувачів, ніж, скажімо, Boost. Отже, якщо ви ставите питання на Stack Overflow, наприклад, ваші шанси отримати відповідь менші, ніж для 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. потік boost здається набагато універсальнішим і вдосконаленим. 2. Якими способами POCO є більш універсальним? 3. Мене цікавить лише мережа. XML і база даних мене не стосуються. 4. Інтегрована як одна бібліотека? Я не впевнений, це добре чи погано? 5. Boost, я вважаю (і це стосується і boost :: asio), також є цілком перехресною платформою.
rahul

@Rahul Я намагався відповісти на деякі Ваші моменти у відповіді.
Дані ван дер Меер,

Я недавно не дивився на POCO, але коли я подивився його кілька років тому, мене збентежило те, що компоненти, здавалося, використовують суміш ліцензій. Одні використовували ліцензію Boost, інші - GPL. Деякі з матеріалів шифрування потребували ліцензії на комерційне використання. Я не знаю, яка ситуація з ліцензуванням на даний момент з POCO, але я б уважно подивився на це, перш ніж використовувати його.
Ферруччо

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, серіалізацію, foreach, property_tree, файлову систему, токенізатор, різні розширення ітераторів, 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 - це асинхронний IO.


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 дотримується жорсткої парадигми розвитку. Конструкції вищого рівня трохи заплутані у використанні. Жорстка парадигма спричиняє деякі аномалії, крім обробки винятків. Бувають або використовувались ситуації, коли пари рядкових значень, передані у виняток, одна з пар є нульовим, викликають виняток викиду у винятку, який завадить вас. Глибина шару класів нудна під час налагодження. Я ніколи не пробував інші бібліотеки, тому не можу робити розумних коментарів.


6

Boost має статус "майже STL" завдяки кількості людей у ​​комітеті зі стандартів C ++, які також є розробниками Boost. Poco та ACE не користуються цією перевагою, і з мого анекдотичного досвіду Boost є більш розповсюдженим.

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


4

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


10
ACE існує дуже давно, і протягом багатьох років їй доводилося підтримувати багато застарілих платформ. Це одна з причин, чому це не такий сучасний Boost, наприклад. З АСЕ вийшло багато надзвичайно корисних досліджень та літератури (див. Резюме Дага Шмідта), якими змогли скористатися інші люди та використати їх. Природно, що інші будуть вчитися на помилках, допущених у старих бібліотеках, та вдосконалювати їх. Інші також запропонують абсолютно нові способи робити подібні речі. Не будьте занадто жорстким до ACE. Я також великий шанувальник Boost. Слід визнати, що я ніколи не використовував POCO.
Порожнеча

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 hell") за незначну перевагу, яку вони дають.

ACE також здається жахливо застарілим, це "бібліотека с ++", написана "програмістами" в 90-х, і це, на мій погляд, справді видно. Так трапляється, зараз я переробляю проект, написаний разом з Піко, мені здається, він повністю відповідає ідеї ACE, але в більш сучасному плані не набагато кращий у цьому.

У будь-якому випадку для високопродуктивного, ефективного, елегантного серверного зв'язку вам може бути краще не використовувати жоден з них.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.