c++ - oficial - Organizar incluye

mac os mojave

Question

• ¿Hay alguna forma preferida de organizar las directivas incluidas?
• ¿Es mejor incluir los archivos que necesita en el archivo .cpp lugar del archivo .h ? ¿Las unidades de traducción están afectadas de alguna manera?
• ¿Qué tal si lo necesito tanto en el archivo .h como en el archivo .cpp , debería simplemente incluirlo en el archivo .h ? ¿Importará?
• ¿Es una buena práctica mantener los archivos ya definidos en un encabezado precompilado ( stdafx.h ), por ejemplo, bibliotecas stdafx.h y de terceros? ¿Qué hay de mis propios archivos? ¿Debería incluirlos en un archivo stdafx.h mientras los creo?

// myClass.h
#include <string>
// ^-------- should I include it here? --------

class myClass{
    myClass();
    ~myClass();

    int calculation()
};

// myClass.cpp
#include "myClass.h"
#include <string>
//  ^-------- or maybe here?  --------

[..]

int myClass::calculation(){
    std::string someString = "Hello World";
    return someString.length();
}


// stdafx.h
#include <string.h>
// ^--------- or perhaps here, and then include stdafx.h everywhere? -------

Answer 1

¿Hay alguna forma preferida de organizar las directivas incluidas?

No hay convenciones comunes. Algunos sugieren clasificarlos en orden alfabético, yo personalmente no me gusta y prefiero mantenerlos agrupados lógicamente.

¿Es mejor incluir los archivos que necesita en el archivo .cpp en lugar del archivo .h?

En general sí. Reduce el número de veces que el compilador necesita abrir y leer el archivo de encabezado solo para ver las guardas de inclusión allí. Eso puede reducir el tiempo total de compilación. Algunas veces, también se recomienda reenviar y declarar tantas clases como sea posible en los encabezados y en realidad incluirlas solo en .cpp, por la misma razón. La "gente Qt" lo hace, por ejemplo.

¿Las unidades de traducción están afectadas de alguna manera?

En sentido semántico, no.

¿Qué tal si lo necesito tanto en el archivo .h como en el archivo .cpp, debería simplemente incluirlo en el archivo .h? ¿Importará?

Sólo tienes que incluirlo en el encabezado.

¿Es una buena práctica mantener los archivos ya definidos en un encabezado precompilado (stdafx.h), por ejemplo, bibliotecas estándar y de terceros? ¿Qué hay de mis propios archivos? ¿Debería incluirlos en un archivo stdafx.h mientras los creo?

Los encabezados precompilados pueden reducir significativamente los tiempos de compilación. Por ejemplo: uno de mis proyectos que incluye boost::spirit::qi compila en 20 segundos con PCH activado y 80 segundos sin él. En general, si usa una biblioteca con muchos rellenos de plantillas como el boost , desearía utilizar la ventaja de PCH.

En cuanto a la pregunta en el ejemplo de código: como no usa std :: string en el encabezado, es mejor incluirlo en el archivo .cpp . También está bien #include <string> en stdafx.h - pero eso solo agregará un poco de complejidad a su proyecto y casi no notará ninguna aceleración en la compilación.

Answer 2

1. Debe tenerlos en la parte superior del archivo, todo en un solo lugar. Esto es lo que todos esperan. Además, es útil agruparlos, por ejemplo, primero todos los encabezados estándar, luego los encabezados de terceros (agrupados por biblioteca) y luego sus propios encabezados. Mantenga este orden constante a lo largo del proyecto. Facilita la comprensión de las dependencias. Como lo señala @James Kanze, también es útil colocar el encabezado que declara el contenido primero. De esta manera, se asegura de que funcione si se incluye primero (lo que significa que no depende de ninguno que no se incluya a sí mismo).
2. Mantenga el alcance lo más pequeño posible, de modo que un cambio en el encabezado afecte al menor número de unidades de traducción. Esto significa que, siempre que sea posible, inclúyalo solo en el archivo cpp . Como comentó @Pedro d''Aquino, puede reducir el número de inclusiones en un encabezado utilizando declaraciones hacia adelante siempre que sea posible (básicamente, siempre que use referencias o punteros a un tipo determinado).
3. Ambos - explícito es mejor que implícito.
4. Después de algunas lecturas, creo que solo debe incluir encabezados en el PCH si está seguro de que ya no cambian. Esto se aplica a todos los encabezados estándar, así como (probablemente) a las bibliotecas de terceros. Para tus propias bibliotecas, tú eres el juez.

