ACE vs Boost vs POCO [zamknięty]

Użyłem wszystkich trzech, więc oto moje $0.02.

Naprawdę chcę głosować na Douga Schmidta i szanować całą pracę, którą wykonał, ale szczerze mówiąc uważam, że ACE jest lekko buggy i trudny w użyciu. Myślę, że biblioteka potrzebuje restartu. Trudno to powiedzieć, ale na razie unikałbym ACE ' a, chyba że istnieje przekonujący powód, aby używać TAO, lub potrzebujesz jednej bazy kodu, aby uruchomić C++ zarówno na odmianach Uniksa, jak i Windows. TAO jest fantastyczny dla wielu trudnych problemów, ale krzywa uczenia się jest nie bez powodu CORBA ma wielu krytyków. Myślę, że po prostu odrobić pracę domową przed podjęciem decyzji o użyciu albo.

Jeśli kodujesz w C++, boost jest w mojej głowie bezmyślny. Używam wielu bibliotek niskiego poziomu i uważam je za niezbędne. Szybki grep mojego kodu ujawnia shared_ptr, program_options, regex, bind, serialization, foreach, property_tree, filesystem, tokenizer, różne rozszerzenia iteratora, alogrithm i mem_fn. Są to w większości niskopoziomowe funkcjonalność, która naprawdę powinna być w kompilatorze. Niektóre biblioteki boost są bardzo ogólne; może to być praca, aby zmusić je do zrobienia tego, co chcesz, ale warto.

Poco jest zbiorem klas użyteczności, które zapewniają funkcjonalność dla niektórych bardzo konkretnych wspólnych zadań. Uważam, że biblioteki są dobrze napisane i intuicyjne. Nie muszę spędzać dużo czasu na studiowaniu dokumentacji lub pisaniu głupich programów testowych. Obecnie używam Loggera, XML, Zip i Net / SMTP. Zacząłem używać Poco kiedy libxml2 irytowało mnie po raz ostatni. 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 to nie jest priorytet w tym momencie.

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

To, co naprawdę wyróżnia POCO, to projekt, który jest skalowany i interfejs z bogatą dostępnością bibliotek przypomina te, które dostaje się z Java lub C#. W tej chwili najbardziej dotkliwym brakiem poco jest asynchroniczne IO.

Używałem ACE do bardzo wydajnej aplikacji do akwizycji danych z ograniczeniami w czasie rzeczywistym. Pojedynczy wątek obsługuje I/O z ponad trzydziestu gniazd TCP / IC i portu szeregowego. Kod działa zarówno na 32, jak i 64-bitowym Linuksie. Kilka z wielu klas ACE, których używałem, to ACE_Reactor, ACE_Time_Value, ACE_Svc_Handler, ACE_Message_Queue, ACE_Connector. ACE był kluczowym czynnikiem sukcesu naszego projektu. Trzeba sporo wysiłku, aby zrozumieć, jak korzystać z ASA klasy. Mam wszystkie książki napisane o ACE. Ilekroć musiałem rozszerzyć funkcjonalność naszego systemu, zazwyczaj zajmuje to trochę czasu, aby przestudiować, co robić, a następnie ilość wymaganego kodu jest bardzo mała. Uważam, że ACE jest bardzo wiarygodny. Używam również trochę kodu Z Boost. Nie widzę tej samej funkcjonalności w Boost. Użyłbym jednej lub obu bibliotek.

Ostatnio dostałem nową pracę i pracuję nad projektem wykorzystującym ACE i TAO. Cóż, mogę powiedzieć, że ACE i TAO pracują i w pełni wykonują swoje zadania. Ale ogólna organizacja i konstrukcja 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 ignorowali przestrzenie nazw od dziesięcioleci.

Dodatkowo wiele nazw klas ACE ' a również nie dostarcza użytecznych informacji. A może ty Zgadnij do jakich klas jak ACE_Dev_Poll_Reactor_Notify lub ACE_Proactor_Handle_Timeout_Upcall można użyć?

Dodatkowo, dokumentacji ACE 'a naprawdę brakuje, więc chyba, że chcesz nauczyć się ACE' a trudniej (jest naprawdę ciężko bez żadnej dobrej dokumentacji..), Nie polecam używania ACE, chyba że naprawdę potrzebujesz TAO dla CORBA, jeśli nie potrzebujesz Corby, skorzystaj z nowoczesnych bibliotek..

Biblioteki gniazd ACE są solidne. Jeśli próbujesz portować standardową implementację gniazd, nie możesz się pomylić. Kod ACE trzyma się sztywnego paradygmatu rozwoju. Konstrukcje wyższego poziomu są nieco 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 łańcuchowych przekazywane do wyjątku z jednym z par jest null powoduje wyjątek wrzucić wyjątek, który będzie boggle you. Głębia warstw klas jest uciążliwa podczas debugowania. Nigdy nie próbowałem innych bibliotek, więc nie mogę zrobić inteligentnego komentarza.

Boost cieszy się statusem "blisko STL" ze względu na liczbę osób w C++ standards committee, którzy są również programistami Boost. Poco i ACE nie cieszą się tą korzyścią, a z mojego anegdotycznego doświadczenia Boost jest bardziej rozpowszechniony.

Jednak POCO jako całość jest bardziej skoncentrowane wokół rzeczy typu sieciowego. Trzymam się Boosta, więc nie mogę ci tam pomóc, ale plusem dla boosta jest jego (stosunkowo) powszechne zastosowanie.

Boost jest świetny, słyszałem tylko dobre rzeczy o POCO (ale nigdy nie używane), ale nie lubię ACE i chciałbym go uniknąć w przyszłości. Chociaż znajdziesz fanów ACE można również znaleźć wielu krytyków, których nie mają tendencję do uzyskania Z boost lub poco (IME), do mnie, że wysyła wyraźny sygnał, że ACE nie jest najlepszym narzędziem (chociaż robi to, co mówi na puszce).

Z tych, których używałem tylko ACE ' a. ACE to świetny framework dla wieloplatformowych aplikacji sieciowych dla przedsiębiorstw. Jest niezwykle wszechstronny i skalowalny oraz wyposażony w Tao i szczęki do szybkiego, wydajnego rozwoju aplikacji ORB i / lub Internetowych.

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

Jest jednak nieco ciężki, więc dla mniejszych aplikacji może to być trochę przesada. Czytając podsumowanie dla POCO brzmi to tak, jakby dążyli do systemu, który może być uruchamiany na systemach wbudowanych, więc zakładam, że może być używany w znacznie lżejszy sposób. Mogę teraz dać wir :p

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

W moim doświadczeniu z pisaniem przenośnego kodu serwera Win32 / Linux (15 + lat), osobiście uważam boost/ACE za niepotrzebnie nadęty i wprowadza zagrożenia konserwacyjne (inaczej znane jako "dll hell") dla małej przewagi, jaką dają.

ACE również wydaje się być strasznie przestarzały, jest to "biblioteka C++ "napisana przez" programistów c " w latach 90 - tych i naprawdę pokazuje się moim zdaniem. Tak się składa, że w tej chwili przeprojektowuję projekt napisany z Pico, wydaje mi się, że całkowicie podąża za ideą ACE, ale w bardziej współczesnych terminach, w tym niewiele lepiej.

W każdym razie dla wysokiej wydajności, wydajnej, eleganckiej komunikacji serwera może być lepiej nie używać żadnej z nich.