ACE vs Boost vs POCO [zamknięte]

97

Od dłuższego czasu pracuję z bibliotekami Boost C ++ . Uwielbiam bibliotekę Boost Asio C ++ do programowania sieciowego. Jednak poznałem dwie inne biblioteki: POCO i framework Adaptive Communication Environment (ACE) . Chciałbym poznać dobro i zło każdego z nich.

rahul
źródło
3
ACE to „ostateczny szwajcarski scyzoryk do programowania sieciowego” do programowania w C ++, ale ostatnio sprawdziłem, że samo w sobie jest to również ogromna zależność.
brak

Odpowiedzi:

91

Jak powiedział rdbound, Boost ma status „bliski STL”. Więc jeśli nie potrzebujesz innej biblioteki, trzymaj się Boost. Jednak używam POCO, ponieważ ma to pewne zalety w mojej sytuacji. Dobre rzeczy w POCO IMO:

  • Lepsza biblioteka wątków, zwłaszcza implementacja metody aktywnej. Podoba mi się również to, że możesz ustawić priorytet wątku.

  • Bardziej wszechstronna biblioteka sieciowa niż boost::asio. Jednak boost::asiojest to również bardzo dobra biblioteka.

  • Obejmuje funkcje, których nie ma w Boost, takie jak XML i interfejs bazy danych, żeby wymienić tylko kilka.

  • Jest bardziej zintegrowana jako jedna biblioteka niż Boost.

  • Posiada czysty, nowoczesny i zrozumiały kod C ++. Uważam, że jest o wiele łatwiejszy do zrozumienia niż większość bibliotek Boost (ale nie jestem ekspertem od programowania szablonów :)).

  • Może być używany na wielu platformach.

Niektóre wady POCO to:

  • Ma ograniczoną dokumentację. Jest to nieco równoważone faktem, że źródło jest łatwe do zrozumienia.

  • Ma znacznie mniejszą społeczność i bazę użytkowników niż, powiedzmy, Boost. Jeśli więc zadasz pytanie na przykład na przepełnienie stosu, Twoje szanse na uzyskanie odpowiedzi są mniejsze niż w przypadku Boost

  • Okaże się, jak dobrze będzie on zintegrowany z nowym standardem C ++. Wiesz na pewno, że Boost nie będzie problemem.

Nigdy nie używałem ACE, więc nie mogę tego komentować. Z tego, co słyszałem, ludzie uważają POCO za bardziej nowoczesny i łatwiejszy w użyciu niż ACE.

Kilka odpowiedzi na komentarze Rahula:

  1. Nie znam się na wszechstronności i zaawansowaniu. Biblioteka wątków POCO zapewnia pewne funkcje, których nie ma w Boost: ActiveMethodi Activity, i ThreadPool. Wątki IMO POCO są również łatwiejsze w obsłudze i zrozumieniu, ale to kwestia subiektywna.

  2. Biblioteka sieciowa POCO zapewnia również obsługę protokołów wyższego poziomu, takich jak HTTP i SSL (prawdopodobnie również w boost::asio, ale nie jestem pewien?).

  3. Słusznie.

  4. Zaletą zintegrowanej biblioteki jest spójne kodowanie, dokumentacja i ogólny wygląd.

  5. Bycie wieloplatformowym jest ważną cechą POCO, nie jest to zaleta w stosunku do Boost.

Ponownie, prawdopodobnie powinieneś rozważyć POCO tylko wtedy, gdy zapewnia pewną potrzebną funkcjonalność i nie ma jej w Boost.

