ACE vs vs Boost POCO [fermé]

https://stackoverflow.com/questions/992069

13-09-2019
|

Question

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

La solution

Comme dit rdbound, Boost a un statut "près de STL". Donc, si vous ne le faites pas besoin une autre bibliothèque, bâton Boost. Cependant, j'utilise POCO parce qu'il a quelques avantages pour ma situation. Les bonnes choses à propos de Poco OMI:

Une meilleure bibliothèque de threads, en particulier une mise en œuvre de la méthode active. Je aime aussi le fait que vous pouvez définir la priorité de fil.
plus complète bibliothèque réseau que boost::asio. Cependant boost::asio est aussi une très bonne bibliothèque.
Comprend des fonctionnalités qui ne sont pas dans Boost, comme l'interface XML et base de données pour ne citer que quelques-uns.
Il est plus intégré une bibliothèque que Boost.
Il est propre, le code moderne et compréhensible C ++. Je trouve beaucoup plus facile à comprendre que la plupart des bibliothèques Boost (mais je ne suis pas un expert en programmation de modèle:))
Il peut être utilisé sur beaucoup de plates-formes.

Quelques inconvénients de POCO sont:

Il a limité la documentation. Ce quelque peu compensé par le fait que la source est facile à comprendre.
Il a une base communautaire et l'utilisateur beaucoup plus faible 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 à quel point il sera intégré à la nouvelle norme C ++. Vous savez bien sûr que ce ne sera pas un problème pour Boost.

Je ne ai jamais utilisé ACE, donc je ne peux pas vraiment commenter. D'après ce que je l'ai entendu, les gens trouvent POCO plus moderne et plus facile à utiliser que ACE.

Quelques réponses aux commentaires par Rahul:

Je ne sais pas polyvalent et avancé. La bibliothèque de threads POCO fournit des fonctionnalités qui ne sont pas dans Boost: ActiveMethod et Activity et ThreadPool. fils de l'OMI POCO sont également plus faciles à utiliser et à comprendre, mais cela est une question subjective.
bibliothèque réseau POCO fournit également un soutien pour les protocoles de niveau supérieur comme HTTP et SSL (peut-être aussi dans boost::asio, mais je ne suis pas sûr?).
est juste.
Bibliothèque intégrée présente l'avantage d'avoir un codage cohérent, la documentation et "look and feel" général.
Être multi-plateforme est une caractéristique importante de POCO, ce n'est pas un avantage par rapport à Boost.

Encore une fois, vous devriez probablement considérer que POCO si elle fournit des fonctionnalités dont vous avez besoin et ce n'est pas dans Boost.

Autres conseils

Je l'ai utilisé trois donc 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 buggy et difficile à utiliser. Je pense que la bibliothèque a besoin d'un redémarrage. Il est difficile de dire cela, mais je serais timide loin de ACE pour l'instant à moins d'une raison impérieuse d'utiliser TAO, ou vous avez besoin d'une seule base de code pour exécuter C ++ sur les deux 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 CORBA a un certain nombre de critiques. Je suppose que fais juste vos devoirs avant de prendre une décision d'utiliser soit.

Si vous codez en C ++, boost est dans mon esprit un doux euphémisme. J'utilise un certain nombre de bibliothèques de bas niveau et les trouve essentiel. Un grep rapide de mon code, révèle shared_ptr program_options, regex, se lient, sérialisation, foreach, property_tree, système de fichiers, tokenizer, diverses extensions iterator, alogrithm et mem_fn. Ceux-ci sont pour la plupart des fonctionnalités de bas niveau qui devrait vraiment être dans le compilateur. Certaines bibliothèques Boost sont très génériques; il peut être un travail pour les amener à faire ce que vous voulez, mais il 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 écrits et intuitive. Je n'ai pas passer beaucoup de temps à étudier la documentation ou l'écriture de programmes de test stupides. J'utilise actuellement Logger, XML, Zip et Net / SMTP. Je commencé à utiliser Poco quand libxml2 m'a irrité pour la dernière fois. Il y a d'autres classes que je pourrais utiliser, mais ne l'ai pas essayé, par exemple :: données MySQL (je suis heureux avec MySQL ++) et Net :: HTTP (je suis content de libcURL). Je vais essayer le reste de Poco finalement, mais ce n'est pas une priorité à ce stade.

De nombreux utilisateurs POCO avouent en consommer à côté Boost, il est donc évident qu'il ya 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. En ce qui concerne ACE, je l'ai utilisé dans le passé et ne pas comme la conception. En outre, son support pour anciens compilateurs non conformes a façonné le code de base d'une manière laid.

Ce qui distingue vraiment POCO est une conception que les échelles et une interface avec une bibliothèque riche disponibilité rappelle ceux que l'on obtient avec Java ou C #. A cette époque, la chose la plus aiguë manque de POCO est asynchrone IO.

