ACE vs Boost vs POCO [fermé]

Je travaille avec les bibliothèques Boost C ++ depuis un certain temps. J'adore la bibliothèque Boost Asio C ++ pour la programmation réseau. Cependant, j'ai été présenté à deux autres bibliothèques: POCO et le framework Adaptive Communication Environment (ACE) . J'aimerais connaître le bien et le mal de chacun.

Comme l'a dit rdbound, Boost a un statut "proche de STL". Donc, si vous n'avez pas besoin d' une autre bibliothèque, restez fidèle à Boost. Cependant, j'utilise POCO car il 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 puissiez définir la priorité du thread.

• Bibliothèque réseau plus complète que boost::asio. Cependant, boost::asioc'est 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 plates-formes.

Certains inconvénients de POCO sont:

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

• Il a une communauté et une base d'utilisateurs beaucoup plus petites 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 le commenter. 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 sur polyvalent et avancé. La bibliothèque de threads POCO fournit des fonctionnalités qui ne sont pas dans Boost: ActiveMethodet Activity, et ThreadPool. Les fils IMO 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 niveau supérieur comme HTTP et SSL (peut-être aussi dans boost::asio, mais je ne suis pas sûr?).

3. C'est suffisant.

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

5. Ê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 envisager POCO que s'il fournit certaines fonctionnalités dont vous avez besoin et qui ne sont pas dans Boost.

J'ai utilisé les trois, alors voici mon 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 cette bibliothèque a besoin d'un redémarrage. C'est difficile à dire, mais j'hésiterais à utiliser ACE pour l'instant à moins qu'il n'y ait une raison impérieuse d'utiliser TAO, ou que vous ayez 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 qu'il suffit de faire vos devoirs avant de prendre la décision 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 je les trouve essentielles. Un grep rapide de mon code révèle shared_ptr, program_options, regex, bind, sérialisation, foreach, property_tree, système de fichiers, tokenizer, diverses extensions d'itérateur, alogrithme et mem_fn. Ce sont principalement des fonctionnalités de bas niveau qui devraient vraiment être dans le compilateur. Certaines bibliothèques boost sont très génériques; il peut être difficile de les amener à 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 courantes très concrètes. Je trouve que les bibliothèques sont bien écrites et intuitives. Je n'ai pas à 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 satisfait de mysql ++) et Net :: HTTP (je suis satisfait de libCURL). Je vais éventuellement essayer le reste de Poco, mais ce n'est pas une priorité pour le moment.

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 d'anciens compilateurs non conformes a façonné la base de code d'une manière moche.

Ce qui distingue vraiment POCO, c'est une conception évolutive et une interface avec une riche disponibilité de bibliothèque qui rappelle celles que l'on obtient avec Java ou C #. À l'heure actuelle, ce qui manque le plus à POCO est les E / S asynchrones.

J'ai utilisé ACE pour une application d'acquisition de données très performante avec des contraintes de temps réel. Un seul thread gère les E / S depuis plus de trente connexions socket TCP / IC et un port série. Le code fonctionne à la fois 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. ACE a été un facteur clé de la réussite 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, il faut 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'ai récemment obtenu un nouvel emploi et 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 globale et la conception 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 aient ignoré les espaces de noms pendant des décennies.

De plus, de nombreux noms de classe ACE ne fournissent pas non plus d'informations utiles. Ou pouvez-vous deviner ce que les classes aiment ACE_Dev_Poll_Reactor_Notifyou ACE_Proactor_Handle_Timeout_Upcallpeuvent être utilisées?

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 bonne documentation ..), je ne recommanderais PAS d'utiliser ACE, sauf si vous avez vraiment besoin de TAO pour CORBA , si vous pas besoin de CORBA, allez-y et utilisez des bibliothèques modernes.

Les bibliothèques de socket 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 constructions de niveau supérieur sont un peu déroutantes à utiliser. Le paradigme rigide provoque des anomalies avec la gestion des exceptions. Il y a ou a eu l'habitude d'être des situations où des paires de valeurs de chaîne passées dans une exception avec l'une des paires étant nul, provoquent une levée d'exception dans l'exception qui vous stupéfiera. La profondeur de la superposition des 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 «quasi STL» en raison du nombre de personnes au comité de normalisation 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 éléments de type réseau. Je m'en tiens à Boost donc je ne peux pas vous aider, mais le plus de Boost est son utilisation (relativement) répandue.

Boost est génial, je n'ai entendu que de bonnes choses à propos de POCO (mais jamais utilisées) 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 que ACE n'est pas le meilleur outil (bien qu'il fasse ce qu'il dit) sur l'étain).

Parmi ceux-ci, je n'ai jamais vraiment utilisé ACE. ACE est un excellent cadre pour les applications de réseau d'entreprise multiplateformes. 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 un peu intimidant, mais il existe une abondante 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, il semble 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 serveur portable Win32 / Linux (15+ ans), je trouve personnellement boost / ACE inutilement gonflé et introduit des risques de maintenance (autrement appelés "dll hell") pour le petit avantage qu'ils donnent.

ACE semble également être horriblement obsolète, 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 je suis en train de réorganiser 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 performantes, efficaces et élégantes, il vaut peut-être mieux ne pas utiliser l'un d'entre eux.