2009-01-28 9 views
16

¿Me puede recomendar qué debo leer/aprender para hacer un código bien organizado en C?mejores artículos sobre la organización de archivos de código en C

Una de las cosas que quiero aprender es los principios del proyecto de desdoblamiento en .hy archivos .c, dónde va y por qué, para nombrar variables, cuándo usar variables globales ...

Estoy interesado en libros y artículos que se ocupan de este problema específico.

Respuesta

1

Creo que la mejor lectura educativa que obtendrás sobre este tema es leer algo así como la fuente Linux Kernel. Tiene un buen diseño de fuente, y es básicamente el proyecto estándar de C grande. Here es una guía sobre cómo deben juntarse los archivos fuente para fuente BSD.

En serio, solo comience a leer la fuente de Kernel y tenga una idea de cómo se junta todo. Es un proyecto muy bien planeado, obviamente.

14

Un buen libro que cubre una gran parte de este (tanto para C y C++) es Large Scale C++ Software Design, by John Lakos:

Además, una buena regla para recordar es "No hacer nada que asigna memoria en un archivo de cabecera"

+2

"Nunca hagas nada que asigne memoria en un archivo de encabezado" --- Me gusta eso. Sucinto y una perla de sabiduría. – dmckee

+0

solo para asegurarme de que me sale bien, la asignación de memoria en un archivo de cabecera es un problema porque si dos archivos .c lo incluyen, habrá ambigüedades del enlazador. ¿Estoy en lo correcto? – Lazer

+0

Solo me preguntaba, ¿podría profundizar en esa regla de oro? Puedo entender si su asignación estática (por ejemplo, una variable sin un 'extern' delante), pero realmente no veo cómo es un problema, por ejemplo, con 'malloc'. – Edmund

2

específico para Unix (y no a c, naturalmente), pero sin embargo:

Recursive Make Considered Harmful

Con la estructura de compilación descrita, puede permitirse utilizar mucho de archivos. Entonces, cada unidad lógica obtiene un encabezado y un archivo fuente.

3

En cuanto al diseño de archivos, no hay demasiadas alternativas.

La partición es típicamente uno de los siguientes (paquete que aquí hay una sola biblioteca o binario):.

  1. .../proyecto /.../ paquete/módulo {c, h}
  2. .../project /.../ {src, include}/package/module. {C, h} // encabezados que no son de interfaz van a src
  3. .../project /.../ paquete/{src, incluir}/módulo. {c, h} // cabeceras no interfaz go para src

El particionamiento (1) es conveniente porque todos los archivos pertenecientes a un paquete particular se almacenan en un solo directorio, por lo que el paquete puede moverse fácilmente, pero con este enfoque separar los encabezados de API de los privados y detectar cambios de API no es trivial . (2) y (3) son muy similares, hacen que la liberación de API y la detección de cambios de API sean triviales, mientras que (2) es un poco más fácil para el caso cuando siempre liberas todo el proyecto y (3) es ligeramente mejor cuando lanzas individial paquetes (por ej.para los propósitos)

parcheo En cualquier C/C++ proyecto hay típicamente los siguientes paquetes comunes:

  1. macros comunes y tipos de datos
  2. paquete de registro
  3. aplicación del paquete de arranque (en caso de que haya más de 1 binarios en el proyecto).
Cuestiones relacionadas