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.
Odpowiedzi:
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:
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.
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?).
Słusznie.
Zaletą zintegrowanej biblioteki jest spójne kodowanie, dokumentacja i ogólny wygląd.
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.
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.
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.
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.
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.
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.
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.
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).
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
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.