ACE vs Boost vs POCO

Question

J'ai travaillé avec le Bibliothèques Boost C++ depuis un certain temps. J'aime absolument le Boost Bibliothèque Asio C++ pour la programmation du réseau. Cependant, on m'a présenté deux autres bibliothèques : POCO y Cadre de l'environnement de communication adaptatif (ACE) . J'aimerais connaître les avantages et les inconvénients de chacun.

Answer 1

Comme l'a dit rdbound, Boost a un statut "near STL". Donc si vous ne besoin de une autre bibliothèque, tenez-vous en à Boost. Cependant, j'utilise POCO parce qu'il présente certains avantages pour ma situation. Les bons côtés de la POCO IMO :

• Meilleure bibliothèque de threads, notamment une implémentation de la méthode active. J'aime aussi le fait que l'on puisse définir la priorité des threads.

• Bibliothèque de réseau plus complète que boost::asio . Cependant boost::asio est également 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 en nommer quelques-unes.

• Elle est plus intégrée comme une bibliothèque unique que Boost.

• Son code C++ est propre, moderne et compréhensible. Je le trouve beaucoup plus facile à comprendre que la plupart des bibliothèques Boost (mais je ne suis pas un expert en programmation de templates :)).

• Il peut être utilisé sur de nombreuses plateformes.

Les inconvénients de la POCO sont les suivants :

• Sa documentation est limitée. Ceci est quelque peu compensé par le fait que la source est facile à comprendre.

• Sa communauté et sa base d'utilisateurs sont beaucoup plus petites que celles de Boost, par exemple. Ainsi, 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é à la nouvelle norme C++. Il est certain que ce ne sera pas un problème pour Boost.

Je n'ai jamais utilisé ACE, donc je ne peux pas vraiment faire de commentaires à ce sujet. 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 :

1. Je ne sais pas pour la polyvalence et l'avancée. La bibliothèque POCO thread fournit certaines fonctionnalités qui ne sont pas dans Boost : ActiveMethod y Activity y ThreadPool . Les fils POCO sont également plus faciles à utiliser et à comprendre, mais c'est une question subjective.

2. La bibliothèque réseau POCO prend également en charge les protocoles de plus haut niveau tels que HTTP et SSL (éventuellement aussi en boost::asio mais je ne suis pas sûr ).

3. C'est juste.

4. Une bibliothèque intégrée présente l'avantage d'avoir un codage, une documentation et un "look and feel" général cohérents.

5. Le fait d'être multiplateforme est une caractéristique importante de POCO, mais ce n'est pas un avantage par rapport à Boost.

Encore une fois, vous ne devriez probablement envisager la POCO que si elle offre une fonctionnalité dont vous avez besoin et qui n'est pas dans Boost.

Answer 2

J'ai utilisé les trois, alors voici mon point de vue.

J'ai vraiment envie de voter pour Doug Schmidt et je respecte 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 cette bibliothèque a besoin d'un reboot. C'est difficile à dire, mais je m'éloignerais d'ACE pour le moment, à moins qu'il n'y ait une raison impérieuse d'utiliser TAO, ou que vous ayez besoin d'une base de code unique pour faire tourner 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 pense qu'il faut faire ses devoirs avant de prendre la décision d'utiliser l'un ou l'autre.

Si vous codez en C++, Boost est à mon avis une évidence. J'utilise un certain nombre de bibliothèques de bas niveau et je les trouve essentielles. Une recherche rapide dans mon code révèle shared_ptr, program_options, regex, bind, serialization, foreach, property_tree, filesystem, tokenizer, diverses extensions d'itérateurs, alogrithm, et mem_fn. Il s'agit principalement de fonctionnalités de bas niveau qui devraient vraiment se trouver dans le compilateur. Certaines bibliothèques boost sont très génériques ; il peut être difficile de leur faire faire ce que vous voulez, mais cela en vaut la peine.

Poco est une collection de classes utilitaires qui fournissent des fonctionnalités pour certaines tâches communes 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 test 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 exemple Data::MySQL (je suis heureux avec mysql++) et Net::HTTP (je suis heureux avec libCURL). J'essaierai le reste de Poco éventuellement, mais ce n'est pas une priorité pour le moment.

Answer 3

De nombreux utilisateurs de POCO déclarent l'utiliser en même temps que Boost, il est donc évident qu'il y a des avantages pour les gens dans les deux projets. Boost est une collection de bibliothèques de haute qualité. Mais ce n'est pas un framework. Quant à ACE, je l'ai utilisé dans le passé et je n'ai pas aimé son design. De plus, sa prise en charge d'anciens compilateurs non conformes a façonné la base de code d'une manière peu glorieuse.

Ce qui distingue vraiment POCO, c'est une conception évolutive et une interface dotée d'une riche bibliothèque disponible qui rappelle celle de Java ou de C#. Pour l'instant, la chose qui manque le plus à POCO est l'entrée-sortie asynchrone.

Answer 4

J'ai utilisé ACE pour une application d'acquisition de données à très haute performance avec des contraintes de temps réel. Un seul thread gère les entrées/sorties de plus de trente connexions de socket TCP/IC et d'un port série. Le code fonctionne sur Linux 32 et 64 bits. Parmi les nombreuses classes ACE que j'ai utilisées, citons ACE_Reactor, ACE_Time_Value, ACE_Svc_Handler, ACE_Message_Queueue, ACE_Connector. ACE a été un facteur clé de la réussite de notre projet. Il faut faire un effort considérable pour comprendre comment utiliser les classes ACE. J'ai tous les livres écrits sur ACE. Chaque fois que j'ai eu à étendre la fonctionnalité de notre système, il m'a fallu un certain temps pour étudier ce qu'il fallait faire, puis la quantité de code requise a été très faible. J'ai trouvé ACE très fiable. J'utilise également un peu de code de Boost. Je ne vois pas les mêmes fonctionnalités dans Boost. J'utiliserais l'une ou l'autre ou les deux bibliothèques.

Answer 5

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 fonctionnent et accomplissent pleinement leurs tâches. Mais l'organisation générale et la conception des bibliothèques sont assez déconcertantes...

Par exemple, la partie principale de ACE est constituée de centaines de classes commençant par "ACE_". On dirait qu'ils ont ignoré les espaces de noms pendant des décennies.

De plus, de nombreux noms de classes de ACE ne fournissent pas non plus d'informations utiles. Pouvez-vous deviner ce que sont des classes comme ACE_Dev_Poll_Reactor_Notify o ACE_Proactor_Handle_Timeout_Upcall peut être utilisé ?

De plus, la documentation de ACE est vraiment insuffisante, 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, à moins que vous ayez vraiment besoin de TAO pour CORBA Si vous n'avez pas besoin de CORBA, allez-y et utilisez des bibliothèques modernes