¿Cuál es la diferencia entre #include <filename> y #include "filename"?

2357

En los lenguajes de programación C y C ++, ¿cuál es la diferencia entre usar corchetes angulares y usar comillas en una includedeclaración, de la siguiente manera?

  1. #include <filename>
  2. #include "filename"
quest49
fuente

Respuestas:

1405

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

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

Para #include "filename"las búsquedas preprocesador primeros en el mismo directorio que el archivo que contiene la directiva, y luego sigue el camino de búsqueda utilizada para el #include <filename>formulario. Este método se usa normalmente para incluir archivos de encabezado definidos por el programador.

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

quest49
fuente
135
La declaración: "el preprocesador busca en el mismo directorio ..." puede ser cierto en la práctica, pero el estándar establece que el archivo fuente nombrado se "busca de una manera definida por la implementación". Ver respuesta de piCookie.
Richard Corden
6060
Si bien su respuesta puede parecer "verdadera", debido a que esta es la cantidad de implementaciones que funcionan por convención, debe observar detenidamente las respuestas de aib y piCookie. Ambos señalan (respaldados por la redacción del estándar C) que la distinción real es la inclusión de un "encabezado" versus la inclusión de un "archivo fuente" (y no, esto no significa ".h" vs. ". C"). El "archivo de origen" en este contexto puede ser (y generalmente es, y casi siempre debería ser) un archivo ".h". Un encabezado no necesariamente debe ser un archivo (un compilador podría, por ejemplo, incluir un encabezado que esté codificado estáticamente, no en un archivo).
Dan Molding
55
"... el preprocesador busca en el mismo directorio que el archivo que se está compilando para que se incluya el archivo". Esta afirmación no es completamente correcta. Estaba interesado en esta pregunta porque tenía curiosidad por saber cuál es la respuesta real, pero sé que esto no es cierto porque al menos con gcc cuando especifica una ruta de inclusión adicional con -I que buscará los archivos especificados con el nombre de archivo #include ". h "
Gabriel Southern
99
Aquellos a quienes no les gusta la respuesta, por favor, den un ejemplo práctico, en el que esté equivocado.
0kcats
1
Efectivamente, recientemente mezclé estas sintaxis al incluir encabezados de 'la misma' biblioteca y terminé con errores de redefinición. Si entiendo correctamente, #include <...>usé el paquete instalado en el sistema y #include "..."usé la versión del repositorio cercano. Podría tener eso al revés. De cualquier manera, el protector de inclusión en el encabezado empaquetado tiene el prefijo de subrayado. (Podría ser una convención para paquetes o tal vez una forma de evitar deliberadamente mezclar los dos, aunque los calificadores de versión tendrían más sentido para mí.)
John P
714

