¿Cuál es la diferencia entre #include y #include “filename”?

En los lenguajes de progtwigción C y C ++, ¿cuál es la diferencia entre usar corchetes angulares y usar comillas en una instrucción include , como se muestra a continuación?

  1. #include
  2. #include "filename"

En la práctica, la diferencia está en la ubicación donde el preprocesador busca el archivo incluido.

Para #include el preprocesador busca de una manera dependiente de la implementación, normalmente en directorios de búsqueda previamente designados por el comstackdor / IDE. Este método normalmente se usa para incluir archivos de encabezado de biblioteca estándar.

Para #include "filename" el preprocesador busca primero en el mismo directorio que el archivo que contiene la directiva, y luego sigue la ruta de búsqueda utilizada para el formulario #include . Este método normalmente se usa para incluir archivos de encabezado definidos por el progtwigdor.

Una descripción más completa está disponible en la documentación de GCC sobre rutas de búsqueda .

La única forma de saber es leer la documentación de su implementación.

En el estándar C , sección 6.10.2, los párrafos 2 a 4 dicen:

  • Una directiva de preprocesamiento de la forma

     #include  new-line 

    busca una secuencia de lugares definidos por la implementación para un encabezado identificado únicamente por la secuencia especificada entre los delimitadores < y > , y provoca la sustitución de esa directiva por todo el contenido del encabezado. Cómo se especifican los lugares o el encabezado identificado está definido por la implementación.

  • Una directiva de preprocesamiento de la forma

     #include "q-char-sequence" new-line 

    provoca la sustitución de esa directiva por el contenido completo del archivo fuente identificado por la secuencia especificada entre los " delimitadores." El archivo fuente nombrado se busca de una manera definida por la implementación. Si esta búsqueda no es compatible, o si la búsqueda falla , la directiva se reprocesa como si se lea

     #include  new-line 

    con la secuencia contenida idéntica (incluyendo > caracteres, si corresponde) de la directiva original.

  • Una directiva de preprocesamiento de la forma

     #include pp-tokens new-line 

    (que no coincide con ninguna de las dos formas anteriores) está permitido. Los tokens de preprocesamiento después de include en la directiva se procesan igual que en el texto normal. (Cada identificador actualmente definido como nombre de macro se reemplaza por su lista de reemplazo de tokens de preprocesamiento). La directiva resultante después de todos los reemplazos debe coincidir con una de las dos formas anteriores. El método por el cual se combina una secuencia de tokens de preprocesamiento entre un par de token de preprocesamiento < y a > o un par de " caracteres " en un token de preprocesamiento de nombre de encabezado único está definido por la implementación.

Definiciones:

  • h-char: cualquier miembro del conjunto de caracteres fuente excepto el carácter de nueva línea y >

  • q-char: cualquier miembro del juego de caracteres fuente excepto el carácter de nueva línea y "

La secuencia de caracteres entre se refiere únicamente a un encabezado, que no es necesariamente un archivo. Las implementaciones son más o menos libres de usar la secuencia de caracteres como lo deseen. (En su mayoría, sin embargo, simplemente trátelo como un nombre de archivo y realice una búsqueda en la ruta de inclusión , como indican las otras publicaciones).

Si se utiliza el formulario #include "file" , la implementación primero busca un archivo del nombre de stack, si es compatible. Si no (compatible), o si la búsqueda falla, la implementación se comporta como si se hubiera utilizado el otro #include ( #include ).

Además, existe un tercer formulario y se usa cuando la directiva #include no coincide con ninguno de los formularios anteriores. De esta forma, se realiza un preprocesamiento básico (como macro expansión) en los “operandos” de la directiva #include , y se espera que el resultado coincida con una de las otras dos formas.

Algunas buenas respuestas aquí hacen referencia al estándar C pero olvidaron el estándar POSIX, especialmente el comportamiento específico del comando c99 (por ejemplo, el comstackdor C) .

De acuerdo con The Open Group Base Specifications Issue 7 ,

-I directorio

