ARCHIVOS DE CABECERA

Se denomina header file, al espaol fichero cabecera, o include file, al espaol ficherode
inclusin, en ciencias de computacin, especialmente en el mbito de los lenguajesde
programacin C y C++, al archivo, normalmente en forma de cdigo fuente, que
elcompilador incluye de forma automtica al procesar algn otro archivo
fuente.Tpicamente los programadores especifican la inclusin de los header files por
mediode pragmas al comienzo (head o cabecera) de otro archivo fuente.Un header file
contiene, normalmente, una declaracin directa de clases, subrutinas,variables, u otros
identificadores. Aquellos programadores que desean declararidentificadores estndares
en ms de un archivo fuente pueden colocar esosidentificadores en un nico header file,
que se incluir cuando el cdigo que contienesea requerido por otros archivos.Si se
adopta el modelo modular entonces se querr tener para cada mdulo lasdefiniciones de
las variables, los prototipos de las funciones, etc. Sin embargo, qusucede si varios
mdulos necesitan compartir tales definiciones? En tal caso, lo mejores centralizar las
definiciones en un archivo, y compartir el archivo entre los mdulos.Tal archivo es
usualmente llamado un archivo cabecera .Por convencin estos archivos tienen el sufijo .h
Se han revisado ya algunos archivos cabecera de la biblioteca estndar, por ejemplo:

#include <stdio.h>

Se pueden definir los propios archivos cabecera y se pueden incluir en el programacomo
se muestra enseguida:

#include "mi_cabecera.h"
Los archivos cabecera por lo general slo contienen definiciones de tipos de
datos,prototipos de funciones y comandos del preprocesador de C



FUNCIONES DE BIBLIOTECAS
El lenguaje C, C++ contiene numerosas funciones, cuando se emplean funciones deesta
biblioteca estndar, se incrementa la transportabilidad de los programas.C ofrece un
conjunto de funciones estndar que dan soporte a las operaciones que seutilizan con ms
frecuencia. Estas funciones estn agrupadas en bibliotecas. Parautilizar cualquiera de las
funciones que forman parte de las bibliotecas estndar de C,slo hace falta realizar una
llamada a dicha funcin.Los grupos de funciones estndar ms comunes son:

Entrada/Salida estndar
Matemticas
De conversin
Diagnostico
De manipulacin de memoria
Control de proceso
Ordenacin
Directorios
Fecha y hora
Bsqueda
Manipulacin de cadenas
Grficos

Tipos de ficheros

Los ficheros de cabecera del proyecto se llamarn fichero.h (si trabajamos en C) o
fichero.hh (si trabajamos en C++) (tambin sera correcto el uso de fichero.hpp para C++)

Los ficheros con el codigo de las funciones no inline se llamar fichero.c (si trabajamos en
C) o fichero.cc (si trabajamos en C++) (tambin sera correcto el uso de fichero.cpp para
C++)

Los ficheros con el codigo de las funciones inline se llamar fichero.ic (si trabajamos en C)
o fichero.icc (si trabajamos en C++) (tambin sera correcto el uso de fichero.ipp)

El separar las funciones inline (funciones definidas en una sla lnea) de las dems
funciones se debe a que algunos debuggers (y ms raramente algunos compiladores) no
manejan bien las funciones inline.
Separando las funciones inline en un fichero aparte, podemos conseguir que se incluyan
en los ficheros de cabecera o en los ficheros fuente, segn nosotros deseemos de acuerdo
a directivas de compilacin.

A continuacin se muestra en un ejemplo como se hara...

// At the end of fichero.hh
#if !defined(DEBUG_MODE)
#include <fichero.icc>
#endif

// At the end of fichero.cc
#if defined(DEBUG_MODE)
#include <fichero.icc>
#endif

Con este ejemplo conseguimos que si se compila en modo debug (definiendo
DEBUG_MODE) las funciones inline (funcion.icc) se incluiran en el fichero.hh, mientras
que en el modo normal se incuirian en el fichero.cc

[subir]

10.2 Nombres de los ficheros

Para C en cada fichero de una librera tiene que haber funciones realcionadas con el
mismo fin, y el nombre sera el apropiado para poder identificar el fin de estas funciones
(por ejemplo funcionesFecha.c para recopilar funciones de manejo de fechas).

Para C++ en cada fichero de una librera tiene que haber solamente una clase, y el nombre
del fichero sera el mismo que el de la clase (por ejemplo CMiClase.cc para la
implementacin de la clase CMiClase).

[subir]

