Diseño de biblioteca: proporcione un archivo de encabezado común o múltiples encabezados

7

Básicamente, hay dos grupos de diseñadores de bibliotecas en relación con el diseño de la inclusión del archivo de encabezado final:

  • Proporcione un único archivo de encabezado que incluya todos los demás archivos de encabezado que conforman la API pública. Por ejemplo, GTK + dicta que solo se incluirá gtk.h . Esto significa que no significa que todo está escrito explícitamente en ese archivo de encabezado común.
  • Haga que el usuario incluya el archivo de encabezado en cuya funcionalidad está más interesado. El ejemplo más prominente sería la biblioteca estándar donde debe incluir stdio.h para E / S, string.h para la manipulación de cadenas, etc. de un std.h común

¿Hay una forma preferida? libabc no da consejos al respecto , mientras que una respuesta a una pregunta similar sugiere mantenerlos separados pero no especifica por qué.

    
pregunta matthias 31.01.2013 - 09:02

2 respuestas

9

El diseño en general siempre es " el arte de equilibrar objetivos contradictorios ".

Aquí tienes estos objetivos:

  1. El marco debe ser fácil de usar. Si su API es de 15 archivos de encabezado, los usuarios siempre tendrán problemas para incluir y omitir cuáles.
  2. Todas las funciones comunes deben estar en un solo archivo de encabezado. Por lo tanto, la E / S de archivos no debería estar en string.h , pero tampoco desea un 3% de archivos de cabecera string.h .
  3. Las dependencias son malas, por lo que debe reducirlas a la menor cantidad posible
  4. La lectura de grandes (cantidades de) archivos de encabezado es lenta
  5. Cada característica en su archivo de encabezado aumentará el riesgo de que necesite incluir otro archivo de encabezado para compilarlo.

gtk.h tiene sentido ya que desea crear una interfaz de usuario para su aplicación (punto # 2). Podría argumentar que las personas deberían incluir cada widget individualmente, pero luego, su marco será un poco más difícil de usar (punto # 1).

Si observa el antiguo código X11 / Motif, verá docenas de #include sentencias en la parte superior de cada C archivo de origen. Se compila un poco más rápido, pero se necesitan horas de trabajo manual para mantener estas listas.

OTOH, si coloca demasiadas funciones en sus archivos de encabezado, tendrá demasiadas dependencias allí y una de ellas podría matarlo (por ejemplo, cuando esta dependencia requiere otro marco con una determinada versión - > dependency hell ).

Espero que ya entiendas que no hay solución; el problema es demasiado complejo y debe abordarse nuevamente cada vez que se inicia un nuevo marco.

EDIT

  

Pero entonces debe haber una buena razón para que GTK + impida activamente la inclusión de encabezados individuales a través de controles macro . - matthias

Para GTK, las declaraciones #include son parte de la API pública. Con estas macros, tienen la libertad de reorganizar los archivos de encabezado, su contenido, los nombres y el orden de inclusión, de la forma que deseen en cualquier momento sin interrumpir un solo proyecto existente.

    
respondido por el Aaron Digulla 31.01.2013 - 09:48
2

Tener todos los encabezados en uno solo es excelente y mejor, es más fácil para otros incluir un solo encabezado que incluir encabezados diferentes.

Un problema de este tipo de diseño, en encabezados grandes como windows.h , gtk.h aún es pequeño en comparación con window.h , el proceso de construcción puede ser lento. En windows.h solucionamos este problema definiendo WIN32_LEAN_AND_MEAN para excluir algunos encabezados poco comunes como Windows Sockets y la API de criptografía para acelerar el proceso de creación, lea más aquí Uso de los encabezados de Windows .

También en el momento en que su biblioteca crezca, hay muchos encabezados y puede ser difícil trabajar con ella, tendrá que hacer muchas macros, lotes y endup con un encabezado complejo para no interrumpir la compatibilidad hacia atrás.

Aunque, personalmente prefiero el diseño de un solo encabezado.

    
respondido por el user76452 31.01.2013 - 09:43

Lea otras preguntas en las etiquetas