Cambie el algoritmo para buscar encabezados cuyos nombres no sean nombres de ruta absolutos para buscar en el directorio nombrado por el nombre de ruta del directorio antes de buscar en los lugares habituales. Por lo tanto, los encabezados cuyos nombres están entre comillas dobles (“”) se buscarán primero en el directorio del archivo con la línea #include , luego en directorios nombrados en las opciones -I , y últimos en los lugares habituales. Para los encabezados cuyos nombres están entre corchetes angulares (“<>“), el encabezado se buscará solo en directorios nombrados en las opciones -I y luego en los lugares habituales. Los directorios nombrados en las opciones -I se buscarán en el orden especificado. Las implementaciones deben admitir al menos diez instancias de esta opción en una sola invocación de comando c99 .

Por lo tanto, en un entorno compatible con POSIX, con un comstackdor de C compatible con POSIX, es probable que #include "file.h" ./file.h primero ./file.h , donde . es el directorio donde está el archivo con la instrucción #include , mientras que #include , es probable que busque /usr/include/file.h primero, donde /usr/include es el sistema que define los lugares habituales para encabezados (parece que no está definido por POSIX).

Lo hace:

 "mypath/myfile" is short for ./mypath/myfile 

con . siendo el directorio del archivo donde está contenido #include , y / o el directorio de trabajo actual del comstackdor, y / o el default_include_paths

y

  is short for /mypath/myfile 

Si ./ está en , entonces no hace la diferencia.

Si mypath/myfile está en otro directorio de inclusión, el comportamiento no está definido.

La documentación de GCC dice lo siguiente sobre la diferencia entre los dos:

Los archivos de cabecera del usuario y del sistema se incluyen utilizando la directiva de preprocesamiento '#include' . Tiene dos variantes:

#include

Esta variante se usa para archivos de cabecera del sistema. Busca un archivo denominado archivo en una lista estándar de directorios del sistema. Puede anteponer directorios a esta lista con la opción -I (ver Invocación ).

#include "file"

Esta variante se usa para archivos de encabezado de su propio progtwig. Primero busca un archivo denominado archivo en el directorio que contiene el archivo actual, luego en los directorios de cotizaciones y luego en los mismos directorios utilizados para . Puede anteponer directorios a la lista de directorios de cotizaciones con la opción -iquote . El argumento de '#include' , ya sea delimitado con comillas o corchetes angulares, se comporta como una constante de cadena porque los comentarios no se reconocen y los nombres de macro no se expanden. Por lo tanto, #include especifica la inclusión de un archivo de encabezado del sistema llamado x/*y .

Sin embargo, si se producen barras inclinadas inversas dentro del archivo, se consideran caracteres de texto normales, no caracteres de escape. Ninguna de las secuencias de escape de caracteres apropiadas para las constantes de cadena en C se procesa. Por lo tanto, #include "x\n\\y" especifica un nombre de archivo que contiene tres barras diagonales inversas. (Algunos sistemas interpretan ‘\’ como un separador de ruta de acceso. Todos estos también interpretan '/' la misma manera. Es más portable usar solo '/' ).

Es un error si hay algo (que no sean comentarios) en la línea después del nombre del archivo.

El include le dice al preprocesador que busque primero en directorios -I y en directorios predefinidos, luego en el directorio del archivo .c. El "file" incluye le dice al preprocesador que busque primero en el directorio del archivo de origen y luego vuelva a -I y que -I predefinido. Todos los destinos se buscan de todos modos, solo el orden de búsqueda es diferente.

La norma 2011 principalmente analiza los archivos de inclusión en “16.2 Inclusión del archivo de origen”.

2 Una directiva de preprocesamiento de la forma

# include new-line

busca una secuencia de lugares definidos por la implementación para un encabezado identificado únicamente por la secuencia especificada entre los delimitadores , y provoca la sustitución de esa directiva por todo el contenido del encabezado. Cómo se especifican los lugares o el encabezado identificado está definido por la implementación.

3 Una directiva de preprocesamiento de la forma

# include "q-char-sequence" new-line

provoca la sustitución de esa directiva por el contenido completo del archivo fuente identificado por la secuencia especificada entre los “delimitadores.” El archivo fuente nombrado se busca de una manera definida por la implementación. Si esta búsqueda no es compatible, o si la búsqueda falla , la directiva se reprocesa como si se lea

# include new-line

con la secuencia contenida idéntica (incluyendo> caracteres, si corresponde) de la directiva original.

Tenga en cuenta que el formulario "xxx" degrada al formulario si no se encuentra el archivo. El rest está definido por la implementación.