La única forma de saberlo 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 establecen:

  • Una directiva de preprocesamiento del formulario

    #include <h-char-sequence> new-line

    busca una secuencia de lugares definido por la implementación de una cabecera identificado de forma única por la secuencia especificada entre el <y >delimitadores, y hace que la sustitución de dicha Directiva por todo el contenido de la cabecera . La forma en que se especifican los lugares o el encabezado identificado está definido por la implementación.

  • Una directiva de preprocesamiento del formulario

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

    provoca el reemplazo de esa directiva por todo el contenido 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 vuelve a procesar como si dijera

    #include <h-char-sequence> new-line

    con la secuencia contenida idéntica (incluidos los >caracteres, si los hay) de la directiva original.

  • Una directiva de preprocesamiento del formulario

    #include pp-tokens new-line

    (que no coincide con una de las dos formas anteriores) está permitido. Los tokens de preprocesamiento posteriores includea la directiva se procesan igual que en el texto normal. (Cada identificador actualmente definido como un 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 mediante el cual una secuencia de tokens de preprocesamiento entre ay <un >par de tokens de preprocesamiento o un par de "caracteres se combina en un token de preprocesamiento de nombre de encabezado único se define en la implementación.

Definiciones:

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

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

piCookie
fuente
108
Relevante: implementación en g ++ y en visual c ++
Alexander Malakhov
27
@piCookie tanto <nombre de archivo> como "nombre de archivo" buscan lugares definidos por la implementación. Entonces cuál es la diferencia ?
onmyway133
15
@Stefan, solo estoy citando el estándar que no dice nada sobre INCLUDE_PATH. Su implementación puede hacer eso, y la mía no. La pregunta original era genéricamente C y no específicamente gcc (que no creo que use INCLUDE_PATH) o Microsoft C (que creo que sí) o cualquier otra, por lo que no se puede responder genéricamente, sino que se debe hacer referencia a la documentación de cada implementación.
piCookie
12
Al igual que con todas estas situaciones, los ejemplos concretos (especialmente de escenarios comunes) son muy útiles e igualmente apreciados. Las respuestas genéricas innecesariamente obtusas no tienen tanto uso práctico.
Vargonian
132
"Así es como el estándar C puede ser detallado y no responder a su pregunta"
anatolyg
287

La secuencia de caracteres entre <y> se refiere únicamente a un encabezado, que no es necesariamente un archivo. Las implementaciones son bastante libres de usar la secuencia de caracteres como lo deseen. (Sin embargo, principalmente, trátelo como un nombre de archivo y realice una búsqueda en la ruta de inclusión , como indican las otras publicaciones).

Si #include "file"se utiliza el formulario, la implementación primero busca un archivo con el nombre dado, si es compatible. Si no (compatible), o si la búsqueda falla, la implementación se comporta como si #include <file>se utilizara el otro formulario ( ).

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

aib
fuente
50
+1, esta es probablemente la respuesta más concisa y correcta aquí. De acuerdo con el estándar (que piCookie cita en su respuesta), la única diferencia real es "encabezado" versus "archivo fuente". El mecanismo de búsqueda está definido por la implementación de cualquier manera. El uso de comillas dobles significa que tiene la intención de incluir un "archivo fuente", mientras que los corchetes angulares significan que tiene la intención de incluir un "encabezado" que, como usted dice, puede no ser un archivo en absoluto.
Dan Molding
3
Vea el comentario de Dan Moulding a la respuesta de quest49; los encabezados estándar no tienen que estar en forma de archivo, pueden estar integrados.
ab
10
He estado leyendo estos "encabezados estándar no tienen que estar en forma de archivo" durante una década. ¿Te importaría dar un ejemplo del mundo real?
Maxim Egorushkin
12
@Maxim Yegorushkin: Tampoco puedo pensar en ningún ejemplo existente en el mundo real; sin embargo, no puede existir un compilador C11 completo para MS-DOS a menos que los encabezados no tengan que ser archivos. Esto se debe a que algunos de los nombres de encabezado C11 no son compatibles con la limitación de nombre de archivo MS-DOS "8.3".
Dan Moulding
18
@MaximEgorushkin: El compilador VAX / VMS C mantuvo todos los encabezados de la biblioteca de tiempo de ejecución C en un solo archivo de biblioteca de texto (similar a un archivo Unix), y usó la cadena entre <y >como la clave para indexar en la biblioteca.
Adrian McCarthy
117

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

Según el número 7 de las especificaciones básicas de The Open Group ,

-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 encerrados entre comillas dobles ("") se buscarán primero en el directorio del archivo con la línea #include , luego en los directorios nombrados en las opciones -I y por último en los lugares habituales. Para los encabezados cuyos nombres están encerrados entre paréntesis angulares ("<>"), el encabezado se buscará solo en los directorios nombrados en opciones -I y luego en los lugares habituales. Los directorios nombrados en las opciones -I se buscarán en el orden especificado.invocación del comando c99 .

Por lo tanto, en un entorno compatible con POSIX, con un compilador de C compatible con POSIX, #include "file.h"es probable que busque ./file.hprimero, dónde .está el directorio donde está el archivo con la #includedeclaración, mientras que #include <file.h>es probable que busque /usr/include/file.hprimero, dónde /usr/includeestá definido su sistema lugares habituales para encabezados (parece que POSIX no lo define).

Yann Droneaud
fuente
1
¿Cuál es la fuente exacta del texto? ¿Es de parte normativa de IEEE Std 1003.1, 2013?
osgx
77
@osgx: esa redacción (o algo extremadamente similar) se encuentra en la especificación POSIX para c99, que es el nombre POSIX para el compilador de C. (El estándar POSIX 2008 difícilmente podría referirse a C11; la actualización de 2013 a POSIX 2008 no cambió el estándar C al que se refería.)
Jonathan Leffler
1
Este fue mi primer pensamiento también. La página de manual de gcc incluye esto al igual que otros. También hay algo similar para las bibliotecas -L.
Pryftan
50

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

Los archivos de encabezado del usuario y del sistema se incluyen mediante la directiva de preprocesamiento ‘#include’. Tiene dos variantes:

#include <file>

Esta variante se utiliza para los archivos de encabezado del sistema. Busca un archivo llamado archivo en una lista estándar de directorios del sistema. Puede anteponer directorios a esta lista con la -Iopción (ver Invocación ).

#include "file"

Esta variante se utiliza para archivos de encabezado de su propio programa. Busca un archivo llamado archivo primero en el directorio que contiene el archivo actual, luego en los directorios de comillas y luego en los mismos directorios utilizados <file>. Puede anteponer directorios a la lista de directorios de citas con la -iquoteopción. El argumento de ‘#include’, ya sea delimitado con comillas o corchetes angulares, se comporta como una constante de cadena en que los comentarios no se reconocen y los nombres de macro no se expanden. Por lo tanto, #include <x/*y>especifica la inclusión de un archivo de encabezado del sistema denominado x/*y.

Sin embargo, si se producen barras invertidas 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 procesan. Por lo tanto, #include "x\n\\y"especifica un nombre de archivo que contiene tres barras invertidas. (Algunos sistemas interpretan '\' como un separador de nombre de ruta. Todos estos también se interpretan de ‘/’la misma manera. Es más portátil de usar solamente ‘/’).

Es un error si hay algo (aparte de los comentarios) en la línea después del nombre del archivo.

Suraj Jain
fuente
46

Lo hace:

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

con .ser el directorio del archivo donde #includeestá contenido, y / o el directorio de trabajo actual del compilador, y / o eldefault_include_paths

y

<mypath/myfile> is short for <defaultincludepaths>/mypath/myfile

Si ./está adentro <default_include_paths>, entonces no hay diferencia.

Si mypath/myfileestá en otro directorio de inclusión, el comportamiento es indefinido.

Stefan Steiger
fuente
12
No, #include "mypath/myfile"no es equivalente a #include "./mypath/myfile". Como dice la respuesta de piCookie, las comillas dobles le dicen al compilador que busque de una manera definida por la implementación, lo que incluye buscar en los lugares especificados #include <...>. (En realidad, probablemente sea equivalente, pero solo porque, por ejemplo, /usr/include/mypath/myfilese puede denominar /usr/include/./mypath/myfile, al menos en sistemas tipo Unix)
Keith Thompson, el
1
@Keith Thompson: Así es, estaba pensando en mi caja de Linux. Evidentemente podría ser diferente. Aunque en la práctica, Windows como sistema operativo no Posix también interpreta / como separador de ruta, y ./ también existe.
Stefan Steiger
1
la opción -L dirpath luego agrega dirpath a defaultincludepaths, en lugar de darle otro significado a .(como se mencionó anteriormente). Esto tiene la consecuencia esperada de que ambos #include "..."y #include <...>buscar en dirpath
Protongun
1
Creo que esta respuesta es incorrecta, ya que implica que los encabezados incluidos con comillas dobles siempre se buscan en el directorio de trabajo actual. El mecanismo de búsqueda es mucho más detallado; Esta respuesta es incompleta. No estoy agregando este comentario para quejarme o quejarme, sino porque el sistema me pide que agregue un comentario para explicar por qué rechacé esta respuesta.
Carlo Wood
39

La <file>inclusión le dice al preprocesador que busque en -Idirectorios y en directorios predefinidos primero , luego en el directorio del archivo .c. La "file"inclusión le dice al preprocesador que primero busque en el directorio del archivo fuente y luego regrese -Iy esté predefinido. Todos los destinos se buscan de todos modos, solo el orden de búsqueda es diferente.

El estándar de 2011 trata principalmente los archivos de inclusión en "16.2 Inclusión de archivos fuente".

2 Una directiva de preprocesamiento del formulario

# include <h-char-sequence> new-line

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

3 Una directiva de preprocesamiento del formulario

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

provoca el reemplazo de esa directiva por todo el contenido 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 vuelve a procesar como si dijera

# include <h-char-sequence> new-line

con la secuencia contenida idéntica (incluidos los caracteres>, si los hay) de la directiva original.

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


fuente
44
¿Podría proporcionar una referencia de en qué parte del estándar C -Ise especifica este negocio?
juanchopanza
1
No veo ninguna referencia a -I.
juanchopanza
2
Esa es la parte "definida por la implementación".
28

#include <file.h>le dice al compilador que busque el encabezado en su directorio "incluye", por ejemplo, para MinGW el compilador buscaría file.hen C: \ MinGW \ include \ o donde esté instalado su compilador.

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

Puede usar el -Iindicador de GCC para indicarle que, cuando encuentra una inclusión con corchetes angulados, también debe buscar encabezados en el directorio posterior -I. GCC tratará el directorio después de la bandera como si fuera el includesdirectorio.

Por ejemplo, si tiene un archivo llamado myheader.hen su propio directorio, podría decir #include <myheader.h>si llamó a GCC con el indicador -I .(lo que indica que debe buscar incluye en el directorio actual).

Sin la -Ibandera, tendrá que usar #include "myheader.h"para incluir el archivo o moverse myheader.hal includedirectorio de su compilador.

adrian
fuente
22

Por norma, sí, son diferentes:

  • Una directiva de preprocesamiento del formulario

    #include <h-char-sequence> new-line

    busca una secuencia de lugares definido por la implementación de una cabecera identificado de forma única por la secuencia especificada entre el <y >delimitadores, y hace que la sustitución de dicha Directiva por todo el contenido de la cabecera. La forma en que se especifican los lugares o el encabezado identificado está definido por la implementación.

  • Una directiva de preprocesamiento del formulario

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

    provoca el reemplazo de esa directiva por todo el contenido 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 vuelve a procesar como si dijera

    #include <h-char-sequence> new-line

    con la secuencia contenida idéntica (incluidos los >caracteres, si los hay) de la directiva original.

  • Una directiva de preprocesamiento del formulario

    #include pp-tokens new-line

    (que no coincide con una de las dos formas anteriores) está permitido. Los tokens de preprocesamiento posteriores includea la directiva se procesan igual que en el texto normal. (Cada identificador actualmente definido como un 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 mediante el cual una secuencia de tokens de preprocesamiento entre ay <un >par de tokens de preprocesamiento o un par de "caracteres se combina en un token de preprocesamiento de nombre de encabezado único se define en la implementación.

Definiciones:

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

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

Tenga en cuenta que el estándar no indica ninguna relación entre los modos definidos por la implementación. La primera forma busca de una manera definida por la implementación, y la otra de una manera (posiblemente otra) definida por la implementación. La norma también especifica que ciertos archivos de inclusión deben estar presentes (por ejemplo <stdio.h>).

Formalmente, tendría que leer el manual de su compilador, sin embargo, normalmente (por tradición) el #include "..."formulario busca #includeprimero en el directorio del archivo en el que se encontró y luego en los directorios en los que #include <...>busca el formulario (la ruta de inclusión, por ejemplo, encabezados del sistema )

Rey del cielo
fuente
2
Este es principalmente el mismo texto que la respuesta de piCookie de siete años antes.
Kyle Strand
55
@KyleStrand Eso se debe a que el mismo texto es una cita de la sección relevante de la norma: ese texto debe ser idéntico. La respuesta real no es el mismo texto y es algo diferente, aunque también reconozco que se escribirá en la documentación para la implementación, también noto que también hay una forma tradicional de interpretarlos (que la mayoría o todos los compiladores que utilicé respetan) .
Skyking
2
OMI, esta es la mejor respuesta aquí, porque cubre tanto lo que dice el estándar como lo que la mayoría de los compiladores hacen en realidad.
plugwash
17

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

Al igual que muchos programadores, he usado la convención informal de usar el "myApp.hpp"formulario para archivos específicos de la aplicación, y el <libHeader.hpp>formulario para los archivos del sistema de compilación y biblioteca, es decir, archivos especificados en /Iy la INCLUDEvariable de entorno, durante años pensando que 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 jam, que automáticamente determina dónde están los archivos de inclusión. 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 necesario. No sé cuando cambió. Simplemente use barras diagonales para compatibilidad con 'nix (Windows lo aceptará).

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

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

Formulario citado

El preprocesador busca incluir archivos 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 que
    se abrieron. 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 los archivos de inclusión de los abuelos.
  3. A lo largo del camino especificado por cada /Iopción del compilador.
  4. A lo largo de las rutas especificadas por la INCLUDEvariable de entorno.

Forma de soporte angular

El preprocesador busca incluir archivos en este orden:

  1. A lo largo del camino especificado por cada /Iopción del compilador.
  2. Cuando la compilación se produce en la línea de comando, a lo largo de las rutas que especifica la INCLUDEvariable de entorno.
jineteBill
fuente
16

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

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

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

Denis Ros
fuente
1
Sí, hay varias formas diferentes de generar dependencias. Ese es uno de ellos, pero no es el único.
Pryftan
15

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

Maxim Egorushkin
fuente
1
No estoy seguro de por qué la gente no está de acuerdo.
Maxim Egorushkin
Sospecho que es porque la mayoría de las personas compila solo los archivos en su CWD. Si está en el directorio foo, y está compilando foo / unittest / bar.c, e incluye bar.h, entonces "bar.h" funciona y <bar.h> no.
1
@Maxim personas no están de acuerdo porque el comportamiento que describe no es estándar C.
osvein
2
@Spookbuster Correcto, el estándar dice ambos <filename>y "filename"busca lugares definidos por la implementación.
Maxim Egorushkin
14

Cuando utiliza #include <nombre de archivo>, el preprocesador busca el archivo en el directorio de archivos de encabezado C \ C ++ (stdio.h \ cstdio, cadena, vector, etc.). Pero, cuando usa #include "filename": primero, el preprocesador busca el archivo en el directorio actual, y si no lo hace aquí, lo busca en el directorio de archivos de encabezado C \ C ++.

Chayim Friedman
fuente
1
Después de que una respuesta perfecta estuvo disponible durante años, ¿por qué enviar una, eso es descaradamente incorrecto? Aunque es común, la #includedirectiva no está estrictamente relacionada con los archivos.
Inspeccionable el
@IInspectable, explique por qué no está relacionado con los archivos.
Behrooz Karjoo
11

Un #include con paréntesis 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 manera dependiente de la implementación", bleh). Lo que significa que, en inglés normal, intentará aplicar la ruta / nombre de archivo que le arrojas y no antepondrá una ruta del sistema ni la manipulará de otra manera.

Además, si #include "" falla, el estándar lo vuelve a leer como #include <>.

La documentación de gcc tiene una descripción (específica del compilador) que, aunque es específica de gcc y no del estándar, es mucho más fácil de entender que la charla estilo abogado de los estándares ISO.

Damon
fuente
Sin embargo, el uso de corchetes o comillas angulares no afecta la forma en que se incluyen los archivos, es exactamente lo mismo: el preprocesador crea esencialmente un archivo fuente grande copiando y pegando el código de los archivos de inclusión al archivo fuente original, antes de proporcionar al compilador (el preprocesador hace otra cosa, como #definir la sustitución, #if evaluación, etc. pero el #incluir procesamiento es así de fácil)
Loghorn
¿Qué hay de los conflictos? por ejemplo, digamos que tengo zlib.hen mis rutas de búsqueda de 'usuario', y existe una versión diferente en la ruta de búsqueda del sistema, ¿entonces #include <zlib.h>incluye la versión del sistema e #include "zlib.h"incluye la mía?
the_mandrill
Ajá, respondió mi propia pregunta: stackoverflow.com/questions/21593/…
the_mandrill
Gracias por reconocer que tanto el estándar (s) como las convenciones de implementación típicas son relevantes aquí, en lugar de simplemente declarar que es incognoscible porque no está especificado por el estándar.
Kyle Strand
10
#include "filename" // User defined header
#include <filename> // Standard library header.

Ejemplo:

El nombre del archivo aquí es Seller.h:

#ifndef SELLER_H     // Header guard
#define SELLER_H     // Header guard

#include <string>
#include <iostream>
#include <iomanip>

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.cppy en otros archivos que usarán el archivo Seller.h), el encabezado definido por el usuario ahora debe incluirse de la siguiente manera:

#include "Seller.h"
Bárbara
fuente
10
  • #include <> es para archivos de encabezado predefinidos

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

#include <iostream>
  • #include " " es para archivos de encabezado que el programador define

Si usted (el programador) 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"
VishalSoni
fuente
2
No tiene nada que ver con los archivos de encabezado predefinidos en absoluto. Tiene que ver con ubicaciones para buscar.
C Johnson
9

Muchas de las respuestas aquí se centran en las rutas que buscará el compilador para encontrar el archivo. Si bien esto es lo que hacen la mayoría de los compiladores, se permite que un compilador conforme se programe previamente con los efectos de los encabezados estándar y que se trate, por ejemplo, #include <list>como un interruptor, y no es necesario que exista como un archivo.

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

sp2danny
fuente
9
#include <abc.h>

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

#include "xyz.h"

le indicará al compilador que incluya archivos de encabezado definidos por el usuario. Por lo tanto, el compilador buscará estos archivos de encabezado en la carpeta actual o en las -Icarpetas definidas.

Christy Wald
fuente
7

En C ++, incluya 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 es a menudo una variable de entorno INCLUDE que denota la ruta para incluir archivos.

Y el segundo tipo es #include "nombre de archivo", que le dice al preprocesador que busque primero el archivo en el directorio actual, luego búsquelo en las ubicaciones predefinidas que el usuario haya configurado.

virat
fuente
7

Forma 1 - # incluye <xxx>

Primero, busca la presencia del archivo de encabezado en el directorio actual desde donde se invoca la directiva. Si no se encuentra, busca en la lista preconfigurada de directorios estándar del sistema.

Formulario 2 - # incluye "xxx"

Esto busca la presencia del archivo de encabezado en el directorio actual desde donde se invoca la directiva.


La lista de directorios de búsqueda exacta depende del sistema de destino, cómo está configurado GCC y dónde está instalado. Puede encontrar la lista del directorio de búsqueda de su compilador GCC ejecutándola con la opción -v.

Puede agregar directorios adicionales a la ruta de búsqueda mediante el uso de - I dir , que hace que se busque dir después del directorio actual (para el formulario de cotización de la directiva) y delante de los directorios estándar del sistema.


Básicamente, la forma "xxx" no es más que buscar en el directorio actual; si no se encuentra retrocediendo el formulario

Darshan L
fuente
3
Si decide responder una pregunta anterior que tiene respuestas bien establecidas y correctas, agregar una nueva respuesta al final del día puede no darle ningún crédito. Si tiene alguna información nueva distintiva, o está convencido de que las otras respuestas están todas equivocadas, agregue una nueva respuesta, pero 'otra respuesta' que proporciona la misma información básica mucho tiempo después de que se formuló la pregunta, generalmente gana ' No te ganaré mucho crédito.
Jonathan Leffler
1
@ Jonathan Leffler ¿Puede señalarme la respuesta "bien establecida" que considera que es tan concisa y precisa como la respuesta de Darshan?
personal_cloud
1
La descripción del #include "header.h"formulario no es precisa, @personal_cloud. Considero que la respuesta de piCookie y Yann Droneaud es la más relevante, ya que identifican de dónde proviene su información. Tampoco creo que la respuesta mejor votada sea completamente satisfactoria.
Jonathan Leffler
¿Por qué esta respuesta se muestra en la parte superior, mientras que dos respuestas más abajo hay más de 650 votos? Esta respuesta me confundió, porque no coincide con el comportamiento observado por mí. Esto podría ser, porque la última oración se rompe debido a que no escapan los corchetes angulares. No estoy seguro de lo que se supone que significa.
Neonit
6

Se #include <filename>utiliza cuando se hace referencia a un archivo del sistema. Ese es un archivo de encabezado que se puede encontrar en ubicaciones predeterminadas del sistema como /usr/includeo /usr/local/include. Para sus propios archivos que deben incluirse en otro programa, debe usar la #include "filename"sintaxis.

srsci
fuente
6

el "<nombre de archivo>" busca en ubicaciones de biblioteca C estándar

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 escribe y están presentes en el directorio actual.

jigar karangiya
fuente
44
¿Qué nueva información agrega esta respuesta a las otras?
Daniel Langr
5

La regla general simple es usar corchetes angulados para incluir archivos de encabezado que vienen con el compilador. Use comillas dobles para incluir cualquier otro archivo de encabezado. La mayoría de los compiladores lo hacen de esta manera.

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

Eakan Gopalakrishnan
fuente
4
#include <filename>

se utiliza cuando desea utilizar el archivo de encabezado del sistema C / C ++ o las bibliotecas del compilador. 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 está en su carpeta de proyecto o en otro lugar.

Para más información sobre preprocesadores y encabezado. Leer C - Preprocesadores .

Hafiz Shehbaz Ali
fuente
3

#include <filename>

  • El preprocesador busca de manera dependiente de la implementación. Le dice al compilador que busque el directorio donde se guardan los archivos de encabezado del sistema.
  • Este método generalmente se usa para buscar archivos de encabezado estándar.

#include "filename"

  • Esto le dice al compilador que busque archivos de encabezado donde se está ejecutando el programa. Si fallaba, se comportaba como#include <filename> y busca ese archivo de encabezado en donde se almacenaron los archivos de encabezado del sistema.
  • Este método generalmente se usa para identificar archivos de encabezado definidos por el usuario (archivos de encabezado creados por el usuario). No debe usar esto si desea llamar a la biblioteca estándar porque requiere más tiempo de compilación que #include <filename>.
Kalana
fuente
2

Para ver el orden de búsqueda en su sistema usando gcc, basado en la configuración actual, puede ejecutar el siguiente comando. Puedes encontrar más detalles sobre este comando aquí

cpp -v /dev/null -o /dev/null

Apple LLVM versión 10.0.0 (clang-1000.10.44.2)
Destino: x86_64-apple-darwin18.0.0
Modelo de subproceso: posix InstalledDir: Library / Developer / CommandLineTools / usr / bin
"/ Library / Developer / CommandLineTools / usr / bin / clang" -cc1 -triple x86_64-apple-macosx10.14.0 -Wdeprecated-objc-isa-use -Werror = deprecated-objc-isa-use -E -disable-free - disable-llvm-verifier -discard-value-names -main-file-name null -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -fno-strictly-return -masm-verbose - munwind-tables -target-cpu penryn -dwarf-column-info -debugger-tuning = lldb -target-linker-version 409.12 -v -resource-dir /Library/Developer/CommandLineTools/usr/lib/clang/10.0.0 - isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk -I / usr / local / include -fdebug-compilation-dir / Users / hogstrom -ferror-limit 19 -fmessage-length 80 -stack-protector 1 -fblocks -fencode-extended-block-signature -fobjc-runtime = macosx-10.14.0 -fmax-type-align = 16 -fdiagnostics-show-option -fcolor-diagnostics -traditional-cpp -o - -xc / dev / null
clang -cc1 versión 10.0.0 (clang-1000.10.44.2) objetivo predeterminado x86_64-apple-darwin18.0.0 ignorando el directorio inexistente "/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/local/include" ignorando inexistente directorio "/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/Library/Frameworks"
#include "..." la búsqueda comienza aquí:
#include <...> la búsqueda comienza aquí:
/ usr / local / include
/ Library / Developer / CommandLineTools / usr / lib / clang / 10.0.0 / include
/ Library / Developer / CommandLineTools / usr / include
/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include
/ Library / Developer / CommandLineTools / SDKs / MacOSX10.14.sdk / System / Library / Frameworks (directorio del marco)
Fin de la lista de búsqueda.

Hogstrom
fuente
1
#include <file> 

Incluye un archivo donde está el directorio de inclusión predeterminado.

#include "file" 

Incluye un archivo en el directorio actual en el que se compiló.

IAmAUser
fuente
-2

Existen dos formas de escribir la declaración #include. Estas son:

#include"filename"
#include<filename>

El significado de cada forma es

#include"mylib.h"

Este comando buscaría el archivo mylib.hen el directorio actual, así como la lista especificada de directorios como se menciona en la ruta de búsqueda de inclusión que podría haberse configurado.

#include<mylib.h>

Este comando buscaría el archivo mylib.hen la lista especificada de directorios solamente.

La ruta de búsqueda de inclusión no es más que una lista de directorios en los que se buscaría el archivo que se incluye. Los diferentes compiladores de C le permiten configurar la ruta de búsqueda de diferentes maneras.

Noshiii
fuente
1
Si decide responder una pregunta anterior que tiene respuestas bien establecidas y correctas, agregar una nueva respuesta al final del día puede no darle ningún crédito. Si tiene alguna información nueva distintiva, o si está convencido de que las otras respuestas son incorrectas, agregue una nueva respuesta, pero 'otra respuesta' que proporciona la misma información básica mucho tiempo después de que se formuló la pregunta generalmente gana ' No te ganaré mucho crédito.
Jonathan Leffler