Dani van der Meer
źródło
1
Z tego, czego nauczyłem się o POCO, rzeczy nie wydają się sumować: 1. wątek boost wydaje się znacznie bardziej wszechstronny i zaawansowany. 2. W jaki sposób POCO jest bardziej wszechstronny? 3. Interesuje mnie tylko networking. XML i baza danych mnie nie dotyczą. 4. Zintegrowane jako jedna biblioteka? Nie jestem pewien, czy to dobrze czy źle? 5. Uważam, że Boost (i dotyczy to również boostu :: asio) jest również dość wieloplatformowy.
rahul
@Rahul Próbowałem odpowiedzieć na niektóre z twoich punktów w odpowiedzi.
Dani van der Meer
Nie patrzyłem ostatnio na POCO, ale kiedy patrzyłem na to kilka lat temu, zniechęcił mnie fakt, że komponenty wydawały się używać mieszanki licencji. Niektórzy używali licencji Boost, inni GPL. Niektóre elementy szyfrowania wymagały licencji do użytku komercyjnego. Nie wiem, jaka jest obecna sytuacja licencyjna z POCO, ale przyjrzałbym się temu uważnie przed użyciem.
Ferruccio
10
POCO jest w całości objęty licencją w ramach licencji Boost (do wykorzystania w przyszłości).
Brendan Long
1
Jedną z zalet Poco jest to, że ma znacznie krótsze czasy kompilacji. Ponieważ Boost generalnie polega na dużej ilości kodu w nagłówkach, czas kompilacji może być długi. Dzięki poco istnieje bardziej dynamiczne łączenie, które skraca czas kompilacji. Istnieje również korzyść w zakresie bezpieczeństwa, ponieważ użytkownik może zaktualizować .so / .dll bez konieczności ponownej kompilacji wszystkiego.
ericcurtin
28

Wykorzystałem wszystkie trzy, więc oto moje 0,02 dolara.

Naprawdę chcę głosować na Douga Schmidta i szanować całą jego pracę, ale szczerze mówiąc uważam, że ACE jest lekko wadliwy i trudny w użyciu. Myślę, że ta biblioteka wymaga ponownego uruchomienia. Trudno to powiedzieć, ale na razie unikałbym ACE, chyba że istnieje nieodparty powód, aby używać TAO lub potrzebujesz jednego kodu do uruchomienia C ++ na obu wariantach Uniksa i Windows. TAO świetnie radzi sobie z wieloma trudnymi problemami, ale krzywa uczenia się jest intensywna i nie bez powodu CORBA ma wielu krytyków. Myślę, że po prostu zrób swoją pracę domową, zanim podejmiesz decyzję o użyciu jednego z nich.

Jeśli piszesz w C ++, myślę o przyspieszeniu. Korzystam z wielu bibliotek niskiego poziomu i uważam je za niezbędne. Szybkie grep mojego kodu ujawnia shared_ptr, program_options, regex, bind, serialization, foreach, property_tree, filesystem, tokenizer, różne rozszerzenia iteratorów, alogrithm i mem_fn. Są to głównie funkcje niskiego poziomu, które naprawdę powinny znajdować się w kompilatorze. Niektóre biblioteki boost są bardzo ogólne; nakłonienie ich do zrobienia tego, co chcesz, może być pracą, ale warto.

Poco to zbiór klas narzędzi, które zapewniają funkcjonalność dla niektórych bardzo konkretnych, typowych zadań. Uważam, że biblioteki są dobrze napisane i intuicyjne. Nie muszę poświęcać dużo czasu na studiowanie dokumentacji lub pisanie głupich programów testowych. Obecnie używam Loggera, XML, Zip i Net / SMTP. Zacząłem używać Poco, kiedy libxml2 po raz ostatni mnie zirytowało. Są inne klasy, których mógłbym użyć, ale nie próbowałem, np. Data :: MySQL (jestem zadowolony z mysql ++) i Net :: HTTP (jestem zadowolony z libCURL). W końcu wypróbuję resztę Poco, ale w tym momencie nie jest to priorytet.


źródło
Dobry opis, dzięki.
Amir Naghizadeh
21

Wielu użytkowników POCO zgłasza używanie go razem z Boostem, więc oczywiste jest, że w obu projektach istnieją zachęty dla ludzi. Boost to zbiór wysokiej jakości bibliotek. Ale to nie jest ramy. Jeśli chodzi o ACE, używałem go w przeszłości i nie podobał mi się projekt. Dodatkowo, wsparcie dla starożytnych, niezgodnych kompilatorów źle ukształtowało bazę kodu.