10.3 Estructura de los ficheros

Los ficheros de cabecera (fichero.h, fichero.hh, fichero.hpp) tendran que tener una
estructura como la siguiente:

Cabecera del fichero.
Includes si es necesario alguno (se aconseja que en los ficheros de cabecera no vaya
ningn fichero include o el mnimo nmero imprescindible de ellos).
Primero los includes del sistema (si hace falta alguno)
Despus los includes propios del proyecto (si hace falta alguno)
Constantes simblicas y definiciones de macros que se vayan a utilizar en otros
m&ocaute;dulos que incluyan este.
Definicin de tipos que se vayan a utilizar en otros mdulos que incluyan este.
Prototipos de las funciones del mdulo que puedan ser utilizadas desde otro mdulo.
Declaracin de las clases (C++) del mdulo que puedan ser utilizadas desde otro mdulo.
Los ficheros fuente (fichero.c, fichero.cc, fichero.cpp) tendran que tener una estructura
como la siguiente:

Cabecera del fichero.
Includes necesarios para el mdulo.
Primero los includes del sistema.
Despus los includes propios del proyecto.
Constantes simblicas y dfiniciones de macros que solamente vayan a utilizarse en este
mdulo.
Definicin de tipos que se vayan a utilizar solamente en este mdulo.
Variables globales usadas en el mdulo.
Primero las declaradas en otros mdulos distintos, con la palabra reservada extern.
Despus las declaradas en este m&odulo.
Prototipos de las funciones del mdulo que slo se usen en este mdulo.
Declaracin de las clases (C++) del mdulo que slo se usen en este mdulo.
Implementacin de las funciones del mdulo.
La funcin principal (main()) tiene que ser la primera, las dems estarn ordenadas por
orden de aparicin en la funcin principal o por orden de llamada, u organizndolas por su
uso o finalidad.
Es aconsejable que las implementaciones estn en el mismo orden que sus prototipos.
Implementacin de los mtodos de las clases (C++).
Es aconsejable que las implementaciones de los mtodos estn en el mismo orden en que
aparecen en las declaraciones de las clases.
Los ficheros que contienen las funciones inline (fichero.ic, fichero.icc, fichero.ipp)
solamente contendrn el cdigo de las funciones inline y tendrn una estructura como la
siguiente:

Cabecera del fichero
Cdigo de las funciones inline.
Se aconseja que estn en el mismo orden en que se declaran en el fichero de cabecera.
[subir]

10.4 Cabeceras de los ficheros

Todos los ficheros tienen que incluir una cabecera que indique los siguientes campos.

Nombre del fichero
Finalidad o uso del mdulo (incluyendo los argumentos si en este fichero se encuentra la
funcin main).
Variables globales afectadas (si las hay).
Nombre del autor y fecha de ltima modificacin.
Historial de moficiaciones, con fecha, motivo y nombre del autor.
[subir]

10.5 Ficheros de cabecera (*.h)

Todos los ficheros de cabecera tienen que tener un mecanismo para impedir que sean
incluidos ms de una vez (lo mismo les pasara a los ficheros de las funciones inline).

Por ejemplo, el siguiente metodo valdra:
#ifndef __FICHERO_H__
#define __FICHERO_H__
// __FICHERO_H__ sera un identificador propio de este fichero (fichero.h)
// ya que lo he construido con el nombre del fichero
...
// Aqu ira todo el contenido del fichero
...
#endif

Todos los ficheros de cabecera incluidos en los ficheros deben serlo exclusivamente por
que se usan.
Hay que evitar la inclusin de ficheros de cabecera que no se usan, por legibilidad, puede
complicar la compilacin y el linkado innecesariamente.

Los includes de libreras prpias del sistema se realiza indicando el nombre entre
caracteres < y >. Por ejemplo:
#include <stdio.h>

Los includes propios del proyecto se realizarn indicando el nombre entre caracteres ".
Por ejemplo:
#include "CMiClase.hh.h"

Conveciones para los ficheros de cabecera

Cuando se crea una struct que contiene funciones miembro, se est creando un nuevo
tipo de dato. En general, se intenta que ese tipo sea fcilmente accesible. En resumen, se
quiere que la interfaz (la declaracin) est separada de la implmentacin (la definicin de
los mtodos) de modo que la implementacin pueda cambiar sin obligar a recompilar el
sistema completo. Eso se consigue poniendo la declaracin del nuevo tipo en un fichero
de cabecera.

