¿Debo agregar la fuente de las bibliotecas en lugar de vincularlas?

13

Soy relativamente nuevo en C ++, por lo que no estoy seguro de cómo debo manejar mejor las pequeñas dependencias (por ejemplo, un lenguaje de secuencias de comandos o un analizador JSON / YAML / XML).

¿Debo crear proyectos separados y vincularlos como biblioteca estática, o hay inconvenientes de simplemente poner los archivos .h / .cpp en mi proyecto principal?

Este último parece ser mucho más fácil porque pasé varias horas tratando con bibliotecas incompatibles (diferentes configuraciones del compilador al crear la biblioteca), pero no quiero empezar a aprender C ++ de forma incorrecta.

Si es preferible mantenerlas como bibliotecas separadas, ¿cómo puedo mantener sincronizadas las marcas de compilación para que los archivos .lib / .a se vinculen correctamente a mi aplicación?

(Actualmente estoy trabajando con MSVC 2015, pero el objetivo es compilar en Mac OS X e iOS usando XCode / clang, de modo que tenga que lidiar con al menos 3 tipos diferentes de bibliotecas (Win x86, Mac x64 , ARM))

    
pregunta Michael Stum 26.03.2016 - 13:59

2 respuestas

3

TLDR;

¿Debería usted agregar la fuente? SÍ
¿Debería X agregar la fuente? DEPENDS

Aquí viene el porqué ...

En el pasado, el tiempo de compilación era un problema que tenían incluso los proyectos más pequeños. Compilar sus fuentes y no preocuparse por almacenar en caché los resultados del compilador fue definitivamente atractivo para algunos. Ese es un punto para las bibliotecas irrelevantes para usted.

Otro importante es el versionado. ¿Realmente necesitas una versión de cada biblioteca por separado? ¿Ejecutar pruebas contra cada una? ¿Distribuirlo entre muchos miembros del equipo? Las bibliotecas son excelentes si lo haces, y son convenientes para moverte, pero una vez más, parece que tampoco te importa esto.

El punto final aquí es, es una sobrecarga adicional, y eliminar los archivos de origen es más fácil en su caso, lo que le da un punto muy importante a la eliminación de los recursos en lugar de usar bibliotecas. Como ha notado, una vez que realice un cambio en la configuración del compilador único, tendrá que perseguir todas las dependencias de lo contrario.

Sé todo esto por experiencia:

Para los proyectos Swift, definitivamente uso marcos (bibliotecas) y enlaces con ellos, ya que es fácil de configurar utilizando Xcode. También necesito realmente el control de versiones, las pruebas y el desacoplamiento, así que por eso.

Para los proyectos Mono (C #), para Unity, comencé con el enfoque moderno de dividir el proyecto en bibliotecas, compilar y probar cada una, lo cual fue genial ... pero una vez que coloqué las bibliotecas en Unity, todo tipo De los problemas ocurridos, desde la versión pirateada de los usos de Mono Unity, hasta el comportamiento a veces diferente que muestra el código al cambiar de plataforma. No tener un solo IDE aquí para administrar todas las bibliotecas fue un verdadero dolor, por lo que poner todas las fuentes dentro de Unity fue una gran victoria para la productividad.

Finalmente, lo más relevante para ti, un proyecto de juego en C ++ en el que trabajé. Un motor de juego, un cliente de red en tiempo real, un cliente de red HTTP, AI y un almacén de persistencia se escribieron para este juego, solo en el lado del cliente. ¿Para qué opté? CLION + Bibliotecas. A pesar de que estaba usando bibliotecas, no se sentía como si lo estuviera. Todas las fuentes estaban en el proyecto CLion IDE, y al componer CMakeLists, pude activar todas las compilaciones y vincularlas de una sola vez.

Como conclusión , diría que usar bibliotecas es una solución a prueba de futuro, pero también una optimización prematura si no es necesaria. Por lo que pude averiguar de su situación, cambiar de MSVC a Xcode será una molestia si va a tener un objetivo de compilación múltiple. Por lo tanto, simplemente colóquelo y mantenga el mayor aislamiento posible para cuando sea necesario que pueda usar bibliotecas.

P.S: Tengo un dilema similar estos días con la ventana acoplable. ¿Debo componer? ¿Debo simplemente correr localmente? .. etc. También Elixir, ya que le permite construir aplicaciones dentro de la misma aplicación .. ¿Debo hacer eso? ¿O separar la aplicación en los llamados micro-servicios? ... etc. No hay una bala de plata, mídase siempre, como YMMV.

    
respondido por el Mazyod 27.03.2016 - 08:24
0

Yo diría que sí, siempre que sea más fácil. Hay muchos beneficios:

  1. Resultará en un código mejor y más rápido, especialmente si activa la optimización de tiempo de enlace.

  2. A tu IDE le gustará más, por ejemplo, (con suerte) le permitirá saltar a la implementación (.cpp) del código de la biblioteca, en lugar de solo a la interfaz (.h), que es extremadamente útil cuando se trabaja con código mal documentado (es decir, la mayoría código).

  3. A menudo te permite agregar la dependencia como un submódulo de git, que es una forma un tanto pirateada pero bastante buena de tener dependencias (para C ++ de todos modos, que no tiene sistemas de construcción sanos). Facilita la actualización de la biblioteca y la prueba de diferentes versiones.

  4. No tiene que preocuparse por que se compile una dependencia con MSVC ++ 2013, mientras que, por ejemplo, usa 2017. O MSVCRT compartido vs estático.

  5. Puedes construir fácilmente en modo de depuración y entrar en la biblioteca.

La única razón por la que creo que no desea hacer esto, es si la biblioteca es grande y tiene un sistema de compilación complejo que no desea replicar en el suyo, por ejemplo. Impulso o LLVM. Pero para bibliotecas simples no hay inconveniente realmente.

Como ejemplo, uso libusb en algunos proyectos y necesito compatibilidad con Windows. libusb usa autotools, que es una broma de un sistema de compilación y no funciona en Windows de todos modos. Proporcionan archivos binarios precompilados, pero están diseñados con MSVC ++ 2013 y no funcionarán con 2017. La solución más sencilla, con mucho, es simplemente agregar todos los archivos relevantes .c y .h a mi proyecto.

    
respondido por el Timmmm 10.04.2018 - 10:55

Lea otras preguntas en las etiquetas