ACE vs Boost vs POCO [fermé]

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 buggé et difficile à utiliser. Je pense que cette bibliothèque a besoin d'un redémarrage. C'est difficile à dire, mais je me méfierais D'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 juste faire vos devoirs avant de prendre la décision d'utiliser soit.

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 grep rapide de mon code révèle shared_ptr, program_options, regex, bind, sérialisation, foreach, property_tree, filesystem, tokenizer, diverses extensions iterator, alogrithm et mem_fn. Ceux-ci sont pour la plupart de bas niveau fonctionnalité qui devrait vraiment être dans le compilateur. Certaines bibliothèques boost sont très génériques; cela peut être un travail pour 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 communes 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 quand 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 content de mysql++) et Net::HTTP (je suis content de libCURL). Je vais essayer le reste de Poco éventuellement, mais ce n'est pas une priorité à ce stade.

De nombreux utilisateurs de POCO rapportent l'utiliser aux côtés de 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 il n'est pas un cadre. Quant à ACE, Je l'ai utilisé dans le passé et n'a pas aimé la conception. De plus, son support pour les anciens compilateurs non conformes a façonné la base de code d'une manière laide.

Ce qui distingue vraiment POCO est un design qui évolue et une interface avec une riche disponibilité de bibliothèque réminiscence de ceux que L'on obtient avec Java ou C#. En ce moment, la chose qui manque le plus de POCO est asynchrone IO.

J'ai utilisé ACE pour une application d'acquisition de données très performante avec des contraintes en temps réel. Un seul thread gère les E / S de plus de trente connexions de 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. ACE a été un facteur clé de la réussite de notre projet. Il faut un effort important pour comprendre comment utiliser L'ACE classe. J'ai tous les livres écrits sur ACE. Chaque fois que j'ai dû étendre la fonctionnalité de notre système, il faut généralement un certain temps pour étudier ce qu'il faut faire et la quantité de code requise est très faible. J'ai trouvé ACE à très fiable. J'utilise aussi un peu de code de Boost. Je ne vois pas la même fonctionnalité dans Boost. Je voudrais utiliser une ou les deux bibliothèques.

J'ai récemment obtenu un nouvel emploi et travailler sur un projet qui utilise ACE et TAO. 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 intimidantes...

Par exemple, la partie principale de 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 classes D'ACE ne fournissent pas non plus d'informations utiles. Ou pouvez-vous devinez pour quelles classes comme ACE_Dev_Poll_Reactor_Notify ou ACE_Proactor_Handle_Timeout_Upcall peuvent être utilisées?

Additonally, 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 avez vraiment besoin de 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 constructions de niveau supérieur sont un peu déroutantes à utiliser. Le paradigme rigide provoque des anomolies avec la gestion des exceptions. Il y a ou il y a eu des situations où des paires de valeurs de chaîne sont passées dans une exception avec l'une des paires étant null provoque une exception dans l'exception qui vous boggle. La profondeur de la superposition de classe est fastidieuse lors du débogage. Je n'ai jamais essayé les autres bibliothèques, donc je ne peux pas faire un commentaire intelligent.

Boost bénéficie d'un statut" proche de STL " en raison du nombre de personnes 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 de mon expérience anecdotique Boost est plus répandue.

Cependant, POCO dans son ensemble est plus centré sur les éléments de type réseau. Je m'en tiens à Boost donc je ne peux pas vous aider là-bas, mais le plus pour 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é) mais je n'aime pas ACE et je l'éviterais à l'avenir. Bien que vous trouviez 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 le tin).

Parmi ceux que je n'ai jamais vraiment utilisé ACE. ACE est un excellent cadre pour les applications de réseau d'entreprise multi-plateforme. 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 mettre au courant peut être un peu intimidant, mais il y a beaucoup de littérature à ce sujet, et le soutien commercial disponible.

C'est un peu lourd, 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 Win32/Linux portable (années 15+), je trouve personnellement boost / ACE inutilement gonflé et introduit des risques de maintenance (autrement connu sous le nom de "dll hell") pour le peu d'avantage qu'ils donnent.

ACE semble aussi être horriblement obsolète, c'est une "bibliothèque C++" écrite par des "programmeurs c" dans les 90-s et cela se voit vraiment à mon avis. Il arrive, en ce moment je Je réingénierie 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 à cela.

Dans tous les cas, pour des communications de serveur hautes performances, efficaces et élégantes, il serait peut-être préférable de ne pas les utiliser.