Cuando yo aprend a programar en C, el fichero de cabecera era un misterio para mi.
Muchos libros de C no hacen hincapi, y el compilador no obliga a hacer la declaracin de
las funciones, as que pareca algo opcional la mayor parte de las veces, excepto cuando se
declaraban estrucutras. En C++ el uso de los ficheros de cabecera se vuelve claro como el
cristal. Son prcticamente obligatorios para el desarrollo de programas sencillos, y en ellos
podr informacin muy especfica: declaraciones. El fichero de cabecera informa al
compilador de lo que hay disponible en la librera. Puede usar la librera incluso si slo se
dispone del fichero de cabecera y el fichero objeto o el fichero de librera; no necesita
disponer del cdigo fuente del fichero cpp. En el fichero de cabecera es donde se guarda
la especificacin de la interfaz.

Aunque el compilador no lo obliga, el mejor modo de construir grandes proyectos en C es
usar libreras; colecciones de funciones asociadas en un mismo mdulo objeto o librera, y
usar un fichero de cabecera para colocar todas las declaraciones de las funciones. Es de
rigor en C++, Podra meter cualquier funcin en una librera C, pero el tipo abstracto de
dato C++ determina las funciones que estn asociadas por medio del acceso comn a los
datos de una struct. Cualquier funcin miembro debe ser declarada en la declaracin de la
struct; no puede ponerse en otro lugar. El uso de libreras de funciones fue fomentado en
C y institucionalizado en C++.

4.7.1. Importancia de los ficheros de cabecera

Cuando se usa funcin de una librera, C le permite la posibilidad de ignorar el fichero de
cabecera y simplemente declarar la funcin a mano. En el pasado, la gente haca eso a
veces para acelerar un poquito la compilacin evitando la tarea de abrir e incluir el fichero
(eso no supone ventaja alguna con los compiladores modernos). Por ejemplo, la siguiente
es una declaracin extremadamente vaga de la funcin printf() (de <stdio.h>):

printf(...);
Estos puntos suspensivos [49] especifican una lista de argumentos variable [50], que dice:
la printf() tiene algunos argumentos, cada uno con su tipo, pero no se sabe cuales.
Simplemente, coge los argumentos que veas y aceptalos. Usando este tipo de declaracin,
se suspenden todas las comprobaciones de errores en los argumentos.

Esta prctica puede causar problemas sutiles. Si declara funciones a mano, en un
fichero puede cometer un error. Dado que el compilador slo ver las declaraciones
hechas a mano en ese fichero, se adaptar al error. El programa enlazar correctamente,
pero el uso de la funcin en ese fichero ser defectuoso. Se trata de un error difcil de
encontrar, y que se puede evitar fcilmente usando el fichero de cabecera
correspondiente.

Si se colocan todas las declaraciones de funciones en un fichero de cabecera, y se incluye
ese fichero all donde se use la funcin se asegurar una declaracin consistente a travs
del sistema completo. Tambin se asegurar de que la declaracin y la definicin
corresponden incluyendo el fichero de cabecera en el fichero de definicin.

Si declara una struct en un fichero de cabecera en C++, debe incluir ese fichero all donde
se use una struct y tambin donde se definan los mtodos de la struct. El compilador de
C++ devolver un mensaje de error si intenta llamar a una funcin, o llamar o definir un
mtodo, sin declararla primero. Imponiendo el uso apropiado de los ficheros de cabecera,
el lenguaje asegura la consistencia de las libreras, y reduce el nmero de error forzando
que se use la misma interface en todas partes.

El fichero de cabecera es un contrato entre el programador de la librera y el que la usa. El
contrato describe las estructuras de datos, expone los argumentos y valores de retorno
para las funciones. Dice, Esto es lo que hace mi librera. El usuario necesita parte de
esta informacin para desarrollar la aplicacin, y el compilador necesita toda ella para
generar el cdigo correcto. El usuario de la struct simplemente incluye el fichero de
cabecera, crea objetos (instancias) de esa struct, y enlaza con el mdulo objeto o librera
(es decir, el cdigo compilado)

El compilador impone el contrato obligando a declarar todas las estruturas y funciones
antes que puedan ser usadas y, en el caso de mtodos, antes de ser definidos. De ese
modo, se le obliga a poner las declaraciones en el fichero de cabecera e incluirlo en el
fichero en el que se definen los mtodos y en los ficheros en los que se usen. Como se
incluye un nico fichero que describe la librera para todo el sistema, el compilador puede
asegurar la consistencia y evitar errores.

