Lo sé para evitar la inclusión múltiple del archivo de encabezado. Pero supongamos que me aseguro de incluir este archivo en solo un archivo .cpp solo una vez. ¿Todavía hay escenarios en los que necesitaría esta protección?Propósito de #ifndef FILENAME .... # endif en el archivo de encabezado
Puede garantizar que su código sólo incluye una vez, pero se puede garantizar que el código cualquiera 's incluirá una vez?
Por otra parte, imaginar esto:
// a.h
typedef struct { int x; int y; } type1;
// b.h
#include "a.h"
typedef struct { type1 old; int z; } type2;
// main.c
#include "a.h"
#include "b.h"
Oh, no! Nuestra main.c solo incluyó una vez, pero b.h incluye a.h, por lo que obtuvimos a.h dos veces, a pesar de nuestros mejores esfuerzos.
Ahora imagine esta escondido detrás de tres o más capas de #include s y es un menor uso interno de sólo encabezado que vaya a incluirse dos veces y es un problema porque una de las cabeceras #undef ed una macro que se define, pero la segunda cabecera #define d de nuevo y rompió un código y se necesita un par de horas para averiguar por qué hay definiciones contradictorias de las cosas.
No, ese es el único propósito de las protecciones incluidas, pero usarlas debería ser una obviedad: hacerlo requiere poco tiempo y potencialmente ahorra mucho.
Esa es su única razón de ser. Todavía es una buena idea, incluso si cree que tiene eso cubierto; no reduce la velocidad de tu código ni nada, y nunca está de más tener una guardia adicional.
El propósito del protector es evitar que el archivo sea re incluido en el mismo archivo .cpp más de una vez. No protege contra incluir el archivo en más de un archivo .cpp.
Si está seguro de que un archivo de encabezado no está incluido en otro archivo de encabezado, entonces no se requiere el resguardo. pero sigue siendo una buena forma.
forma aún mejor es utilizar
#pragma once
si su compilador lo soporta.
El protector de inclusión es mejor en mi humilde opinión porque es más portátil. Evito depender de características específicas del compilador como la plaga. –
@Chris: la portabilidad es importante para el código fuente abierto. Pero generalmente no es para fuente cerrada. #pragma una vez es más confiable y más rápido que los guardias porque el compilador en realidad puede 'skip_' volver a explorar el archivo. Ese es el tipo de cosas que realmente importa en una tienda de código cerrado. –
GCC en realidad optimiza la expresión de incluir guardia para hacer esencialmente lo mismo. Pero estoy de acuerdo en que, para una base de código de código cerrado con Visual Studio, '#pragma once' es bastante bueno. –
Garantizar que su código se incluye una sola vez es el único propósito de un llamado "protector de encabezado".
Esto puede ser útil como si hubiera una dependencia circular entre los archivos de encabezado, no quede atrapado en un bucle sin fin de archivos incluidos.
El escenario adicional en el que puedo pensar (y lo hicimos) es crear simulaciones de C++.
Usted explícitamente en su compilación define el valor GUARD del archivo y luego puede agregar su propia realización simulada a través de -include my_mock.h como la opción del compilador adicional (usamos g ++).
my_mock.h
#define THAT_FILE_GUARD
class ThatClass
{
void connect()
{
std::cout << "mock connect" << std::endl;
}
}
El uso de un protector de cabecera como esto acelera el proceso de compilación, imaginar tener tres archivos de origen utilizando el encabezado (menos el guardia de cabecera), que a su vez significaría que el compilador tendría que incluir la cabecera (análisis sintáctico y leer la sintaxis) varias veces.
Con un protector de encabezado, el compilador dirá '¡Ja! He visto este antes, y no voy a analizar/leer la sintaxis, lo que acelera el proceso de compilación.
Espero que esto ayude, Saludos cordiales, Tom.
Gracias a todos. Chris lo entiende por ser elaborado :) – deeJ
La próxima vez que necesite romper mi límite de reputación, solo recordaré publicar mientras procrastino mi tarea. :) –