wake-up-neo.com

ACE gegen Boost gegen POCO

Ich arbeite seit einiger Zeit mit den Boost C++ Libraries . Ich liebe den Boost Asio C++ - Bibliothek für die Netzwerkprogrammierung. Ich wurde jedoch mit zwei anderen Bibliotheken bekannt gemacht: POCO und Adaptive Communication Environment (ACE) framework . Ich würde gerne das Gute und das Schlechte von jedem erfahren.

90
rahul

Wie bereits erwähnt, hat Boost den Status "Near STL". Wenn Sie also keine andere Bibliothek brauchen haben, bleiben Sie bei Boost. Ich benutze jedoch POCO , weil es einige Vorteile für meine Situation hat. Das Gute an POCO IMO:

  • Bessere Thread-Bibliothek, insbesondere eine Active Method-Implementierung. Mir gefällt auch die Tatsache, dass man die Thread-Priorität einstellen kann.

  • Umfangreichere Netzwerkbibliothek als boost::asio. Jedoch boost::asio ist auch eine sehr gute Bibliothek.

  • Enthält Funktionen, die nicht in Boost enthalten sind, wie XML und die Datenbankschnittstelle, um nur einige zu nennen.

  • Es ist mehr als eine Bibliothek als Boost integriert.

  • Es hat sauberen, modernen und verständlichen C++ - Code. Ich finde es viel einfacher zu verstehen als die meisten Boost-Bibliotheken (aber ich bin kein Experte für Template-Programmierung :)).

  • Es kann auf vielen Plattformen eingesetzt werden.

Einige Nachteile von POCO sind:

  • Die Dokumentation ist begrenzt. Dies wird etwas durch die Tatsache ausgeglichen, dass die Quelle leicht zu verstehen ist.

  • Es hat eine weitaus kleinere Community und Nutzerbasis als beispielsweise Boost. Wenn Sie zum Beispiel eine Frage zu Stack Overflow stellen, ist die Wahrscheinlichkeit geringer, eine Antwort zu erhalten, als bei Boost

  • Es bleibt abzuwarten, wie gut es in den neuen C++ - Standard integriert werden wird. Sie wissen sicher, dass Boost keine Probleme haben wird.

Ich habe ACE nie benutzt, kann es also nicht wirklich kommentieren. Nach allem, was ich gehört habe, finden die Leute POCO moderner und benutzerfreundlicher als ACE.

Einige Antworten auf die Kommentare von Rahul:

  1. Ich weiß nicht über vielseitig und fortgeschritten. Die POCO-Thread-Bibliothek bietet einige Funktionen, die nicht in Boost enthalten sind: ActiveMethod und Activity und ThreadPool. IMO POCO-Threads sind auch einfacher zu verwenden und zu verstehen, dies ist jedoch eine subjektive Angelegenheit.

  2. Die POCO-Netzwerkbibliothek bietet auch Unterstützung für übergeordnete Protokolle wie HTTP und SSL (möglicherweise auch in boost::asio, aber ich bin mir nicht sicher?).

  3. Meinetwegen.

  4. Die integrierte Bibliothek bietet den Vorteil einer konsistenten Codierung, Dokumentation und eines allgemeinen "Look and Feel".

  5. Plattformübergreifend zu sein, ist ein wichtiges Merkmal von POCO. Dies ist kein Vorteil in Bezug auf Boost.

Auch hier sollten Sie POCO wahrscheinlich nur in Betracht ziehen, wenn es einige Funktionen bietet, die Sie benötigen, und das nicht in Boost.

84

Ich habe alle drei verwendet und hier sind meine 0,02 $.

Ich möchte wirklich für Doug Schmidt stimmen und seine ganze Arbeit respektieren, aber um ehrlich zu sein, finde ich ACE leicht fehlerhaft und schwer zu bedienen. Ich denke, dass die Bibliothek einen Neustart benötigt. Es ist schwer zu sagen, aber ich würde ACE vorerst scheuen, es sei denn, es gibt einen zwingenden Grund, TAO zu verwenden, oder Sie benötigen eine einzige Codebasis, um C++ sowohl unter Unix-Varianten als auch unter Windows auszuführen. TAO ist fabelhaft für eine Reihe schwieriger Probleme, aber die Lernkurve ist intensiv und es gibt einen Grund, warum CORBA eine Reihe von Kritikern hat. Ich schätze, machen Sie einfach Ihre Hausaufgaben, bevor Sie sich für eine der beiden entscheiden.