To, co naprawdę wyróżnia POCO, to skalowalny projekt i interfejs o bogatej dostępności bibliotek, przypominający te, które można uzyskać w Javie lub C #. W tej chwili najbardziej brakującą rzeczą w POCO jest asynchroniczne IO.

Alex
źródło
11

Użyłem ACE do bardzo wydajnej aplikacji do zbierania danych z ograniczeniami czasu rzeczywistego. Pojedynczy wątek obsługuje operacje we / wy z ponad trzydziestu połączeń za pomocą gniazd TCP / IC i portu szeregowego. Kod działa na 32- i 64-bitowym Linuksie. Kilka z wielu klas ACE, których użyłem, to ACE_Reactor, ACE_Time_Value, ACE_Svc_Handler, ACE_Message_Queue, ACE_Connector. ACE było kluczowym czynnikiem sukcesu naszego projektu. Zrozumienie, jak używać klas ACE, wymaga sporego wysiłku. Mam wszystkie książki napisane o ACE. Ilekroć musiałem rozszerzyć funkcjonalność naszego systemu, zwykle przeanalizowanie, co mam zrobić, zajmuje trochę czasu, a wtedy ilość wymaganego kodu jest bardzo mała. ACE jest dla mnie bardzo niezawodne. Używam też trochę kodu z Boost. Nie widzę tej samej funkcjonalności w Boost.

Pion
źródło
10

Niedawno dostałem nową pracę i pracuję nad projektem, który wykorzystuje ACE i TAO. Cóż, mogę powiedzieć, że ACE i TAO pracują iw pełni wykonują swoje zadania. Ale ogólna organizacja i projekt bibliotek są dość zniechęcające ...

Na przykład główna część ACE składa się z setek klas zaczynających się od „ACE_”. Wygląda na to, że przez dziesięciolecia ignorowali przestrzenie nazw.

Ponadto wiele nazw klas ACE również nie dostarcza przydatnych informacji. Czy możesz zgadnąć, jakie klasy lubią ACE_Dev_Poll_Reactor_Notifylub ACE_Proactor_Handle_Timeout_Upcallmogą być używane?

Dodatkowo, dokumentacja ACE naprawdę brakuje, więc jeśli nie chcesz nauczyć się ACE na własnej skórze (jest to naprawdę trudne bez dobrej dokumentacji ..), NIE polecam używania ACE, chyba że naprawdę potrzebujesz TAO dla CORBA , jeśli nie potrzebujesz CORBA, śmiało używaj nowoczesnych bibliotek.

smerlin
źródło
7

Biblioteki gniazd ACE są stałe. Jeśli próbujesz przenieść standardową implementację gniazd, nie możesz się pomylić. Kod ACE trzyma się sztywnego paradygmatu rozwoju. Konstrukcje wyższego poziomu są trochę mylące w użyciu. Sztywny paradygmat powoduje pewne anomolie z obsługą wyjątków. Istnieją lub były sytuacje, w których pary wartości ciągu są przekazywane do wyjątku, przy czym jedna z par ma wartość null, co powoduje zgłoszenie wyjątku w wyjątku, który będzie Cię zdumiewać. Głębokość warstwowania klas jest uciążliwa podczas debugowania. Nigdy nie próbowałem innych bibliotek, więc nie mogę zrobić inteligentnego komentarza.

Dan
źródło
6

Boost cieszy się statusem „prawie STL” ze względu na liczbę osób w komitecie ds. Standardów C ++, którzy są również programistami Boost. Poco i ACE nie cieszą się z tej korzyści, a z mojego anegdotycznego doświadczenia wynika, że ​​Boost jest bardziej rozpowszechniony.

Jednak POCO jako całość jest bardziej skoncentrowane na rzeczach sieciowych. Trzymam się Boost, więc nie mogę ci w tym pomóc, ale plusem Boost jest jego (stosunkowo) powszechne zastosowanie.

