2010-02-27 14 views
43

La biblioteca Loki implementa algunos conceptos muy utilizados (puntero inteligente, visitante, fábrica, etc.). El libro asociado "Modern C++ Design" se menciona a menudo, pero la biblioteca en sí misma no se usa ampliamente. ¿Porqué es eso?¿Por qué la biblioteca Loki no se usa más ampliamente?

La mayoría de los desarrolladores parecen preferir Boost. En particular, ¿por qué la gente a menudo decide usar los punteros inteligentes de Boost en lugar de los de Loki?

+23

Nadie necesita un puntero inteligente con 6 parámetros de plantilla. –

+4

Loki infamemente no pudo ser compilado por ningún compilador mainstream cuando fue publicado. Alexandrescu es un tipo inteligente. Demasiado inteligente para mí. –

+4

@johannes: la mayoría de los parámetros de la plantilla tienen valores predeterminados, por lo que no es necesario configurarlos. Y podría usar typedef para enlazar algunos de los parámetros de la plantilla. – Frank

Respuesta

11

Desea utilizar una biblioteca que el próximo programador va a saber y que será bien soportada en el futuro, por lo que elige una lib importante. Debido a que es una gran cantidad de gente lo usa, por lo que se convierte en la opción predeterminada.

4

Hablando como alguien que ha usado bastante la biblioteca de Boost, y también miró a Loki más de una vez, el mayor problema fue la escasez de documentación. Además, Loki usa algunas de las partes más peludas de las plantillas de C++. Emocionante, pero también bastante desalentador.

+4

* "Loki usa algunas de las partes más peludas de las plantillas de C++" *, al igual que Boost, ¿o estoy malinterpretando algo? –

+6

Consulte la pregunta frecuente 'shared_ptr': * La parametrización desanima a los usuarios. La plantilla shared_ptr está cuidadosamente diseñada para satisfacer las necesidades comunes sin una parametrización exhaustiva. Algún día se puede inventar un puntero inteligente altamente configurable que también es muy fácil de usar y muy difícil de usar. Hasta entonces, shared_ptr es el puntero inteligente de elección para una amplia gama de aplicaciones. (Aquellos interesados ​​en los indicadores inteligentes basados ​​en políticas deben leer Modern C++ Design de Andrei Alexandrescu.) * –

+4

@litb: Como dije en el IRC, no estoy de acuerdo. Simplemente me pareció más natural usar el puntero inteligente de loki y luego el de boost. Si quería bloqueo mutex en el puntero inteligente de Loki, solo necesitaba ingresar una clase mutex para él. El puntero inteligente de Loki es la solución más genérica que encontré para el problema. A veces hace que el uso sea más fácil. –

19

Loki es un tipo de cosa de investigación/prueba de concepto. Alexandrescu empuja nuevas ideas, otras personas las adoptan para el mundo real. También boost::shared_ptr está casi literalmente en TR1.

2

Utilicé Loki una vez para una pequeña herramienta (básicamente un intérprete) y realmente me gustó. Mis compañeros de trabajo estaban menos entusiasmados con la biblioteca, por lo que su uso se limitó a este pequeño subproyecto.

6

En realidad, prefiero la forma de hacer las cosas de Loki y he contribuido a Loki un patrón Decorator que ahora se encuentra en el rastreador porque el proyecto hasta ahora sé ya no se mantiene.
Utilizo boost shared_pointer porque pronto será el estándar. Puede que no me guste el hecho de que no puedo personalizarlo para que actúe exactamente como quiero que actúe, pero tengo que vivir con él.
El uso de la biblioteca estándar es importante ya que mantiene el código mantenible por otros programadores. Si es de código abierto y quieres experimentar, usa Loki. Nadie te está deteniendo.
En realidad, Windows Vista usa algunas de las funciones de Loki.
Supongo que no están utilizando las implementaciones redundantes de punteros inteligentes y visitantes.

16

Loki sufre de ser una buena biblioteca tocando varias áreas funcionales (soporte de metaprogramación de plantillas con algunas aplicaciones específicas: punteros inteligentes, singletons, objetos funcionales, protectores de alcance, etc.), mientras que boost es una colección de muchas bibliotecas típicamente exhaustiva cubriendo cada área funcional y mucho más afinado para la portabilidad (primero).

Cuando 9 de cada 10 aves se pueden matar con la misma piedra, muchas personas simplemente comienzan con el impulso y llenan los huecos con bibliotecas de terceros. Es muy difícil competir con el impulso si te superpones. Debido a que no se superpondrá con mucho impulso, la gente descargará/instalará impulso de todos modos para obtener la otra funcionalidad, así que a menos que encuentres un área en la que el impulso sea débil y la diferencia sea significativa para el proyecto, "se resolverán" "para el impulso allí también.

Además, Alexandrescu hizo repetidos intentos para incluir a Loki en el impulso, y algunos de los autores de impulso clave simplemente no cooperaron. Mi opinión personal es que quieren que el MPL más completo pero mucho menos amigable para el usuario tenga más "cuota de mercado": como autores de la biblioteca y los libros en papel que son la única documentación decente (en marcado contraste con la mayoría de los otros bibliotecas que tienen una excelente documentación en línea), salen bastante bien de esto.

Si alguien está ofendido y no está de acuerdo con este análisis, soy todo oídos.

Otro problema práctico con el código extremadamente parametrizado es que en proyectos grandes donde diferentes desarrolladores/equipos trabajan de forma independiente, a menudo terminan utilizando sutilmente diferentes instancias de la misma plantilla bastante arbitrariamente. Esto hace que sea más difícil de pasar valores entre esos subsistemas: puede necesitar el receptor para:

  • parametrizar (es decir, con plantilla, y por lo tanto en línea, que introduce dependencias de compilación y más lento se basa en los sistemas de escala empresarial)
  • proporcionan una cobertura mínima para todas las instancias posibles (por ejemplo, comprobación de códigos de error y excepciones de expecting/handling)
  • trabajando a través del tiempo de compilación en tiempo de ejecución basado en un acceso base abstracto con implementaciones para cada instanciación) que compromete algunos de los beneficios de rendimiento de la parametrización

Esto es posible, pero se necesita un gran programador para navegar por el terreno.

+1

Ese es exactamente el problema con boost, boost IS la biblioteca estándar de C++ o debería serlo, ya que la biblioteca estándar actual no se adapta a nadie ... Es por eso que C++ está siendo descargado por lenguajes como Java y C#, debido al estándar altamente rico biblioteca.Sin mencionar que tanto Java como C# le permiten a uno conectar otras librerías si así lo desean, ya que tienen buenas interfaces destinadas a ser extensibles. – Coyote21

Cuestiones relacionadas