Según el estándar, sí, son diferentes:

  • Una directiva de preprocesamiento de la forma

     #include  new-line 

    busca una secuencia de lugares definidos por la implementación para un encabezado identificado únicamente por la secuencia especificada entre los delimitadores < y > , y provoca la sustitución de esa directiva por todo el contenido del encabezado. Cómo se especifican los lugares o el encabezado identificado está definido por la implementación.

  • Una directiva de preprocesamiento de la forma

     #include "q-char-sequence" new-line 

    provoca la sustitución de esa directiva por el contenido completo del archivo fuente identificado por la secuencia especificada entre los " delimitadores." El archivo fuente nombrado se busca de una manera definida por la implementación. Si esta búsqueda no es compatible, o si la búsqueda falla , la directiva se reprocesa como si se lea

     #include  new-line 

    con la secuencia contenida idéntica (incluyendo > caracteres, si corresponde) de la directiva original.

  • Una directiva de preprocesamiento de la forma

     #include pp-tokens new-line 

    (que no coincide con ninguna de las dos formas anteriores) está permitido. Los tokens de preprocesamiento después de include en la directiva se procesan igual que en el texto normal. (Cada identificador actualmente definido como nombre de macro se reemplaza por su lista de reemplazo de tokens de preprocesamiento). La directiva resultante después de todos los reemplazos debe coincidir con una de las dos formas anteriores. El método por el cual se combina una secuencia de tokens de preprocesamiento entre un par de token de preprocesamiento < y a > o un par de " caracteres " en un token de preprocesamiento de nombre de encabezado único está definido por la implementación.

Definiciones:

  • h-char: cualquier miembro del conjunto de caracteres fuente excepto el carácter de nueva línea y >

  • q-char: cualquier miembro del juego de caracteres fuente excepto el carácter de nueva línea y "

Tenga en cuenta que la norma no indica ninguna relación entre los modales definidos por la implementación. El primer formulario busca de una manera definida por la implementación y el otro de una manera definida por la implementación (posiblemente otra). El estándar también especifica que ciertos archivos de inclusión deben estar presentes (por ejemplo, ).

Formalmente, debe leer el manual de su comstackdor, pero normalmente (por tradición) el formulario #include "..." busca el directorio del archivo en el que se encontró #include primero, y luego los directorios que el #include <...> búsquedas de formularios (la ruta de inclusión, p. ej., encabezados del sistema).

Gracias por las excelentes respuestas, esp. Adam Stelmaszczyk y piCookie, y aib.

Al igual que muchos progtwigdores, he usado la convención informal de usar el "myApp.hpp" para archivos específicos de la aplicación, y el para archivos del sistema de biblioteca y comstackdor, es decir, archivos especificados en /I y la variable de entorno INCLUDE , durante años pensando que ese era el estándar.

Sin embargo, el estándar C establece que el orden de búsqueda es específico de la implementación, lo que puede complicar la portabilidad. Para empeorar las cosas, usamos mermelada, que automágicamente se da cuenta de dónde están los archivos incluidos. Puede usar rutas relativas o absolutas para sus archivos de inclusión. es decir

 #include "../../MyProgDir/SourceDir1/someFile.hpp" 

Las versiones anteriores de MSVS requerían barras invertidas dobles (\\), pero ahora eso no es obligatorio. No sé cuando cambió. Simplemente use barras diagonales para compatibilidad con ‘nix (Windows lo aceptará).

Si realmente está preocupado, use "./myHeader.h" para un archivo de inclusión en el mismo directorio que el código fuente (mi proyecto actual, muy grande tiene algunos nombres de archivos duplicados incluidos dispersos, realmente un problema de gestión de configuración )

Aquí está la explicación de MSDN copiada aquí para su conveniencia).

Formulario citado

El preprocesador busca los archivos de inclusión en este orden:

  1. En el mismo directorio que el archivo que contiene la instrucción #include.
  2. En los directorios de los archivos de inclusión abiertos actualmente, en el orden inverso en el que
    fueron abiertos La búsqueda comienza en el directorio del archivo de inclusión principal y
    continúa hacia arriba a través de los directorios de cualquier abuelo incluyen archivos.
  3. A lo largo de la ruta especificada por cada opción de comstackdor /I
  4. A lo largo de las rutas especificadas por la variable de entorno INCLUDE .

Forma de ángulo de soporte

El preprocesador busca los archivos de inclusión en este orden:

  1. A lo largo de la ruta especificada por cada opción de comstackdor /I
  2. Cuando se produce la comstackción en la línea de comando, a lo largo de las rutas especificadas por la variable de entorno INCLUDE .

