Pensar en C++ (Volumen 1) - Grupo ARCO

✐
✐
✐
“Volumen1” — 2012/1/12 — 13:52 — page 529 — #567
✐
A.6. Orden de los #includes
El valor del estilo es que el uso de mayúsculas tiene significado - viendo la primera
letra se puede saber si es una clase o un objeto/método. Esto es especialmente
útil cuando se invocan miembros estáticos.
A.6. Orden de los #includes
Los ficheros de cabecera se incluyen en orden «del más específico al más general».
Es decir, cualquier fichero de cabecera en el directorio local se incluye primero,
después las «herramientas» propias, como require.h, luego cabeceras de librerías
de terceros, después cabeceras de la librería estándar C++, y finalmente cabeceras de
la librería C.
La justificación para esto viene de John Lakos en Large-Scale C++ Software Design
(Addison-Wesley, 1996):
FIXME Los errores de uso latentes se puede evitar asegurando que el fichero
.h de un componente es coherente en si mismo - sin declaraciones o
definiciones externas. Incluir el fichero .h como primera línea del fichero
.c asegura que no falta ninguna pieza de información de la interfaz física
del componente en el fichero .h (o, si la hay, aparecerá en cuanto intente
compilar el fichero .c.
Si el orden de inclusión fuese «desde el más específico al más general», entonces
es más probable que si su fichero de cabecera no es coherente por si mismo, lo
descubrirá antes y prevendrá disgustos en el futuro.
A.7. Guardas de inclusión en ficheros de cabecera
Los guardas de inclusión se usan siempre en los ficheros de cabecera para prevenir
inclusiones múltiples durante la compilación de un único fichero .cpp. Los
guardas de inclusión se implementan usado #define y comprobando si el nombre
no ha sido definido previamente. El nombre que se usa para el guarda está basado
en el nombre del fichero de cabecera, pero con todas las letras en mayúscula y
reemplazando el punto por un guión bajo. Por ejemplo:
// IncludeGuard.h
#ifndef INCLUDEGUARD_H
#define INCLUDEGUARD_H
// Body of header file here...
#endif // INCLUDEGUARD_H
El identificador de la última línea se incluye únicamente por claridad. Algunos
preprocesadores ignoran cualquier carácter que aparezca después de un #endif,
pero no es el comportamiento estándar y por eso el identificador aparece comentado.
A.8. Uso de los espacios de nombres
En los ficheros de cabecera, se debe evitar de forma escrupulosa cualquier contaminación
del espacio de nombres. Es decir, si se cambia el espacio de nombres
fuera de una función o clase, provocará que el cambio ocurra también en cualquier
fichero que incluya ese fichero de cabecera, lo que resulta en todo tipo de problemas.
529
✐
✐
✐
✐