Hay ciertos asuntos a los que debe prestar atencin para organizar su cdigo
apropiadamente y escribir ficheros de cabecera eficaces. La regla bsica es nicamente
declaraciones, es decir, slo informacin para el compiladore pero nada que requiera
alojamiento en memoria ya sea generando cdigo o creando variables. Esto es as porque
el fichero de cabecera normalmente se incluye en varias unidades de traduccin en un
mismo proyecto, y si el almacenamiento para un identificador se pide en ms de un sitio,
el enlazador indicar un error de definicin mltiple (sta es la regla de definicin nica de
C++: Se puede declarar tantas veces como se quiera, pero slo puede haber una definicin
real para cada cosa).

Esta norma no es completamente estricta. Si se define una variable que es file static
(que tiene visibilidad slo en un fichero) dentro de un fichero de cabecera, habr mltiples
instancias de ese dato a lo largo del proyecto, pero no causar un colisin en el enlazador
[51]. Bsicamente, debe evitar cualquier cosa en los ficheros de cabecera que pueda
causar una ambigedad en tiempo de enlazado.


Cmo usar #include en C y C++

La directiva de preprocesador #include se usa en los lenguajes C y C++para incluir las
declaraciones de otro fichero en la compilacin. Esta directiva no tiene ms misterio para
proyectos pequeos. En cambio, puede ayudar aprovechar bien esta directiva en
proyectos con un gran nmero de subdirectorios.
El efecto de #include
Cuando el preprocesador encuentra una lnea #include "fichero", entonces reemplaza
esta lnea por el fichero incluido. As procede con todas las directivas de inclusin
tambin en aquellas anidadas en los fichero ya a su vez incluidos. Es decir, existe un slo
fichero grande tras la precompilacin.
No obstante, esta unin de varios ficheros no tiene lugar fsicamente. Lo que sucede es
que se interrumpe la compilacin del fichero actual, se compila el fichero incluido y, tras
compilarlo, se contina con el primero. Por eso, el compilador puede decirnos, en qu
fichero tuvo lugar un error de compilacin.
En cambio, conviene tener esta idea del fichero nico en mente, porque a veces ayuda a
encontrar errores. Uno muy tpico es olvidarse el punto y coma tras la declaracin de una
clase.
En este caso hay una declaracin de clase en el fichero incluido:
class MiClase {}
En el segundo puede haber algo as:
1
2
#include "mi_clase.h"
MiClase miInstancia;
En este ejemplo, el compilador se quejar de que aqu no se puede definir un nuevo tipo
en la lnea de MiClase miInstancia aunque esta lnea es correcta. El error verdadero es la
falta del ; en el fichero incluido. Lo que el compilador realmente ve es
class MiClase {} MiClase miInstancia;
No obstante, el programador no lo ve, porque el cdigo est distribuido sobre dos fichero
y el error se produce en el correcto.
La precompilacin slo modifica el cdigo a nivel textual. No entiende del sintaxis del
lenguaje. Por eso es posible distribuir el cdigo de forma arbitraria. Por ejemplo, el
siguiente ejemplo compilara.
Fichero incluido
1
2
{
int
Fichero principal
1
2
3
4
void main(void)
#include "fichero_incluido"
a;
}
Esto es as porque el compilador ve el conunto
1
2
3
4
5
void main(void)
{
int
a;
}
La posicin del #include
Lo habitual es posicionar las inclusiones al inicio de cada fichero. Esto tiene sentido,
porque se suele requerir declaraciones bsices antes de declarar clases ms complejas. Mi
lugar preferido en los ficheros de cabecera es tras el guardin de inclusin mltiple.
1
2
3
4
5
6
7
// Guardian de inclusin mltiple
#ifndef FICHERO_YA_INCLUIDO
#define FICHERO_YA_INCLUIDO

#include "declaraciones_basicas.h"

