terminar - donde debe "incluir" ser puesto en C++
que se debe adjuntar en un curriculum vitae (9)
Estoy leyendo un código de C ++ y observe que hay "#include" tanto en los archivos de encabezado como en los archivos .cpp. Supongo que si muevo todo el "#include" en el archivo, digamos foo.cpp, también su ''archivo de encabezado foo.hh y deje que foo.cpp solo incluya foo.hh el código debería funcionar de todos modos sin tener en cuenta problemas como inconvenientes, eficiencia y etc.
Sé que mi idea "repentina" debe ser de alguna manera una mala idea, pero ¿cuáles son los inconvenientes exactos de la misma? Soy nuevo en c ++, así que no quiero leer muchos libros en C ++ antes de poder responder esta pregunta yo solo. así que solo deje la pregunta aquí por su ayuda. gracias por adelantado.
Haría que todos los demás archivos, incluido su archivo de encabezado, incluyeran transititivamente todos los #include en su encabezado también.
En C ++ (como en C) #include es manejado por el preprocesador simplemente insertando todo el texto en el archivo #include d en lugar de la instrucción #include . Así que con muchos #include s puede literalmente alardear del tamaño de su archivo compilable en cientos de kilobytes, y el compilador necesita analizar todo esto para cada archivo. Tenga en cuenta que el mismo archivo incluido en diferentes lugares debe volver a repararse en cada lugar donde se encuentre #include d! Esto puede ralentizar la compilación a un rastreo.
Si necesita declarar (pero no definir) elementos en su encabezado, use la declaración forward en lugar de #include s.
Incluir archivos de encabezado desde archivos de encabezado está bien, por lo que se incluye en archivos c ++, sin embargo, para minimizar los tiempos de compilación, generalmente es preferible evitar incluir un archivo de encabezado dentro de otro encabezado a menos que sea absolutamente necesario especialmente si muchos archivos c ++ incluyen el mismo encabezado.
Los archivos .hh (o .h) se supone que son para declaraciones.
Se supone que los archivos .cpp (o .cc) son para definiciones e implementaciones.
Primero dése cuenta de que una declaración #include es literal . #include "foo.h" literalmente copia el contenido de foo.h y lo pega donde la directiva include está en el otro archivo.
La idea es que algunos otros archivos bar.cpp y baz.cpp quieran utilizar algún código que exista en foo.cc. La forma de hacer eso, normalmente, sería que bar.cpp y baz.cpp incluyeran #include "foo.h" para obtener las declaraciones de las funciones o clases que querían usar, y luego, en el momento del enlace, el enlazador conectar estos usos en bar.cpp y baz.cpp a las implementaciones en foo.cpp (ese es el punto principal del enlazador).
Si pones todo en foo.h e intentas hacer esto, tendrías un problema. Digamos que foo.h declara una función llamada doFoo() . Si la definición (código para) esta función está en foo.cc, está bien. Pero si el código para doFoo() se mueve a foo.h, y luego incluye foo.h dentro de foo.cpp, bar.cpp y baz.cpp, ahora hay tres definiciones para una función llamada doFoo() , y su El enlazador se quejará porque no se le permite tener más de una cosa con el mismo nombre en el mismo alcance.
Los archivos de inclusión en un encabezado solo deben ser los necesarios para admitir ese encabezado. Por ejemplo, si su encabezado declara un vector, debe incluir vector, pero no hay razón para incluir una cadena. Debería poder tener un programa vacío que solo incluye ese único archivo de encabezado y se compilará.
Dentro del código fuente, necesita incluir todo lo que llame, por supuesto. Si ninguno de sus encabezados requiere iostream pero lo necesita para la fuente real, debe incluirse por separado.
Incluir la contaminación de archivos es, en mi opinión, una de las peores formas de descomposición del código.
editar: Heh. Parece que el analizador come los símbolos> y <.
No hay nada de malo con el uso de #include en un archivo de encabezado. Es una práctica muy común, no desea cargar una biblioteca a un usuario con recordar también qué otros encabezados oscuros se necesitan.
Un ejemplo estándar es #include <vector> . Obtiene la clase de vector. Y una gran cantidad de archivos internos de encabezado CRT que se necesitan para compilar correctamente la clase vectorial, cosas que realmente no necesita ni quiere saber.
Puede evitar múltiples errores de definición si usa "incluir guardias".
(begin myheader.h)
#ifndef _myheader_h_
#define _myheader_h_
struct blah {};
extern int whatsit;
#endif //_myheader_h_
Ahora bien, si #incluye "myheader.h" en otros archivos de encabezado, solo se incluirá una vez (debido a que se está definiendo _myheader_h_). Creo que MSVC tiene un "#pragma una vez" con la funcionalidad equivalente.
Si #incluye los archivos .cpp, probablemente terminará con muchos errores de "definición múltiple" del vinculador. En teoría, # puede incluir todo en una sola unidad de traducción, pero eso también significa que todo debe reconstruirse cada vez que realice un cambio en un solo archivo. Para proyectos del mundo real, eso es inaceptable, por lo que tenemos enlazadores y herramientas como make.
Si bien un archivo de encabezado debe incluir solo lo que necesita, "lo que necesita" es más fluido de lo que piensas, y depende del propósito al que le pones el encabezado. Lo que quiero decir con esto es que algunos encabezados son en realidad documentos de interfaz para bibliotecas u otro código. En esos casos, los encabezados deben incluir (y probablemente #incluir) todo lo que otro desarrollador necesitará para usar correctamente su biblioteca.
Como regla general, ponga sus inclusiones en los archivos .cpp cuando pueda, y solo en los archivos .h cuando eso no sea posible.
En muchos casos, puede utilizar declaraciones directas para eliminar la necesidad de incluir encabezados de otros encabezados: esto puede ayudar a reducir el tiempo de compilación, que puede convertirse en un gran problema a medida que su proyecto crece. Este es un buen hábito para comenzar desde el principio porque tratar de resolverlo en una fecha posterior (cuando ya es un problema) puede ser una pesadilla completa.
La excepción a esta regla son las clases (o funciones) con plantilla: para usarlas necesita ver la definición completa, lo que generalmente significa ponerlas en un archivo de encabezado.