ACE vs Boost vs POCO [cerrado]

He estado trabajando con las bibliotecas Boost C ++ durante bastante tiempo. Me encanta la biblioteca Boost Asio C ++ para programación en red. Sin embargo, conocí otras dos bibliotecas: POCO y el marco de Adaptive Communication Environment (ACE) . Me gustaría saber lo bueno y lo malo de cada uno.

Como dijo rdbound, Boost tiene un estado "cerca de STL". Entonces, si no necesita otra biblioteca, apéguese a Boost. Sin embargo, utilizo POCO porque tiene algunas ventajas para mi situación. Las cosas buenas de POCO IMO:

• Mejor biblioteca de subprocesos, especialmente una implementación de método activo. También me gusta el hecho de que puedes establecer la prioridad del hilo.

• Biblioteca de red más completa que boost::asio. Sin embargo, boost::asiotambién es una biblioteca muy buena.

• Incluye funcionalidad que no está en Boost, como XML y la interfaz de base de datos, por nombrar algunas.

• Está más integrado como una biblioteca que Boost.

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

• Se puede utilizar en muchas plataformas.

Algunas desventajas de POCO son:

• Tiene documentación limitada. Esto se compensa un poco por el hecho de que la fuente es fácil de entender.

• Tiene una comunidad y una base de usuarios mucho más pequeña que, digamos, Boost. Entonces, si hace una pregunta en Stack Overflow, por ejemplo, sus posibilidades de obtener una respuesta son menores que para Boost

• Queda por ver qué tan bien se integrará con el nuevo estándar C ++. Tienes la certeza de que no será un problema para Boost.

Nunca usé ACE, por lo que realmente no puedo comentar al respecto. Por lo que he escuchado, la gente encuentra POCO más moderno y más fácil de usar que ACE.

Algunas respuestas a los comentarios de Rahul:

1. No sé de versátil y avanzado. La biblioteca de subprocesos POCO proporciona algunas funciones que no están en Boost: ActiveMethody Activity, y ThreadPool. Los hilos de IMO POCO también son más fáciles de usar y comprender, pero este es un asunto subjetivo.

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

3. Lo suficientemente justo.

4. La biblioteca integrada tiene la ventaja de tener una codificación, documentación y un "aspecto" general coherentes.

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

Nuevamente, probablemente solo debería considerar POCO si proporciona alguna funcionalidad que necesita y que no está en Boost.

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, ACE tiene algunos errores y es difícil de usar. Creo que esa biblioteca necesita reiniciarse. Es difícil decir esto, pero me alejaría de ACE por ahora a menos que haya una razón convincente para usar TAO, o necesite una base de código única para ejecutar C ++ tanto en variantes de Unix como en Windows. TAO es fabuloso para una serie de problemas difíciles, pero la curva de aprendizaje es intensa, y hay una razón por la que CORBA tiene varios críticos. Supongo que haga su tarea antes de tomar la decisión de usar cualquiera de las dos.

Si está codificando en C ++, en mi opinión, boost es una obviedad. Utilizo varias bibliotecas de bajo nivel y las encuentro esenciales. Un grep rápido de mi código revela shared_ptr, program_options, regex, bind, serialization, foreach, property_tree, filesystem, tokenizer, varias extensiones de iterador, alogrithm y mem_fn. En su mayoría, son funcionalidades de bajo nivel que realmente deberían estar en el compilador. Algunas bibliotecas de impulso son muy genéricas; Puede resultar complicado conseguir que hagan lo que usted quiere, pero merece la pena.

Poco es una colección de clases de utilidad que brindan funcionalidad para algunas tareas comunes muy concretas. Encuentro que las bibliotecas están bien escritas e intuitivas. No tengo que dedicar mucho tiempo a estudiar documentación o escribir programas de prueba tontos. Actualmente estoy usando Logger, XML, Zip y Net / SMTP. Empecé a usar Poco cuando libxml2 me irritó por última vez. Hay otras clases que podría usar pero que no he probado, por ejemplo, Data :: MySQL (estoy contento con mysql ++) y Net :: HTTP (estoy contento con libCURL). Probaré el resto de Poco eventualmente, pero eso no es una prioridad en este momento.

Muchos usuarios de POCO informan que lo usan junto con Boost, por lo que es obvio que hay incentivos para las personas en ambos proyectos. Boost es una colección de bibliotecas de alta calidad. Pero no es un marco. En cuanto a ACE, lo he usado en el pasado y no me gustó el diseño. Además, su soporte para antiguos compiladores no compatibles ha dado forma a la base del código de una manera desagradable.

Lo que realmente distingue a POCO es un diseño que escala y una interfaz con una rica disponibilidad de bibliotecas que recuerda a las que se obtienen con Java o C #. En este momento, lo que más falta de POCO es la IO asincrónica.

