2010-12-11 21 views
5

supongamos que tengo una cabecera foo.h así:Cómo volver a incluir encabezado en aplicación

#ifndef FOO_H 
#define FOO_H 
#include <string> 
#include "non_standard_class.h" 

std::string foo(MyClass a); 
... 
#endif 

y la implementación foo.cpp habrá

#include <vector> 

#include "foo.h" 

std::string foo(MyClass a) 
{ 
    std::vector<int> x; 
    MyClass b; 
    ... 
} 

es una buena pratice volver a incluir <string> y non_standard_class.h en foo.cpp ? El punto es: si leo foo.cpp, ¿cómo puedo entender de dónde viene MyClass? Necesito mirar foo.h pero será más difícil.

+1

¿Por qué sería una buena práctica escribir todo dos veces?Eso sería una pesadilla de mantenimiento. – jwueller

+0

Es realmente bueno, y no esencial, práctica si no vas a incluir foo.h en foo.cpp ... – Goz

+2

@Goz: Pero en general, no incluir 'foo.h' en' foo.cpp' es en sí mismo práctica cuestionable. –

Respuesta

7

La práctica I sigue:

  • foo.h debe incluir directamente todos los encabezados de sus necesidades de código fuente (es decir #include <string> si hay std::string en foo.h)
  • foo.cpp debe incluir directamente foo. h más todos los demás encabezados que necesita su propio código fuente, excepto los que ya incluye directamente foo.h

Otra formulación de esta práctica: en foo. *, incluya solo los encabezados que necesite el código fuente. Si solo se necesita un encabezado por foo.cpp (pero no por foo.h), inclúyalo desde foo.cpp, de lo contrario, inclúyalo desde foo.h.

Por lo tanto, en su caso, no me #include <string> en foo.cpp, porque ya está incluido por foo.h.

Supongamos que string hace un #include <vector>, y foo.h contiene std::vector. En este caso, tendría #include <vector> en foo.h, porque su código fuente lo necesita – y no importa que string ya lo incluya.

1

Yo diría que sí, porque de lo contrario su foo.cpp se basa en un detalle de foo.h que puede cambiar. Obviamente, esto es más un problema con otros archivos .h que no están bajo tu control, pero aún así lo hago por consistencia.

+0

-1, porque esto introduce un trabajo de mantenimiento adicional, y 'foo.cpp' y' foo.h' difícilmente van a cambiar de forma independiente - son los archivos correspondientes –

+0

Y además de eso, puede presentar más trabajo para el compilador si se aplica de manera consistente en un proyecto. –

+0

Si cree que incluir un archivo dos veces introduce un trabajo adicional significativo para los mantenedores y el compilador, necesita mejores mantenedores * y * un mejor compilador. –

2

Personalmente, sigo la práctica de inclusión mínima (cuestionable): solo incluyo lo que se necesita para que la compilación funcione.

Las personas que dicen que para obtener un mejor compilador/máquina me hacen reír, de alguna manera, el proyecto en el que estoy trabajando diariamente se compila en aproximadamente 8 minutos (desde cero) en un quad-core (fue de aproximadamente 1 hora antes Eliminé las dependencias) y me parece demasiado malditamente. Ciertamente no quiero ningún cambio para hacer que todo vuelva a compilarse, y por lo tanto estoy preocupado de incluir.

Durante el desarrollo, siempre siento que el tiempo de compilación es tiempo perdido. Un poco podría permitir un descanso seguro, pero cuando quieres probar algo ahora, es frustrante esperar a que la maldita cosa esté finalmente lista (especialmente si solo suena en tu mano cuando realizas las pruebas y te das cuenta de que tendrás que modificar de nuevo y vuelva a compilar nuevamente).

Incluir las cosas dos veces parece ser una buena manera de olvidarse de eliminar el include de la fuente cuando ya no es necesario por el encabezado (hurrah for forward declaration), no veo el punto.

Cuestiones relacionadas