Answer 3

(4) No recomendaría incluir ningún archivo adicional en stdafx.h. o archivos similares "include_first.h". La inclusión directa en cpp o archivos h particulares le permite expresar explícitamente las dependencias de su código y excluir las dependencias redundantes. Es especialmente útil cuando decides descomponer el código monolítico en unas pocas bibliotecas o archivos DLL. Personalmente, uso archivos como "include_first.h" (stdafx.h) solo para fines de configuración (este archivo contiene solo definiciones de macro para la configuración de la aplicación actual).
Es posible proporcionar encabezados precompilados para sus propios archivos marcando otro archivo para detener la precompilación en lugar de stdafx.h (por ejemplo, puede usar un archivo vacío especial denominado "stop_pch.h").
Tenga en cuenta que los encabezados precompilados pueden no funcionar correctamente para algunos tipos de uso sofisticado del preprocesador (en particular, para algunas técnicas utilizadas en BOOST_PP_ * )

Answer 4

Desde el punto de vista del rendimiento:

Cambiar cualquiera de los encabezados incluidos desde stdafx.h activará una nueva precompilación, por lo que depende de qué tan "congelado" esté el código. Las bibliotecas externas son candidatos típicos para la inclusión de stdafx.h, pero también puede incluir sus propias bibliotecas, es un compromiso basado en la frecuencia con la que espera cambiarlas.

Además, con el compilador de Microsoft puede poner esto en la parte superior de cada archivo de encabezado:

#pragma once

Esto permite al compilador omitir completamente ese archivo después de la primera aparición, guardando las operaciones de E / S. El patrón tradicional de ifndef / define / endif requiere abrir y analizar el archivo cada vez que se incluye, lo que por supuesto lleva algún tiempo. ¡Sin duda puede acumularse y hacerse perceptible!

(Asegúrese de dejar a los guardias tradicionales allí, para la portabilidad).

Answer 5

Este artículo en el archivo de encabezado que incluye patrones debería ser útil para usted.

• ¿Hay alguna forma preferida de organizar las directivas incluidas?

Sí , puedes encontrarlos en el artículo anterior.

• ¿Es mejor incluir los archivos que necesita en el archivo .cpp en lugar del archivo .h? ¿Las unidades de traducción están afectadas de alguna manera?

Sí , es mejor tenerlos en .cpp. Incluso, si se requiere un tipo definido en la definición de otro tipo, puede usar la declaración hacia adelante.

• ¿Qué tal si lo necesito tanto en el archivo .h como en el archivo .cpp, debería simplemente incluirlo en el archivo .h? ¿Importará?

Solo en el archivo .h , pero se sugiere reenviar declarar en archivos de encabezado e incluir en archivos .cpp.

• ¿Es una buena práctica mantener los archivos ya definidos en un encabezado precompilado (stdafx.h), por ejemplo, bibliotecas estándar y de terceros? ¿Qué hay de mis propios archivos? ¿Debería incluirlos en un archivo stdafx.h mientras los creo?

Personalmente no he usado encabezados precompilados, pero anteriormente se ha discutido sobre ellos en :

Encabezados precompilados? ¿Realmente los necesitamos?

Answer 6

Podría ser importante notar que el orden de las clases en la Unidad de traducción debe ser correcto o que algunas características de c ++ están deshabilitadas y resultan en un error en tiempo de compilación.

Editar: Añadiendo ejemplos:

class A { };
class B { A a; }; // order of classes need to be correct