He utilizado ACE para una aplicación de adquisición de datos de muy alto rendimiento con limitaciones de tiempo real. Un solo hilo maneja la E / S de más de treinta conexiones de socket TCP / IC y un puerto serie. El código se ejecuta en Linux de 32 y 64 bits. Algunas de las muchas clases de ACE que he usado son ACE_Reactor, ACE_Time_Value, ACE_Svc_Handler, ACE_Message_Queue, ACE_Connector. ACE fue un factor clave para el éxito de nuestro proyecto. Se necesita un esfuerzo significativo para comprender cómo usar las clases ACE. Tengo todos los libros escritos sobre ACE. Siempre que he tenido que ampliar la funcionalidad de nuestro sistema, por lo general lleva algún tiempo estudiar qué hacer y luego la cantidad de código requerida es muy pequeña. He encontrado que ACE es muy confiable. También utilizo un poco de código de Boost. No veo la misma funcionalidad en Boost.

Recientemente conseguí un nuevo trabajo y trabajo en un proyecto que usa ACE y TAO. Bueno, lo que puedo decir es que ACE y TAO funcionan y cumplen plenamente sus tareas. Pero la organización general y el diseño de las bibliotecas son bastante abrumadores ...

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

Además, muchos de los nombres de las clases de ACE tampoco proporcionan información útil. ¿O puedes adivinar para qué les gusta ACE_Dev_Poll_Reactor_Notifyo ACE_Proactor_Handle_Timeout_Upcallse pueden usar las clases ?

Además, la documentación de ACE es realmente deficiente, por lo que a menos que desee aprender ACE de la manera difícil (es realmente difícil sin una buena documentación ...), NO recomendaría usar ACE, a menos que realmente necesite TAO para CORBA , si no necesita CORBA, siga adelante y use algunas bibliotecas modernas ..

Las bibliotecas de sockets ACE son sólidas. Si está intentando portar una implementación estándar de sockets, no puede equivocarse. El código ACE se adhiere a un rígido paradigma de desarrollo. Las construcciones de nivel superior son un poco confusas de usar. El paradigma rígido causa algunas anomolias con el manejo de excepciones. Hay o solían haber situaciones en las que los pares de valores de cadena que se pasan a una excepción y uno de los pares es nulo provoca una excepción que lo dejará atónito. La profundidad de las capas de clases es tediosa al depurar. Nunca he probado las otras bibliotecas, así que no puedo hacer un comentario inteligente.

Boost disfruta de un estado "casi STL" debido a la cantidad de personas en el comité de estándares de C ++ que también son desarrolladores de Boost. Poco y ACE no disfrutan de ese beneficio, y según mi experiencia anecdótica, Boost está más extendido.

Sin embargo, POCO en su conjunto se centra más en cosas de tipo red. Me quedo con Boost, así que no puedo ayudarte en eso, pero la ventaja de Boost es su uso (relativamente) generalizado.

Boost es genial, solo he escuchado cosas buenas sobre POCO (pero nunca lo usé) pero no me gusta ACE y lo evitaría en el futuro. Aunque encontrará fanáticos de ACE, también encontrará muchos detractores que no suele obtener con boost o poco (IME), para mí eso envía una señal clara de que ACE no es la mejor herramienta (aunque hace lo que dice en la lata).

De esos, solo he usado ACE. ACE es un excelente marco para aplicaciones de redes empresariales multiplataforma. Es extremadamente versátil y escalable y viene con TAO y JAWS para un desarrollo rápido y poderoso de ORB y / o aplicaciones basadas en la Web.

Ponerse al día con él puede ser algo abrumador, pero hay mucha literatura al respecto y soporte comercial disponible.

Sin embargo, es algo pesado, por lo que para aplicaciones de menor escala puede ser un poco excesivo. Al leer el resumen de POCO, parece que su objetivo es un sistema que se pueda ejecutar en sistemas integrados, por lo que supongo que se puede usar de una manera mucho más ligera. Ahora puedo darle una vuelta: P

Creo que realmente es cuestión de opinión, difícilmente hay una respuesta correcta.

En mi experiencia con la escritura de código de servidor portátil Win32 / Linux (más de 15 años), personalmente encuentro boost / ACE innecesariamente inflado e introduce peligros de mantenimiento (también conocidos como "dll hell") por la pequeña ventaja que brindan.

ACE también parece estar horriblemente desactualizado, es una "biblioteca c ++" escrita por "programadores en c" en los años 90 y realmente se nota en mi opinión. Da la casualidad de que ahora mismo estoy rediseñando el proyecto escrito con Pico, me parece que sigue completamente la idea de ACE, pero en términos más contemporáneos, no mucho mejor en eso.

En cualquier caso, para comunicaciones de servidor elegantes, eficientes y de alto rendimiento, es mejor que no utilice ninguno de ellos.