Je l'ai utilisé ACE pour une performance très élevée application d'acquisition de données avec des contraintes de temps réel. Un seul poignées fil E / S de plus de trente connexions socket TCP / IC et un port série. Le code fonctionne aussi bien sur 32 et 64 bits Linux. Quelques-unes des nombreuses classes d'ACE j'ai utilisé sont les 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 ne faut un effort important pour comprendre comment utiliser les classes de l'ECA. J'ai tous les livres écrits sur ACE. Chaque fois que j'ai dû étendre les fonctionnalités de notre système, il prend généralement un certain temps pour étudier ce qu'il faut faire et la quantité de code nécessaire est très faible. J'ai trouvé ACE très fiable. Je l'utilise aussi un peu de code de Boost. Je ne vois pas la même fonctionnalité Boost. J'utiliser ou les deux bibliothèques.

J'ai récemment obtenu un emploi et de travailler sur un projet qui utilise ACE et TAO. Eh bien, ce que je peux dire est que l'ACE et le travail TAO et pleinement accomplir leurs tâches. Mais l'organisation générale et la conception des bibliothèques sont assez intimidante ...

Par exemple, la partie principale de l'ACE se compose de centaines de classes commençant par « ACE_ ». On dirait qu'ils ont ignoré namespaces depuis des décennies.

En outre, un grand nombre de noms de classe d'ACE ne fournissent pas d'informations utiles non plus. Ou pouvez-vous deviner ce que les classes comme ACE_Dev_Poll_Reactor_Notify ou ACE_Proactor_Handle_Timeout_Upcall peuvent être utilisés pour?

Additonally, la documentation d'ACE est vraiment défaut, sauf si vous voulez apprendre à la dure ACE (il est vraiment difficile sans une bonne documentation ..), je ne vous recommandons d'utiliser ACE, sauf si vous avez vraiment besoin TAO CORBA , Si vous n'avez pas besoin CORBA, allez-y et utiliser des bibliothèques modernes ..

Les bibliothèques Prise de ACE sont solides. Si vous essayez de le port d'une implémentation standard de prises vous ne pouvez pas vous tromper. Le code ACE tient à un paradigme de développement rigide. Les contructs de niveau supérieur sont un peu déroutant à utiliser. Le paradigme rigide provoque des anomalies avec la gestion des exceptions. Il y a ou utilisés pour des situations où les paires de valeur de chaîne étant passée dans une exception avec l'un des deux étant une cause nul jet d'exception dans l'exception qui vous époustoufler. La profondeur de la stratification de classe est fastidieuse lors du débogage. Je ne l'ai jamais essayé les autres bibliothèques ne peut donc pas faire un commentaire intelligent.

Boost jouit d'un statut « près de STL » en raison du nombre de personnes au sein du comité des normes C ++ qui sont également les développeurs Boost. Poco et ACE ne bénéficient pas de cette prestation, et de mon expérience anecdotique Boost est plus répandue.

Cependant, POCO dans son ensemble est plus centré autour des choses de type réseau. Je tiens à Boost donc je ne peux pas vous aider là-bas, mais le plus pour Boost est sa (relativement) utilisation généralisée.

Boost est grand, je ne l'ai entendu de bonnes choses à propos de Poco (mais jamais utilisé) mais je n'aime pas ACE et éviterait à l'avenir. Bien que vous trouverez les fans de ACE, vous trouverez également de nombreux détracteurs que vous ne tendent pas à obtenir avec boost ou poco (IME) pour moi, qui envoie un signal clair que ACE n'est pas le meilleur outil (bien qu'il fait ce qu'il dit sur l'étain).

Hors de ceux que je ne l'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 le développement rapide, puissant de ORB et / ou des applications Web.

Mise à la vitesse avec elle peut être un peu intimidant, mais il y a beaucoup de littérature sur elle, et support commercial.

Il est un peu lourd, donc pour les applications à plus petite échelle, il peut être un peu d'un surpuissant. La lecture du résumé pour POCO on dirait qu'ils sont en vue d'un système qui peut être exécuté sur les systèmes embarqués Je suppose donc qu'il peut être utilisé d'une manière beaucoup plus léger. Je peux maintenant donner un tourbillon: P

Je pense qu'il est vraiment question d'une opinion, il n'y a guère bonne réponse.

Dans mon expérience avec l'écriture de code de serveur Win32 / Linux portable (15+ ans), je trouve personnellement boost / ACE inutilement pléthorique et présente des risques d'entretien (autrement connu comme « l'enfer dll ») pour le petit avantage qu'ils donnent.

ACE semble aussi être horriblement pas à jour, il est un « c ++ bibliothèque » écrit par « programmeurs c » dans le 90 s et il montre vraiment à mon avis. Il arrive donc, en ce moment je suis re-engineering du projet écrit avec Pico, il me semble qu'il suit tout à fait l'idée d'ACE, mais en termes plus contemporains, pas beaucoup mieux que.

Dans tous les cas de haute performance, les communications de serveur efficace, élégant, vous pourriez être mieux ne pas utiliser l'un d'eux.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow