2009-04-17 35 views
17

Tengo una considerable experiencia con ACE, Boost y wxWidgets. Recientemente he encontrado las bibliotecas POCO. ¿Alguien tiene alguna experiencia con ellos y cómo se comparan con ACE, Boost y wxWidgets con respecto al rendimiento y la confiabilidad?ACE vs Boost vs Poco vs wxWidgets

Estoy particularmente interesado en reemplazar ACE con POCO. No he podido obtener ACE para compilar con VS2008 con un objetivo x64. Uso principalmente ACE_Task, así que creo que puedo reemplazarlos con los hilos de Poco y las colas de mensajes.

Algunas otras partes de POCO que me interesan son HTTPServer, HTTPClient y LayeredConfiguration. Esas bibliotecas son similares a las bibliotecas de Boost y wxWidgets, pero trato de limitar mi uso de wxWidgets a los componentes de la GUI y las bibliotecas comparables de Boost son ... difíciles.

Me interesa cualquier experiencia que alguien pueda compartir sobre POCO, buena o mala.

+0

Si tiene problemas con ACE, póngase en contacto con Steve Huston en http://www.riverace.com/ - ha estado trabajando en ACE durante mucho tiempo. Cuando trabajé con ACE en una compañía anterior, hablé con él sobre los problemas que teníamos y él fue amable y extremadamente útil. Finalmente terminamos comprando su apoyo y valió cada centavo. –

+0

Su título es engañoso, como si estuviera tratando de comparar manzanas y naranjas. Todavía no entiendo por qué mencionas wx y boost en absoluto? – mentat

+3

Existe una superposición significativa entre POCO y Boost (por ejemplo, punteros compartidos, asio, opciones de programa). Del mismo modo, POCO y wxWidgets se superponen bastante. –

Respuesta

17

He usado partes de POCO de vez en cuando y me pareció una muy buena lib. Abandoné en gran medida a ACE hace algunos años, pero POCO contiene algunos de los mismos patrones: Tarea, Reactor, etc. Nunca he tenido ningún problema, así que tengo que asumir que es estable.

Algunos aspectos que me gustan:

  • es una jerarquía de programación orientada a objetos bastante bien integrado, de forma que los componentes funcionen bien entre sí. Tiene una sensación mucho más cohesiva que algo como Boost, que es más bien pieza-comida.

  • el código fuente está disponible y es muy claro. No es necesario dedicar grandes bloques de tiempo para comprender lo que está haciendo (ACE, al menos la última vez que miré a la fuente) o ser un asistente de plantillas (Boost).

  • Componentes pegados cerca del estándar C++. Las excepciones se derivan de std :: exception; aún no reinventaron otra clase de cadena, etc.

  • Es sorprendente. Hay mucho más de lo que parece a primera vista.

La desventaja:

  • una cuestión de preferencia personal, pero los autores se adhieren más o menos a un modelo de archivo de una clase por cabecera por lo que terminan incluyendo una gran cantidad de archivos diferentes.

  • Documentación limitada. Principalmente páginas de API de tipo doxygen y un par de archivos PDF que apuntan a ejemplos de fuentes. Es utilizable, pero teniendo en cuenta el tamaño de la lib, inicialmente es difícil saber si está haciendo el mejor uso de los componentes.

  • Si hay una comunidad activa construida alrededor de ella, nunca la encontré. El paquete es mantenido por una empresa europea y tenían una wiki, pero no la encontré tan activa o útil.

Teniendo en cuenta todo, la desventaja es bastante menor. Creo que es una biblioteca muy buena y definitivamente la recomendaría.

6

Nunca utilicé ACE, pero utilicé Boost y Poco. Me gusta mucho el estilo de codificación de Poco. Los paquetes son consistentes y el código fuente es fácil de leer. No son una plantilla loca como el impulso. En mi experiencia, me paso horas leyendo cómo usar boost - paquete de serialización, contenedor de mapas de punteros, etc. - y poco tiempo leyendo cómo usar cosas de Poco. Yo diría que tienen un buen diseño y hacen uso de plantillas cuando es necesario.

En el lado negativo, tienen documentación de API pero no tienen una documentación extensa sobre cómo usaría un paquete. Para eso, normalmente miras el código fuente de ejemplo o su unidad prueba el código fuente.

Tengo el HTTPServer trabajando en Windows/Linux sin ningún error obvio.

Así que califíquelo como 1 experiencia positiva.

2

Para mí, parece que impulsar tiene la mayor tracción para las nuevas bibliotecas de C++ y el hecho de que muchos de ellos fueron aceptados en el próximo estándar de C++ habla por sí mismo.

Uso ACE and Boost y las razones por las que los elegí son que son maduros (especialmente ACE) tienen una gran comunidad de usuarios que asegura que se mantendrán y mejorarán y que puedo obtener un soporte profesional de buena calidad. Utilizamos Remedy IT para nuestro soporte de ACE/TAO y estamos muy satisfechos.

Como ACE es una biblioteca mucho más antigua que Boost y uno de sus objetivos es admitir plataformas más exóticas (como las integradas), no utiliza tanta tecnología punta C++ como Boost. Estoy usando una mezcla de ACE y Boost y estoy muy contento con esa combinación.

No sé exactamente por qué pones wxWidgets en el juego, ya que es principalmente una biblioteca de UI de gráficos. Pero si tuviera que hacer algunos proyectos de interfaz de usuario de C++ iría con QT, sobre todo porque esta es también una biblioteca ampliamente utilizada (todo el escritorio de KDE está construido sobre QT) y por lo tanto bien mantenido y tendría acceso a un gran base de usuarios para preguntas y soporte.

+1

wxWidgets define su propia cadena y clases de colección, así como mucha clase de utilidad multiplataforma para archivo/socket, etc. Esto es herencia de los días previos a los compiladores de C++ que soportaban el STL (o plantillas!) –

+0

Es un error común que wxWidgets es solo material de GUI, pero hay mucho más. –

+0

@ Jere.Jones Lo mismo ocurre con QT, pero eso no significa que lo use para cosas que no sean UI :-) – lothar