#endif
As se evita que un compilador poco sofisticado abre otra vez el mismo conjunto de
ficheros cuando se inluye un fichero de cabecera dos o ms veces.
En los ficheros de definicin (los .c o .cpp), los guardianes de inclusin mltiple no hacen
falta. No obstante, puede haber una restriccin importante cuando se usan cabeceras
precompiladas. En este caso, todos los ficheros fuente deben incluir primero el mismo
fichero de cabecera que es aquello que define la cabecera precompilada. El compilador
de C++ de Borland permite varios ficheros de cabecera para la definicin de una cabecera
precompilada. Estas inclusiones deben ser lor primeros ficheros incluidos y se deben
incluir en el mismo orden.
Puede darse el caso de no poner las inclusiones en el inicio de un fichero. Esto es
frecuente en los fichero que se podran denominar programados en directivas de
precompilacin. Normalmente se trata de ficheros de cabeceras con definiciones muy
bsicas como ajustes a la plataforma empleada. Por ejemplo, en medio de un fichero
definiciones_basicas.h puede haber unas lneas
1
2
3
4
5
6
7
8
9
#if PLATAFORMA_ES_LINUX
#include "funcionalidad_gratis.h"
#elif PLATAFORMA_ES_MICROSOFT_WINDOWS
#include "funcionalidad_cara.h"
#elif PLATAFORMA_ES_APPLE
#include "funcionalidad_muy_cara.h"
#else
#error Esta plataforma no est soportada
#endif
La diferencia entre y <>
La directiva #include existe en dos versiones. En una se pone el nombre de fichero
entre comillas, en la otra entre parntesis angulares (el signo menor y mayor como
comillas).
1
2
#include "fichero_con_comillas.h"
#include <fichero_entre_menor_y_mayor.h>
La versin con los parntesis angulares busca los ficheros en todos los directorios que se
han especificado en la llamada al compilador normalmente con la opcin -I. Estos
directorios se suelen rastrear por el fichero incluido en el orden en que aparecen en la
lnea de comando.
Cuando se incluye un fichero entre comillas, entonces el compilador busca este fichero
primero en el mismo directorio que el fichero actualemente compilado y despus en los
dems directorios. Es decir, la versin con comillas se diferencia de la versin con
parntesis angulares nicamente por buscar primero en el directorio del fichero
compilado. Tras no encontrarlo ah acta igual.
Esto muchas veces no es ninguna diferencia, ya que se suelen especificar todos los
directorios en la lnea de comando del compilador. As no se suele dar el caso que se
puede incluir un fichero con comillas pero no con parntesis angulares.
Ms significativo es el comportamiento ante ficheros con el mismo nombre en distintos
directorios. En este caso la versin con comillas da preferencia sobre el fichero en el
mismo directorio y esto suele ser el mejor acertado. Aunque sea preferible nombrar
ficheros de forma nica en un proyecto, es posible que no se pueda evitar tener dos
ficheros con el mismo nombre cuando se incluyen varias bibliotecas de terceros.
De ah se puede deducir que es imperativo incluir cabeceras de la misma biblioteca con
comillas. De esta forma se puede asegurar que las cabeceras de una biblioteca se incluyan
entre si aunque haya otros con el mismo nombre en uno de los directorios especificados
en la lnea de comandos.
Adems, incluir con comillas puede dar al programador un significado adicional: que este
fichero est bajo la custodia de mi equipo de desarrollo. Las cabeceras incluidas con
parntesis angulares son de bibliotecas de terceros. Los primeros ficheros puedo
modificar si hace falta, los segundos no.
El orden de las inclusiones
El orden de las directivas #include no importa cuando todos los identificadores del
programa son nicos. No obstante, a veces no lo son yconviene generar el error este
identificador ya existe en nuestro cdigo y no en el cdigo de una biblioteca estndar.
Esto se consigue incluyendo primero las caberas de terceros. Si aparece un error de
identificador doble, entonces aparece en la segunda definicin que es la nuestra y ah
podemos cambiar el nombre del objeto sin problema.
En proyectos realmente grandes puede haber varias bibliotecas de distintas
dependencias. Por la misma razn de generar los errores de identificadores dobles en el
cdigo ms fcilmente modificable, conviene incluir las bibliotecas ms bsicas primero.
Dentro del mismo nivel podemos ordenar los ficheros incluidos de forma alfabtica. Esto
ayuda a encontrar inclusiones que faltan o sobran.
El siguiente cdigo muestra una secuencia de inclusiones para un fichero
definicion_de_mi_clase.cpp.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
// Primero se debe incluir la cabecera de precompilacin
#include "cabecera_de_precompilacion.h"

// Segundo, incluir la cabecera correspondiente
// a este fichero de implementacin.
// Esto deja ms claro, que es la
// clase que se implementa aqu.
#include "definicion_de_mi_clase.h"

// A continuacin inclusiones de la biblioteca estndar.
// Se usan parntesis angulares.
#include <vector>

// Inclusiones de otras bibliotecas de terceros
#include <wx.h>
#include <gl.h>

// Inclusiones de subbibliotecas bsicas de
// mi proyecto con comillas
#include "mis_definiciones_basicas.h"

