ACE vs Boost vs POCO
Je travaille avec les Boost C++ Libraries depuis un certain temps. J'adore le Boost bibliothèque Asio C++ pour la programmation réseau. Cependant, j'ai été présenté à deux autres bibliothèques: POCO et Adaptive Communication Environment (ACE) framework . J'aimerais connaître le bien et le mal de chacun.
Comme l'a dit rdbound, Boost a un statut "near STL". Donc, si vous n'avez pas besoin d'une autre bibliothèque, restez sur Boost. Cependant, j'utilise POCO car cela présente certains avantages pour ma situation. Les bonnes choses à propos de POCO IMO:
Meilleure bibliothèque de threads, en particulier une implémentation de méthode active. J'aime aussi le fait que vous pouvez définir la priorité des threads.
Bibliothèque réseau plus complète que
boost::asio. Toutefoisboost::asioest aussi une très bonne bibliothèque.Inclut des fonctionnalités qui ne sont pas dans Boost, comme XML et l'interface de base de données pour n'en nommer que quelques-unes.
Il est plus intégré en tant que bibliothèque que Boost.
Il a un code C++ propre, moderne et compréhensible. Je trouve cela beaucoup plus facile à comprendre que la plupart des bibliothèques Boost (mais je ne suis pas un expert en programmation de modèles :)).
Il peut être utilisé sur de nombreuses plateformes.
Certains inconvénients de POCO sont:
Il a une documentation limitée. Cela est quelque peu compensé par le fait que la source est facile à comprendre.
Il a une communauté et une base d'utilisateurs beaucoup plus petite que, par exemple, Boost. Donc, si vous posez une question sur Stack Overflow par exemple, vos chances d'obtenir une réponse sont moindres que pour Boost
Il reste à voir dans quelle mesure il sera intégré au nouveau standard C++. Vous savez avec certitude que ce ne sera pas un problème pour Boost.
Je n'ai jamais utilisé ACE, donc je ne peux pas vraiment en parler. D'après ce que j'ai entendu, les gens trouvent POCO plus moderne et plus facile à utiliser que ACE.
Quelques réponses aux commentaires de Rahul:
Je ne connais pas polyvalent et avancé. La bibliothèque de threads POCO fournit des fonctionnalités qui ne sont pas dans Boost:
ActiveMethodetActivityetThreadPool. Les fils IMO POCO sont également plus faciles à utiliser et à comprendre, mais c'est une question subjective.La bibliothèque réseau POCO prend également en charge les protocoles de niveau supérieur tels que HTTP et SSL (éventuellement également dans
boost::asio, mais je ne suis pas sûr?).C'est suffisant.
La bibliothèque intégrée a l'avantage d'avoir un codage, une documentation et une apparence et une convivialité généraux.
Être multiplateforme est une caractéristique importante de POCO, ce n'est pas un avantage par rapport à Boost.
Encore une fois, vous ne devriez probablement considérer POCO que s'il fournit certaines fonctionnalités dont vous avez besoin et qui ne sont pas dans Boost.
J'ai utilisé les trois donc voici mes 0,02 $.
Je veux vraiment voter pour Doug Schmidt et respecter tout le travail qu'il a fait, mais pour être honnête, je trouve ACE légèrement bogué et difficile à utiliser. Je pense que la bibliothèque a besoin d'un redémarrage. C'est difficile à dire, mais je préfère ACE pour l'instant, sauf s'il existe une raison impérieuse d'utiliser TAO, ou si vous avez besoin d'une seule base de code pour exécuter C++ sur les variantes Unix et Windows. TAO est fabuleux pour un certain nombre de problèmes difficiles, mais la courbe d'apprentissage est intense, et il y a une raison pour laquelle CORBA a un certain nombre de critiques. Je suppose que faites vos devoirs avant de décider d'utiliser l'un ou l'autre.
Si vous codez en C++, boost est dans mon esprit une évidence. J'utilise un certain nombre de bibliothèques de bas niveau et les trouve essentielles. Un rapide grep de mon code révèle shared_ptr, program_options, regex, bind, serialization, foreach, property_tree, filesystem, tokenizer, diverses itérateur iterator, alogrithm et mem_fn. Ce sont principalement des fonctionnalités de bas niveau qui devraient vraiment être dans le compilateur. Certaines bibliothèques de boost sont très génériques; il peut être utile de les amener à faire ce que vous voulez, mais cela en vaut la peine.
Poco est une collection de classes d'utilitaires qui fournissent des fonctionnalités pour certaines tâches courantes très concrètes. Je trouve que les bibliothèques sont bien écrites et intuitives. Je n'ai pas besoin de passer beaucoup de temps à étudier la documentation ou à écrire des programmes de tests stupides. J'utilise actuellement Logger, XML, Zip et Net/SMTP. J'ai commencé à utiliser Poco lorsque libxml2 m'a irrité pour la dernière fois. Il y a d'autres classes que je pourrais utiliser mais que je n'ai pas essayées, par ex. Data :: MySQL (je suis content de mysql ++) et Net :: HTTP (je suis content de libCURL). Je vais éventuellement essayer le reste de Poco, mais ce n'est pas une priorité à ce stade.
De nombreux utilisateurs de POCO déclarent l'utiliser avec Boost, il est donc évident qu'il existe des incitations pour les personnes dans les deux projets. Boost est une collection de bibliothèques de haute qualité. Mais ce n'est pas un cadre. Quant à ACE, je l'ai utilisé dans le passé et je n'ai pas aimé le design. De plus, sa prise en charge des anciens compilateurs non conformes a façonné la base de code de manière laide.
Ce qui distingue vraiment POCO est une conception qui évolue et une interface avec une disponibilité de bibliothèque riche qui rappelle celles que l'on obtient avec Java ou C #. À l'heure actuelle, la chose la plus cruellement manquante de POCO est une E/S asynchrone.
J'ai utilisé ACE pour une application d'acquisition de données à très hautes performances avec des contraintes de temps réel. Un seul thread gère les E/S de plus de trente connexions socket TCP/IC et un port série. Le code fonctionne sur Linux 32 et 64 bits. Quelques-unes des nombreuses classes ACE que j'ai utilisées sont ACE_Reactor, ACE_Time_Value, ACE_Svc_Handler, ACE_Message_Queue, ACE_Connector. L'ACE a été un facteur clé du succès de notre projet. Il faut un effort important pour comprendre comment utiliser les classes ACE. J'ai tous les livres écrits sur ACE. Chaque fois que j'ai dû étendre les fonctionnalités de notre système, cela prend généralement un certain temps pour étudier ce qu'il faut faire, puis la quantité de code requise est très faible. J'ai trouvé ACE très fiable. J'utilise également un peu de code de Boost. Je ne vois pas la même fonctionnalité dans Boost. J'utiliserais l'une ou les deux bibliothèques.
J'ai récemment obtenu un nouvel emploi et je travaille sur un projet qui utilise ACE et TAO. Eh bien, ce que je peux dire, c'est que ACE et TAO travaillent et accomplissent pleinement leurs tâches. Mais l'organisation et la conception générales des bibliothèques sont assez décourageantes ...
Par exemple, la partie principale d'ACE se compose de centaines de classes commençant par "ACE_". Il semble qu'ils ignorent les espaces de noms depuis des décennies.
De plus, de nombreux noms de classe ACE ne fournissent pas non plus d'informations utiles. Ou pouvez-vous deviner quelles classes comme ACE_Dev_Poll_Reactor_Notify ou ACE_Proactor_Handle_Timeout_Upcall peut être utilisé pour?
De plus, la documentation d'ACE fait vraiment défaut, donc à moins que vous ne vouliez apprendre ACE à la dure (c'est vraiment difficile sans une bonne documentation ..), je ne recommanderais PAS d'utiliser ACE, sauf si vous en avez vraiment besoin TAO pour CORBA , Si vous n'avez pas besoin de CORBA, allez-y et utilisez des bibliothèques modernes ..
Les bibliothèques de sockets ACE sont solides. Si vous essayez de porter une implémentation standard de sockets, vous ne pouvez pas vous tromper. Le code ACE s'en tient à un paradigme de développement rigide. Les structures de niveau supérieur sont un peu déroutantes à utiliser. Le paradigme rigide provoque certaines anomalies avec une gestion des exceptions. Il existe ou existait des situations dans lesquelles des paires de valeurs de chaîne passées dans une exception, l'une des paires étant nulle, provoquant une exception dans laquelle vous enlèverait. La profondeur de la superposition de classes est fastidieuse lors du débogage. Je n'ai jamais essayé les autres bibliothèques, je ne peux donc pas faire de commentaire intelligent.
Boost bénéficie d'un statut "near STL" en raison du nombre de membres du comité des normes C++ qui sont également des développeurs Boost. Poco et ACE ne bénéficient pas de cet avantage, et d'après mon expérience anecdotique, Boost est plus répandu.
Cependant, POCO dans son ensemble est plus centré sur des choses de type réseau. Je m'en tiens à Boost, donc je ne peux pas vous y aider, mais l'avantage de Boost est son utilisation (relativement) répandue.
Boost est super, je n'ai entendu que de bonnes choses à propos de POCO (mais jamais utilisé) mais je n'aime pas ACE et je l'éviterais à l'avenir. Bien que vous trouverez des fans d'ACE, vous trouverez également de nombreux détracteurs que vous n'avez pas tendance à obtenir avec boost ou poco (IME), pour moi, cela envoie un signal clair qu'ACE n'est pas le meilleur outil (bien qu'il fasse ce qu'il dit) sur l'étain).
Parmi ceux-là, je n'ai jamais vraiment utilisé ACE. ACE est un excellent cadre pour les applications de mise en réseau d'entreprise multiplateforme. Il est extrêmement polyvalent et évolutif et est livré avec TAO et JAWS pour un développement rapide et puissant d'applications ORB et/ou Web.
Se familiariser avec cela peut être quelque peu intimidant, mais il y a beaucoup de littérature à ce sujet et un support commercial disponible.
C'est un peu lourd cependant, donc pour les applications à plus petite échelle, cela peut être un peu exagéré. En lisant le résumé de POCO, on dirait qu'ils visent un système qui peut être exécuté sur des systèmes embarqués, donc je suppose qu'il peut être utilisé de manière beaucoup plus légère. Je peux maintenant lui donner un tourbillon: P
Je pense que c'est vraiment une question d'opinion, il n'y a guère de bonne réponse.
Dans mon expérience avec l'écriture de code de serveur portable Win32/Linux (15+ ans), je trouve personnellement boost/ACE inutilement gonflé et présente des risques de maintenance (autrement connu comme "dll hell") pour le petit avantage qu'ils donnent.
ACE semble également être horriblement dépassé, c'est une "bibliothèque c ++" écrite par des "programmeurs c" dans les années 90 et cela se voit vraiment à mon avis. Il se trouve que, en ce moment, je suis en train de repenser le projet écrit avec Pico, il me semble qu'il suit complètement l'idée ACE, mais en termes plus contemporains, pas beaucoup mieux.
Dans tous les cas, pour des communications serveur hautes performances, efficaces et élégantes, il vaut mieux ne pas en utiliser.