ACE vs Boost vs POCO [geschlossen]

Ich arbeite seit einiger Zeit mit den Boost C ++ - Bibliotheken . Ich liebe die Boost Asio C ++ - Bibliothek für die Netzwerkprogrammierung. Ich wurde jedoch in zwei andere Bibliotheken eingeführt: POCO und Adaptive Communication Environment (ACE) . Ich würde gerne das Gute und das Schlechte von jedem wissen.

Wie bereits erwähnt, hat Boost den Status "Near STL". Wenn Sie also keine weitere Bibliothek benötigen , bleiben Sie bei Boost. Ich benutze jedoch POCO, weil es einige Vorteile für meine Situation hat. Die guten Dinge an POCO IMO:

• Bessere Thread-Bibliothek, insbesondere eine Implementierung der aktiven Methode. Mir gefällt auch die Tatsache, dass Sie die Thread-Priorität festlegen können.

• Umfangreichere Netzwerkbibliothek als boost::asio. Es boost::asioist aber auch eine sehr gute Bibliothek.

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

• Es ist mehr als eine Bibliothek integriert als Boost.

• 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 Vorlagenprogrammierung :)).

• Es kann auf vielen Plattformen verwendet 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 Benutzerbasis als beispielsweise Boost. Wenn Sie beispielsweise eine Frage zum Stapelüberlauf stellen, sind Ihre Chancen, eine Antwort zu erhalten, geringer als bei Boost

• Es bleibt abzuwarten, wie gut es in den neuen C ++ - Standard integriert wird. Sie wissen sicher, dass es für Boost kein Problem sein wird.

Ich habe ACE nie benutzt, daher kann ich es nicht wirklich kommentieren. Nach allem, was ich gehört habe, finden die Leute POCO moderner und einfacher zu bedienen 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: ActiveMethodund Activity, und ThreadPool. IMO POCO-Threads sind ebenfalls 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 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 ist nicht in Boost.

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

Ich möchte wirklich für Doug Schmidt stimmen und all seine 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 denke, 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 wesentlich. Ein kurzer Blick auf meinen Code zeigt shared_ptr, program_options, regex, bind, serialization, foreach, property_tree, Dateisystem, Tokenizer, verschiedene Iterator-Erweiterungen, Alogrithmus und mem_fn. Dies sind meistens Low-Level-Funktionen, die eigentlich im Compiler vorhanden 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 Dienstprogrammklassen, 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 libxml2 mich zum letzten Mal irritierte. Es gibt andere Klassen, die ich verwenden könnte, aber noch nicht ausprobiert habe, z. B. Data :: MySQL (ich bin mit mysql ++ zufrieden) und Net :: HTTP (ich bin mit libCURL zufrieden). Ich werde den Rest von Poco irgendwann ausprobieren, aber das hat derzeit keine Priorität.

Viele POCO-Benutzer geben an, es neben Boost zu verwenden, sodass es offensichtlich ist, dass es in beiden Projekten Anreize für Menschen gibt. Boost ist eine Sammlung hochwertiger Bibliotheken. Aber es ist kein Rahmen. ACE habe ich in der Vergangenheit verwendet und das Design hat mir nicht gefallen. Darüber hinaus hat die 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 einer umfassenden Bibliotheksverfügbarkeit, die an die mit Java oder C # erinnert. Zu diesem Zeitpunkt ist das asynchronste E / A das akuteste Fehlen von POCO.

Ich habe ACE für eine sehr leistungsstarke Datenerfassungsanwendung mit Echtzeitbeschränkungen verwendet. Ein einzelner Thread verarbeitet E / A von über 30 TCP / IC-Socket-Verbindungen und einer seriellen Schnittstelle. Der Code läuft sowohl unter 32- als auch unter 64-Bit-Linux. Einige der vielen ACE-Klassen, die ich verwendet habe, 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 ein erheblicher Aufwand erforderlich, um 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 normalerweise 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 habe kürzlich einen neuen Job bekommen und arbeite an einem Projekt, das ACE und TAO verwendet. Was ich sagen kann ist, dass ACE und TAO arbeiten und ihre Aufgaben vollständig erfüllen. Aber die Gesamtorganisation und das Design der Bibliotheken sind ziemlich entmutigend ...

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

Darüber hinaus bieten viele Klassennamen von ACE auch keine nützlichen Informationen. Oder können Sie erraten, welche Klassen mögen ACE_Dev_Poll_Reactor_Notifyoder für ACE_Proactor_Handle_Timeout_Upcallwelche verwendet werden können?

Außerdem fehlt die Dokumentation von ACE wirklich. Wenn Sie ACE nicht auf die harte Tour lernen möchten (es ist wirklich schwer ohne eine gute Dokumentation ..), würde ich die Verwendung von ACE NICHT empfehlen, es sei denn, Sie benötigen TAO für CORBA wirklich , wenn Sie brauche kein CORBA, mach weiter und benutze einige moderne Bibliotheken.

Die ACE-Socket-Bibliotheken sind solide. Wenn Sie versuchen, eine Standardimplementierung von Sockets zu portieren, können Sie nichts falsch machen. Der ACE-Code hält an einem starren Entwicklungsparadigma fest. Die höheren Konstruktionen sind etwas verwirrend in der Verwendung. Das starre Paradigma verursacht einige Anomolien mit Ausnahmebehandlung. Es gibt oder gab Situationen, in denen Zeichenfolgenwertpaare an eine Ausnahme übergeben werden, wobei eines der Paare null ist, was zu einem Ausnahmefall in der Ausnahme führt, der Sie verwirrt. Die Tiefe der Klassenschichtung ist beim Debuggen mühsam. Ich habe die anderen Bibliotheken noch nie ausprobiert und kann daher keinen intelligenten Kommentar abgeben.

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

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

Boost ist großartig, ich habe nur gute Dinge über POCO gehört (aber nie verwendet), aber ich mag ACE nicht und würde es in Zukunft vermeiden. Obwohl Sie Fans von ACE finden, werden Sie auch viele Kritiker finden, die Sie mit Boost oder Poco (IME) nicht bekommen, was mir ein klares Signal sendet, dass ACE nicht das beste Werkzeug ist (obwohl es das tut, was es sagt auf der Dose).

Von diesen habe ich nur wirklich ACE verwendet. ACE ist ein großartiges 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 viel Literatur und kommerzielle Unterstützung.

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, scheint es, als würden sie ein System anstreben, das auf eingebetteten Systemen ausgeführt werden kann. Ich gehe also davon aus, dass es viel leichter verwendet werden kann. Ich kann es jetzt versuchen: P.

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

Aufgrund meiner Erfahrung mit dem Schreiben von tragbarem Win32 / Linux-Servercode (über 15 Jahre) finde ich Boost / ACE persönlich unnötig aufgebläht und führe Wartungsrisiken (auch als "DLL-Hölle" bekannt) für den geringen Vorteil ein, den sie bieten.

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

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