// Luego las dems inclusiones de mi proyecto
#include "clases_auxiliares.h"
#include "ms_definiciones_para_mi_clase.h"
Usar rutas relativas
Una forma de evitar nombres de fichero dobles es incluir ficheros con rutas relativas.
1
2
#include "definiciones/tipos_bsicos.h"
#include "funcionalidad/tipos_bsicos.h"
La desventaja de esta forma es, que uno debe saber, en qu directorio se encuentra cada
cabecera. No obstante, esto suele ser un problema menor. Sin ruta relativa, uno debera
poner un prefijo a cada nombre de fichero para evitar nombres dobles. Estos prefijos son
tpicamente los nombres de los directorios. Es decir, todos los ficheros en el directorio
definiciones tienen se llaman definiciones_xxx. Al final debo saber el nombre de
directorio de todas formas.
Los programadores de C++ han copiado de Java la idea de estructurar los directorios
como los espacios de nombre. As, el uso de la
claseNombreDeEspacio::Subespacio::MiClase requiere la inclusin del fichero
nombre_de_espacio/subespacio/mi_clase.h.
El uso de rutas relativas en las inclusiones puede mejorar bastante el orden y reducir la
configuracin del compilador. As basta incluir un solo directorio para obtener acceso a
todos los componentes de la biblioteca boost, por ejemplo. En cambio, rutas relativas
hacen ms complicado recolocar ficheros a otros directorios. Y esto puede pasar a
menudo en fases tempranos de un proyecto.
Optimizar la velocidad de compilacin
La inclusin de un slo fichero normalmente no afecta mucho al tiempo, que el
compilador requiere para la compilacin de un fichero. Pero esto se cambia si el fichero
incluido incluye ms ficheros que a su vez incluyen an ms ficheros. Gracias a tantas
inclusiones anidadas, una sola inclusin, s, puede cambiar el tiempo de compilacin
drsticamente.
Una forma de mejorar la velocidad es utilizar cabeceras precompiladas. Estas cabeceras
deben estar incluidas por todos los ficheros de definicin y, por eso, debe ser una decisin
temprana en un proyecto de utilizarlas o no al menos si uno quiere evitar aadir esta
inclusin en muchos ficheros.
Otra forma es evitar la inclusin de ficheros no necesarios. Normalmente una inclusin
adicional no perjudica al resultado de la compilacin. Simplemente aade declaraciones
que finalmente no se usan. Pero la compilacin de estas declaraciones cuesta un tiempo
que nos queremos ahorrar.
Para proyectos grandes puede convenir no incluir definiciones de tipos que slo aparecen
como punteros o referencias en los ficheros de cabecera. Esto tipos se pueden introducir
con una declaracin forward. Slo en el fichero de definicin se incluye entonces la
cabecera que define este tipo.
Como ejemplo damos una clase, que guarda un puntero a otra clase. En el fichero de
cabecera tenemos
1
2
3
4
5
6
7
8
// Declaracin forward
class OtraClase;

// Declaracin de la clase principal
class UnaClase
{
OtraClase* dame_un_puntero_a_otra_clase();
};
En el fichero de definicin tenemos
1
2
3
4
#include "una_clase.h"
#include "otra_clase.h"

OtraClase* UnaClase::dame_un_puntero_a_otra_clase()
5
6
7
8
{
static OtraClase otraInstancia;
return &otraInstancia;
}
Cabe sealar que una declaracin forward debe tener lugar dentro del nombre de
espacio correspondiente.
1
2
3
4
5
6
7
8
9
10
11
// Esto no es correcto
class NombreDeEspacio::Subespacio::Clase;

// Se debe hacer la declaracin forward as
namespace NombreDeEspacio
{
namespace Subespacio
{
class Clase;
}
}
Conclusin
Como hemos comprobado, hay bastante que se puede tener en cuenta sobre la
directiva #include, cuando se trabaja en proyectos grandes.
La inclusin genera un slo fichero grande. Tener esto en mente cuando se produce
un error de compilacin en la primera lnea aparamente correcta tras un #include.
Conviene incluir ficheros del propio proyecto con comillas y las cabeceras de terceros
con parntesis angulares para marcar la diferencia entre propio y estndar.
Ordenando las propias inclusiones al final ayuda a corregir errores de doble
definicin de identificadores.
Rutas relativas son una buena opcin para proyectos con una clara estructura de
directorios.
Usar cabeceras precompiladas y evitar incluir ficheros innecesarios tambin
aprovechando declaraciones forward puede acelerar el proceso de compilacin.