Wenn Sie in C++ programmieren, ist Boost für mich ein Kinderspiel. Ich benutze eine Reihe von Bibliotheken auf niedriger Ebene und finde sie essentiell. Ein kurzer Blick auf meinen Code zeigt shared_ptr, program_options, regex, bind, serialization, foreach, property_tree, filesystem, tokenizer, verschiedene Iteratorerweiterungen, alogrithm und mem_fn. Hierbei handelt es sich zumeist um einfache Funktionen, die eigentlich im Compiler enthalten sein sollten. Einige Boost-Bibliotheken sind sehr allgemein gehalten. Es kann Arbeit sein, sie dazu zu bringen, das zu tun, was Sie wollen, aber es lohnt sich.

Poco ist eine Sammlung von Utility-Klassen, die Funktionen für einige sehr konkrete allgemeine Aufgaben bereitstellen. Ich finde die Bibliotheken gut geschrieben und intuitiv. Ich muss nicht viel Zeit damit verbringen, Dokumentation zu studieren oder alberne Testprogramme zu schreiben. Ich verwende derzeit Logger, XML, Zip und Net/SMTP. Ich habe angefangen, Poco zu verwenden, als mich libxml2 zum letzten Mal irritierte. Es gibt andere Klassen, die ich verwenden könnte, aber noch nicht ausprobiert habe, z. Data :: MySQL (ich bin mit MySQL ++ zufrieden) und Net :: HTTP (ich bin mit libCURL zufrieden). Ich werde den Rest von Poco irgendwann einmal ausprobieren, aber das hat an dieser Stelle noch keine Priorität.

26
user2460683

Viele POCO-Benutzer berichten, dass sie es zusammen mit Boost verwenden, sodass es offensichtlich Anreize für Menschen in beiden Projekten gibt. Boost ist eine Sammlung hochwertiger Bibliotheken. Aber es ist kein Rahmen. Was ACE betrifft, habe ich es in der Vergangenheit benutzt und das Design nicht gemocht. Darüber hinaus hat seine Unterstützung für alte, nicht konforme Compiler die Codebasis auf hässliche Weise geprägt.

Was POCO wirklich auszeichnet, ist ein skalierbares Design und eine Schnittstelle mit umfangreicher Bibliotheksverfügbarkeit, die an die von Java oder C # erinnert. Derzeit fehlt POCO am meisten an asynchronem E/A.

19
Alex

Ich habe ACE für eine sehr leistungsfähige Datenerfassungsanwendung mit Echtzeitbeschränkungen verwendet. Ein einzelner Thread verarbeitet E/A von über 30 TCP/IC-Socket-Verbindungen und einem seriellen Port. Der Code läuft sowohl auf 32- als auch auf 64-Bit-Linux. Einige der vielen von mir verwendeten ACE-Klassen sind ACE_Reactor, ACE_Time_Value, ACE_Svc_Handler, ACE_Message_Queue und ACE_Connector. ACE war ein Schlüsselfaktor für den Erfolg unseres Projekts. Es ist sehr aufwändig, die Verwendung der ACE-Klassen zu verstehen. Ich habe alle Bücher über ACE geschrieben. Wann immer ich die Funktionalität unseres Systems erweitern musste, dauert es in der Regel einige Zeit, um zu untersuchen, was zu tun ist, und dann ist die erforderliche Codemenge sehr gering. Ich habe ACE als sehr zuverlässig empfunden. Ich benutze auch ein bisschen Code von Boost. Ich sehe nicht die gleiche Funktionalität in Boost. Ich würde eine oder beide Bibliotheken verwenden.

10
Bob

Ich habe vor kurzem einen neuen Job bekommen und arbeite an einem Projekt, das ACE und TAO verwendet. Nun, ich kann sagen, dass ACE und TAO arbeiten und ihre Aufgaben voll erfüllen. Aber die Gesamtorganisation und das Design der Bibliotheken sind ziemlich entmutigend ...

Beispielsweise besteht der Hauptteil von ACE aus Hunderten von Klassen, die mit "ACE_" beginnen. Es scheint, als hätten sie Namespaces seit Jahrzehnten ignoriert.

Darüber hinaus enthalten viele der Klassennamen von ACE auch keine nützlichen Informationen. Oder können Sie erraten, welche Klassen wie ACE_Dev_Poll_Reactor_Notify oder ACE_Proactor_Handle_Timeout_Upcall kann verwendet werden für?

Außerdem fehlt die Dokumentation von ACE wirklich, so dass ich die Verwendung von ACE NICHT empfehlen würde, es sei denn, Sie möchten ACE auf die harte Tour lernen (es ist wirklich schwierig, ohne eine gute Dokumentation), es sei denn, Sie benötigen wirklich TAO for CORBA , Wenn Sie CORBA nicht benötigen, können Sie einige moderne Bibliotheken verwenden.

10
smerlin

Die ACE-Socket-Bibliotheken sind solide. Wenn Sie versuchen, eine Standardimplementierung von Sockets zu portieren, können Sie nichts falsch machen. Der ACE-Code folgt einem starren Entwicklungsparadigma. Die höherstufigen Konstrukte sind etwas verwirrend in der Verwendung. Das starre Paradigma verursacht einige Anomolien bei der Ausnahmebehandlung. Es gibt oder gab Situationen, in denen Zeichenfolgenwertpaare, die an eine Ausnahme übergeben wurden, wobei eines der Paare null ist, einen Ausnahmefehler in der Ausnahme verursachen, der Sie überraschen wird. Die Tiefe der Klassenüberlagerung ist beim Debuggen mühsam. Ich habe die anderen Bibliotheken noch nie ausprobiert, kann also keinen intelligenten Kommentar abgeben.

7
Dan

Boost genießt aufgrund der Anzahl der Mitglieder des C++ - Standardkomitees, die auch Boost-Entwickler sind, den Status "Near STL". Poco und ACE genießen diesen Vorteil nicht, und Boost ist nach meiner anekdotischen Erfahrung weiter verbreitet.

POCO als Ganzes konzentriert sich jedoch mehr auf netzwerkartige Dinge. Ich halte mich an Boost, also kann ich dir dort nicht helfen, aber das Plus für Boost ist seine (relativ) weit verbreitete Verwendung.

5
rlbond

Boost ist großartig, ich habe nur gute Dinge über POCO gehört (aber nie benutzt), aber ich mag ACE nicht und würde es in Zukunft vermeiden. Auch wenn Sie ACE-Fans finden, werden Sie auch viele Kritiker finden, die Sie mit Boost oder Poco (IME) eher nicht erreichen, was für mich ein klares Signal ist, dass ACE nicht das beste Tool ist (obwohl es das tut, was es verspricht) auf der Dose).

4
Patrick

Von diesen habe ich ACE nur wirklich benutzt. ACE ist ein hervorragendes Framework für plattformübergreifende Unternehmensnetzwerkanwendungen. Es ist äußerst vielseitig und skalierbar und wird mit TAO und JAWS für die schnelle und leistungsstarke Entwicklung von ORB- und/oder webbasierten Anwendungen geliefert.

Sich damit vertraut zu machen, kann etwas entmutigend sein, aber es gibt eine Menge Literatur und kommerziellen Support.

Es ist allerdings etwas schwer, so dass es für kleinere Apps ein bisschen übertrieben sein kann. Wenn man die Zusammenfassung für POCO liest, hört es sich so an, als würden sie auf ein System abzielen, das auf eingebetteten Systemen ausgeführt werden kann, also gehe ich davon aus, dass es auf eine viel leichtere Art und Weise verwendet werden kann. Ich darf es jetzt mal ausprobieren: P

3
Gerald

Ich denke, es ist wirklich eine Frage der Meinung, es gibt kaum eine richtige Antwort.

Aufgrund meiner Erfahrung mit dem Schreiben von portablem Win32/Linux-Servercode (über 15 Jahre) empfinde ich Boost/ACE als unnötig aufgebläht und füge Wartungsrisiken (auch bekannt als "dll hell") hinzu, für den geringen Vorteil, den sie bieten.

ACE scheint auch furchtbar veraltet zu sein, es ist eine "C++ - Bibliothek", die in den 90er Jahren von "C-Programmierern" geschrieben wurde und meiner Meinung nach sehr gut funktioniert. Es passiert also, dass ich gerade das mit Pico geschriebene Projekt überarbeite, es scheint mir, dass es der ACE-Idee vollständig folgt, aber in zeitgemäßeren Begriffen ist das nicht viel besser.

In jedem Fall ist es für eine leistungsstarke, effiziente und elegante Serverkommunikation besser, wenn Sie keine davon verwenden.

1
a o