ACE vs Boost vs POCO [cerrada]

Question

He estado trabajando con el Boost C ++ bibliotecas desde hace bastante tiempo. Me encanta el refuerzo Asio C ++ para biblioteca de programación de la red. Sin embargo me presentaron a otras dos bibliotecas: POCO y Medio ambiente Comunicación adaptativo (ACE) marco. Me gustaría saber lo bueno y malo de cada uno.

Answer 1

Como dijo rdbound, Boost tiene un estado "cerca STL". Así que si no lo hace necesidad otra biblioteca, se adhieren a impulso. Sin embargo, yo uso POCO porque tiene algunas ventajas para mi situación. Las cosas buenas sobre Poco IMO:

• Una mejor librería de hilos, especialmente una implementación del método activo. También me gusta el hecho de que se puede establecer la prioridad de subprocesos.

• Más amplia biblioteca de red de boost::asio. Sin embargo boost::asio es también una muy buena biblioteca.

• Incluye la funcionalidad que no está en alza, como XML y bases de datos de interfaz para nombrar unos pocos.

• Es más integrada como una biblioteca de Boost.

• Tiene limpio, moderno y comprensible código C ++. Me resulta mucho más fácil de entender que la mayoría de las bibliotecas Boost (pero no soy un experto en programación de plantilla:))

.

• Puede ser utilizado en una gran cantidad de plataformas.

Algunas desventajas de POCO son:

• Se ha limitado la documentación. Este compensado en cierta medida por el hecho de que la fuente es fácil de entender.

• Tiene una base comunitaria y de usuario mucho menor que, por ejemplo, Boost. Así que si se pone una pregunta sobre desbordamiento de pila, por ejemplo, sus posibilidades de obtener una respuesta son menores que para Boost

• Queda por ver lo bien que se integrará con el nuevo estándar de C ++. Que sepa con certeza que no va a ser un problema para Boost.

nunca he usado ACE, así que no puedo opinar sobre ello. Por lo que he oído, la gente encuentra POCO más moderno y fácil de usar que la ECA.

Algunas respuestas a los comentarios de Rahul:

1. No sé acerca versátil y avanzado. La biblioteca hilo POCO proporciona algunas funcionalidades que no está en Boost: ActiveMethod y Activity, y ThreadPool. POCO hilos OMI también son más fáciles de usar y entender, pero esto es una cuestión subjetiva.

2. biblioteca de red POCO también proporciona soporte para protocolos de alto nivel como HTTP y SSL (posiblemente también en boost::asio, pero no estoy seguro?).

3. Justo lo suficiente.

4. biblioteca integrada tiene la ventaja de tener codificación coherente, la documentación y la "apariencia" en general.

5. Al ser multiplataforma es una característica importante de la POCO, esto no es una ventaja en relación con Boost.

Una vez más, se debe, probablemente, sólo tenemos en cuenta POCO si proporciona alguna funcionalidad que necesita y que no está en Boost.

Answer 2

He usado los tres Así que aquí está mi $ 0,02.

Realmente quiero votar por Doug Schmidt y respetar todo el trabajo que ha hecho, pero para ser honesto me parece ACE ligeramente buggy y difícil de usar. Creo que la biblioteca necesita un reinicio. Es difícil de decir esto, pero me asusta de ACE, por ahora, a menos que haya una razón de peso para utilizar TAO, o si necesita una única base de código para ejecutar C ++ en ambas variantes de Unix y Windows. TAO es fabuloso para una serie de problemas difíciles, pero la curva de aprendizaje es intensa, y hay una razón CORBA tiene un número de críticos. Supongo que acaba de hacer su tarea antes de tomar una decisión de utilizar.

Si está codificando en C ++, impulso está en mi mente una obviedad. Yo uso un número de las bibliotecas de bajo nivel y los encuentro esencial. Un grep rápida de mi código revela shared_ptr, program_options, expresiones regulares, se unen, la serialización, foreach, property_tree, sistema de ficheros, tokenizer, varias extensiones de iterador, alogrithm y mem_fn. Estos son en su mayoría funcionalidad de bajo nivel que realmente debería estar en el compilador. Algunas bibliotecas de impulso son muy genéricos; Puede ser un trabajo para conseguir que hagan lo que quieran, pero vale la pena.

Poco es un conjunto de clases de utilidad que proporcionan funcionalidad para algunas tareas comunes muy concretos. Encuentro las bibliotecas están bien escritos e intuitiva. No tengo que pasar mucho tiempo estudiando la documentación o la escritura de programas de prueba tontas. Actualmente estoy usando Logger, XML, código postal, y Net / SMTP. Empecé a usar cuando Poco libxml2 me irritaba por última vez. Hay otras clases que podría utilizar, pero no he probado, por ejemplo, Datos :: MySQL (estoy feliz con MySQL ++) y Net :: HTTP (estoy feliz con libcurl). Voy a tratar el resto de Poco tiempo, pero eso no es una prioridad en este momento.

Answer 3

Muchos usuarios POCO informe usando que junto Boost, por lo que es obvio que existen incentivos para que la gente en ambos proyectos. Boost es una colección de bibliotecas de alta calidad. Pero no es un marco. En cuanto a la ECA, lo he utilizado en el pasado y no le gustó el diseño. Además, su apoyo a los compiladores no conformes antiguos ha dado forma a la base de código de una manera fea.