rlbond
źródło
4

Boost jest świetny, słyszałem tylko dobre rzeczy o POCO (ale nigdy nie używałem), ale nie lubię ACE i unikałbym go w przyszłości. Chociaż znajdziesz fanów ACE, znajdziesz również wielu przeciwników, których nie dostajesz za pomocą boosta lub poco (IME), co dla mnie wysyła jasny sygnał, że ACE nie jest najlepszym narzędziem (chociaż robi to, co mówi na puszce).

Patrick
źródło
10
ACE istnieje od bardzo dawna i przez lata musiało obsługiwać wiele starszych platform. Jest to na przykład jeden z powodów, dla których nie jest tak nowoczesny Boost. ACE wyszło z wielu niezwykle przydatnych badań i literatury (patrz CV Douga Schmidta), które inni mogli wykorzystać i na których mogli budować. Oczywiście inni będą uczyć się na błędach popełnianych w starszych bibliotekach i poprawiać je. Inni również wymyślą zupełnie nowe sposoby robienia podobnych rzeczy. Nie bądź zbyt surowy dla ACE. Jestem też wielkim fanem Boosta. Trzeba przyznać, że nigdy nie korzystałem z POCO.
Nieważne
6
ACE powstało w czasie, gdy kompilatory były bardzo niekompatybilne (nie istniał jeszcze żaden standard), a szablony były kompletnym koszmarem (1996/1997) i istniało sto platform podobnych do Uniksa. Oceniałem ACE + TAO pod kątem projektu - ostatecznie zdecydowaliśmy się na OmniORB, TAO był tak niedojrzały, że pękał z każdym nowym wydaniem. ACE z drugiej strony był kamieniem. Pokazuje, że jest stary, jeśli chodzi o konfigurację biblioteki, ale jest solidny i ma wielu zwolenników. Trochę obawiałem się jednak życzliwego dyktatora - gdyby Schmidt kiedykolwiek wszedł do butów, ACE może być problemem. Nie mam tego uczucia w przypadku Boost.
Chris K,
3

Z tych, z których korzystałem tylko ACE. ACE to świetny framework dla wieloplatformowych aplikacji sieciowych. Jest niezwykle wszechstronny i skalowalny oraz wyposażony w TAO i JAWS do szybkiego, wydajnego tworzenia aplikacji ORB i / lub aplikacji internetowych.

Szybsze zapoznanie się z nim może być nieco zniechęcające, ale jest na ten temat dużo literatury i dostępne jest wsparcie komercyjne.

Jest jednak nieco ciężki, więc w przypadku aplikacji na mniejszą skalę może to być trochę przesada. Czytając podsumowanie POCO, wygląda na to, że dążą do systemu, który można uruchomić na systemach wbudowanych, więc zakładam, że można go używać w znacznie lżejszy sposób. Mogę teraz nadać temu wir: P

Gerald
źródło
0

Myślę, że to naprawdę kwestia opinii, nie ma właściwej odpowiedzi.

Z mojego doświadczenia w pisaniu kodu przenośnego serwera Win32 / Linux (ponad 15 lat) osobiście uważam, że boost / ACE jest niepotrzebnie rozdęty i wprowadza zagrożenia związane z konserwacją (znane również jako „dll hell”) ze względu na niewielką korzyść, jaką dają.

ACE również wydaje się być okropnie przestarzałe, jest "biblioteką c ++" napisaną przez "programistów c" w latach 90-tych i moim zdaniem naprawdę to widać. Tak się składa, że ​​w tej chwili przeprojektowuję projekt napisany z Pico, wydaje mi się, że jest on całkowicie zgodny z ideą ACE, ale w bardziej współczesnych terminach, niewiele lepszy.

W każdym razie dla wysokiej wydajności, wydajnej i eleganckiej komunikacji z serwerem lepiej byłoby nie używać żadnego z nich.

ao
źródło