13.01.2015 Views

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

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

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

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

✐<br />

✐<br />

✐<br />

“Volum<strong>en</strong>1” — 2012/1/12 — 13:52 — page 162 — #200<br />

✐<br />

Capítulo 4. Abstracción de Datos<br />

Como puede ver, la primera vez que se incluye el fichero de cabecera, los cont<strong>en</strong>idos<br />

del fichero (incluy<strong>en</strong>do la declaración del tipo) son incluidos por el preprocesador.<br />

Las demás veces que se incluya -<strong>en</strong> una única unidad de programación- la<br />

declaración del tipo será ignorada. El nombre HEADER_FLAG puede ser cualquier<br />

nombre único, pero un estándar fiable a seguir es poner el nombre del fichero de<br />

cabecera <strong>en</strong> mayúsculas y reemplazar los puntos por guiones bajos (sin embargo, el<br />

guión bajo al comi<strong>en</strong>zo está reservado para nombres del sistema). Este es un ejemplo:<br />

//: C04:Simple.h<br />

// Simple header that prev<strong>en</strong>ts re-definition<br />

#ifndef SIMPLE_H<br />

#define SIMPLE_H<br />

struct Simple {<br />

int i,j,k;<br />

initialize() { i = j = k = 0; }<br />

};<br />

#<strong>en</strong>dif // SIMPLE_H ///:~<br />

Aunque el SIMPLE_H después de #<strong>en</strong>dif está com<strong>en</strong>tado y es ignorado por el<br />

preprocesador, es útil para docum<strong>en</strong>tación.<br />

Estas s<strong>en</strong>t<strong>en</strong>cias del preprocesador que impid<strong>en</strong> inclusiones múltiples se d<strong>en</strong>ominan<br />

a m<strong>en</strong>udo guardas de inclusión (include guards)<br />

4.7.5. Espacios de nombres <strong>en</strong> los ficheros de cabecera<br />

Notará que las directivas using están pres<strong>en</strong>tes <strong>en</strong> casi todos los ficheros cpp de<br />

esto libro, normalm<strong>en</strong>te <strong>en</strong> la forma:<br />

using namespace std;<br />

Como std es el espacio de nombres que <strong>en</strong>cierra la librería Estándar <strong>C++</strong> al completo,<br />

esta directiva using <strong>en</strong> particular permite que se puedan usar los nombres de<br />

la librería Estándar <strong>C++</strong>. Sin embargo, casi nunca verá una directiva using <strong>en</strong> un<br />

fichero de cabecera (al m<strong>en</strong>os, no fuera de un bloque). La razón es que la directiva<br />

using elimina la protección de ese espacio de nombres <strong>en</strong> particular, y el efecto dura<br />

hasta que termina la unidad de compilación actual. Si pone una directiva using<br />

(fuera de un bloque) <strong>en</strong> un fichero de cabecera, significa que esta perdida de «protección<br />

del espacio de nombres» ocurrirá con cualquier fichero que incluya este fichero<br />

de cabecera, lo que a m<strong>en</strong>udo significa otros ficheros de cabecera, es muy fácil acabar<br />

«desactivando» los espacios de nombres <strong>en</strong> todos sitios, y por tanto, neutralizando<br />

los efectos b<strong>en</strong>eficiosos de los espacios de nombres.<br />

En resum<strong>en</strong>: no ponga directivas using <strong>en</strong> ficheros de cabecera.<br />

4.7.6. Uso de los ficheros de cabecera <strong>en</strong> proyectos<br />

Cuando se construye un proyecto <strong>en</strong> <strong>C++</strong>, normalm<strong>en</strong>te lo creará poni<strong>en</strong>do juntos<br />

un montón de tipos difer<strong>en</strong>tes (estructuras de datos con funciones asociadas).<br />

Normalm<strong>en</strong>te pondrá la declaración para cada tipo o grupo de tipos asociados <strong>en</strong><br />

un fichero de cabecera separado, <strong>en</strong>tonces definirá las funciones para ese tipo <strong>en</strong> una<br />

162<br />

✐<br />

✐<br />

✐<br />

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!