Lo que realmente distingue POCO es un diseño que se adapta y una interfaz con la disponibilidad rica biblioteca recuerdan a las obtiene con Java o C # una. En este momento, lo más agudamente que carecen de POCO es S asíncrona.

Answer 4

He utilizado ACE para una aplicación de adquisición de datos muy alto rendimiento con limitaciones de tiempo real. Un solo hilo se encarga de I / O de más de treinta conexiones de socket TCP / IC y un puerto serie. El código se ejecuta en 32 y 64 bits de Linux. Algunas de las muchas clases de la ECA que he utilizado son el ACE_Reactor, ACE_Time_Value, ACE_Svc_Handler, ACE_Message_Queue, ACE_Connector. ACE fue un factor clave para el éxito de nuestro proyecto. Sin embargo, toma un esfuerzo importante para entender cómo usar las clases de la ECA. Tengo todos los libros escritos sobre ACE. Siempre que he tenido que ampliar la funcionalidad de nuestro sistema por lo general toma algún tiempo para estudiar qué hacer y luego la cantidad de código necesaria es muy pequeña. He encontrado a ACE muy fiable. También uso un poco de código de Boost. No veo la misma funcionalidad en Boost. Me gustaría utilizar una o ambas bibliotecas.

Answer 5

Hace poco recibí un nuevo trabajo y trabajar en un proyecto que utiliza ACE y TAO. Bueno, lo que puedo decir es, que ACE y el trabajo TAO y totalmente cumplir con sus tareas. Pero la organización general y el diseño de las bibliotecas son bastante desalentador ...

Por ejemplo, la parte principal de ACE consta de cientos de clases que comienzan con "ACE_". Parece que han ignorado durante décadas espacios de nombres.

Además, muchos de los nombres de las clases de la ECA no proporcionan información útil tampoco. O se puede adivinar lo que las clases como ACE_Dev_Poll_Reactor_Notify o ACE_Proactor_Handle_Timeout_Upcall se pueden utilizar para?

menaje, la documentación de la ECA está muy deficiente, por lo menos que desea aprender de la manera difícil ACE (que es muy difícil sin una buena documentación ..), yo no recomendaría el uso de la ECA, a menos que realmente necesita TAO para CORBA , Si usted no necesita CORBA, seguir adelante y utilizar algunas bibliotecas modernas ..

Answer 6

Las bibliotecas de socket ACE son sólidos. Si usted está tratando de puerto de una implementación estándar de tomas que no se puede ir mal. El código de la ECA se pega a un paradigma de desarrollo rígida. Los constructos de nivel superior son un poco confuso de usar. El paradigma rígida hace que algunas anomalías con el manejo de excepciones. Existen o se utilizan para darse situaciones en las parejas de valores de cadena que se transmiten en una excepción con uno de los dos siendo nula provoca un tiro excepción en la excepción que se aturdir. La profundidad de la estratificación clase es tedioso cuando la depuración. Nunca he probado las otras bibliotecas por lo que no puede hacer un comentario inteligente.

Answer 7

Boost goza de un estatus "cerca STL" debido al número de personas en el comité de estándares de C ++ que también están Boost desarrolladores. Poco y ACE no gozan de ese beneficio, y desde mi experiencia anecdótica de refuerzo es más generalizada.

Sin embargo, POCO como un todo está más centrada alrededor de la materia de tipo red. Me quedo con Boost, así que no puedo ayudar, pero la ventaja para su Boost es (relativamente) el uso generalizado.

Answer 8

Boost es grande, sólo he oído cosas buenas sobre Poco (pero nunca utilizado), pero no me gusta la ECA y evitaría en el futuro. Aunque encontrará fans de la ECA también puede encontrar muchos detractores que no tienden a conseguir con el impulso o poco (IME), para mí que envía una señal clara de que ACE no es la mejor herramienta (a pesar de que hace lo que dice en la lata).

Answer 9

De esos sólo he utilizado realmente ACE. ACE es un gran marco para aplicaciones de redes empresariales multiplataforma. Es muy versátil y escalable y viene con TAO y poderosa JAWS para el desarrollo rápido de aplicaciones basadas en Web ORB y / o.

en ponerse al día con ella puede ser algo desalentador, pero hay una gran cantidad de literatura sobre el mismo, y el apoyo comercial disponible.

Es un poco pesado, sin embargo, por lo que para aplicaciones de menor escala, puede ser un poco de una exageración. Leer el resumen del Poco suena como que están apuntando a un sistema que se puede ejecutar en sistemas embebidos así que estoy asumiendo que puede ser utilizado de una manera mucho más ligero. ahora yo pueda darle una turbina: P

Answer 10

Creo que es realmente importante de una opinión, apenas hay una respuesta correcta.

En mi experiencia con la escritura de código de servidor Win32 / Linux portátil (15 años), yo personalmente considero realce / ACE innecesariamente hinchado e introduce riesgos de mantenimiento (también conocida como "infierno DLL") para la pequeña ventaja que dan.

ACE también parece ser terriblemente anticuados, se trata de una "biblioteca de C ++", escrito por los programadores de "C" en el 90-s y realmente se demuestra en mi opinión. Se da la circunstancia, en este momento estoy reingeniería del proyecto escrito con Pico, me parece que se sigue por completo la idea de la ECA, pero en términos más contemporáneos, no es mucho mejor en eso.

En cualquier caso, para alto rendimiento, servidores, comunicaciones eficientes elegante que puede ser mejor no utilizar ninguno de ellos.