Al menos para la versión de GCC <= 3.0, el formulario de paréntesis angulares no genera una dependencia entre el archivo incluido y el incluido.

Por lo tanto, si desea generar reglas de dependencia (utilizando la opción GCC -M, por ejemplo), debe usar el formulario citado para los archivos que deben incluirse en el árbol de dependencias.

(Ver http://gcc.gnu.org/onlinedocs/cpp/Invocation.html )

Para #include "" un comstackdor normalmente busca en la carpeta del archivo que contiene esa y luego las otras carpetas. Para #include <> el comstackdor no busca en la carpeta del archivo actual.

  • #include <> es para archivos de encabezado predefinidos

Si el archivo de encabezado está predefinido, simplemente escriba el nombre del archivo de encabezado entre corchetes angulares, y se vería así (suponiendo que tengamos un nombre de archivo de encabezado predefinido iostream):

 #include  
  • #include " " es para archivos de encabezado que el progtwigdor define

Si usted (el progtwigdor) escribió su propio archivo de encabezado, entonces escribiría el nombre del archivo de encabezado entre comillas. Entonces, supongamos que escribió un archivo de encabezado llamado myfile.h , entonces este es un ejemplo de cómo usaría la directiva include para incluir ese archivo:

 #include "myfile.h" 

Un #include con corchetes angulares buscará una “lista de lugares dependiente de la implementación” (que es una forma muy complicada de decir “encabezados del sistema”) para que se incluya el archivo.

Un #include con comillas solo buscará un archivo (y, “de una manera dependiente de la implementación”, bleh). Lo que significa que, en inglés normal, intentará aplicar la ruta / nombre de archivo que arrojes y no anteponerá una ruta del sistema ni la manipulará de otra manera.

Además, si #include “” falla, el estándar vuelve a leerlo como #include <>.

La documentación de gcc tiene una descripción (específica del comstackdor) que, aunque es específica de gcc y no de la norma, es mucho más fácil de entender que la charla estilo abogado de las normas ISO.

 #include "filename" // User defined header #include  // Standard library header. 

Ejemplo:

El nombre del archivo aquí es Seller.h :

 #ifndef SELLER_H // Header guard #define SELLER_H // Header guard #include  #include  #include  class Seller { private: char name[31]; double sales_total; public: Seller(); Seller(char[], double); char*getName(); #endif 

En la implementación de la clase (por ejemplo, Seller.cpp y en otros archivos que usarán el archivo Seller.h ), el encabezado definido por el usuario ahora debe incluirse, como se Seller.h continuación:

 #include "Seller.h" 

Cuando usa #include , el preprocesador busca el archivo en directtory de los archivos de encabezado C \ C ++ (stdio.h \ cstdio, cadena, vector, etc.). Pero cuando usa #include “filename”: primero, el pre-procesador busca el archivo en el directorio actual, y si no está aquí, lo busca en el directorio de archivos de cabecera C \ C ++.

Muchas de las respuestas aquí se centran en las rutas que el comstackdor buscará para encontrar el archivo. Si bien esto es lo que hacen la mayoría de los comstackdores, se permite preprogtwigr un comstackdor conforme con los efectos de los encabezados estándar, y tratar, digamos, #include como un modificador, y no necesita existir como un archivo en absoluto.

Esto no es puramente hipotético. Hay al menos un comstackdor que funciona de esa manera. Se recomienda usar #include solo con encabezados estándar.

#include le dice al comstackdor que busque el encabezado en su directorio de inclusión, por ejemplo, para MinGW el comstackdor buscará el file en C: \ MinGW \ include \ o donde esté instalado su comstackdor.

#include "file" le dice al comstackdor que busque el #include "file" en el directorio actual (es decir, el directorio en el que reside el archivo fuente).

Puede usar el -I para que GCC le diga que, cuando encuentra una inclusión con corchetes en ángulo, también debe buscar encabezados en el directorio después de -I . Por ejemplo, si tiene un archivo llamado myheader.h en su propio directorio, podría decir #include si llamó a GCC con -I . (indicando que debe buscar incluye en el directorio actual). Sin el -I , deberá usar #include "myheader.h" para incluir el archivo, o mover myheader.h al directorio de include de su comstackdor ( véase más arriba)

En C ++, incluye un archivo de dos maneras:

El primero es #include que le dice al preprocesador que busque el archivo en la ubicación predeterminada predefinida. Esta ubicación suele ser una variable de entorno INCLUDE que denota la ruta para incluir archivos.

Y el segundo tipo es #include “filename” que le dice al preprocesador que busque primero el archivo en el directorio actual, luego búsquelo en las ubicaciones predefinidas que el usuario ha configurado.

 #include  

se usa para incluir archivos de biblioteca estándar. Por lo tanto, el comstackdor controlará las ubicaciones donde residen los encabezados de biblioteca estándar.

 #include "xyz.h" 

le dirá al comstackdor que incluya archivos de encabezado definidos por el usuario. Entonces el comstackdor buscará estos archivos de encabezado en la carpeta actual o -I carpetas definidas.

las búsquedas de “” en ubicaciones de bibliotecas estándar C

mientras que “nombre de archivo” también busca en el directorio actual.

Idealmente, usaría <...> para las bibliotecas C estándar y “…” para las bibliotecas que escriba y estén presentes en el directorio actual.

El #include se usa cuando se hace referencia a un archivo del sistema. Es un archivo de encabezado que se puede encontrar en las ubicaciones predeterminadas del sistema, como /usr/include o /usr/local/include . Para sus propios archivos que deben incluirse en otro progtwig, debe usar la syntax #include "filename" .

La regla general simple es usar corchetes en ángulo para incluir archivos de encabezado que vienen con el comstackdor. Use comillas dobles para incluir cualquier otro archivo de encabezado. La mayoría de los comstackdores lo hacen de esta manera.

1.9 – Los archivos de encabezado explican con más detalle las directivas del preprocesador. Si eres un progtwigdor novato, esa página debería ayudarte a entender todo eso. Lo aprendí de aquí, y lo he estado siguiendo en el trabajo.

#include

se usa cuando desea usar el archivo de encabezado del sistema C / C ++ o las bibliotecas del comstackdor. Estas bibliotecas pueden ser stdio.h, string.h, math.h, etc.

#include "path-to-file/filename"

se usa cuando desea usar su propio archivo de encabezado personalizado que se encuentra en su carpeta de proyecto o en otro lugar.

Para obtener más información acerca de los preprocesadores y el encabezado. Lea C – Preprocesadores .

I believe that headers included in double-quotes will be looked for the in same system paths as angle-bracketed includes if they are not found in the current directory.

  #include  (1) #include "filename" (2) 

#include includes source file, identified by filename, into the current source file at the line immediately after the directive.

The first version of the directive searches only standard include directories. The standard C++ library, as well as standard C library, is implicitly included in standard include directories. The standard include directories can be controlled by the user through compiler options.

The second version first searches the directory where the current file resides and, only if the file is not found, searches the standard include directories.

In the case the file is not found, the program is ill-formed.

Form 1 – #include “xxx”

First, looks for the presence of header file in the current directory from where directive is invoked. If not found, then it searches in the preconfigured list of standard system directories.

Form 2 – #include < xxx >

This looks for the presence of header file in the current directory from where directive is invoked.


The exact search directory list depends on the target system, how GCC is configured, and where it is installed. You can find the search directory list of your GCC compiler by running it with -v option.

You can add additional directories to the search path by using – I dir , which causes dir to be searched after the current directory (for the quote form of the directive) and ahead of the standard system directories.


Basically, the form “xxx” is nothing but search in current directory; if not found falling back the form

There exists two ways to write #include statement.These are:

 #include"filename" #include 

The meaning of each form is

 #include"mylib.h" 

This command would look for the file mylib.h in the current directory as well as the specified list of directories as mentioned n the include search path that might have been set up.

 #include 

This command would look for the file mylib.h in the specified list of directories only.

The include search path is nothing but a list of directories that would be searched for the file being included.Different C compilers let you set the search path in different manners.

The order of search header files is different. prefer to search the standard headers first while “XXX.h” searches the workspace’s header files first.

#include

will find the corresponding file from the C++ library. it means if you have a file called hello.h in the C++ library folder, #include will load it.

Pero,

#include "filename"

will find the file in the same directory where your source file is.

En adición,

#include "path_to_file/filename"

will find the file in the directory which you typed in path_to_file .

To include a predefined library header file , #include is used whereas to include user defined header file, #include "filename" is relevant.