library - librerias de c++
Diferencia entre<include.hpp> e "include.hpp" (7)
<> busca en el directorio predeterminado para incluir archivos, "" busca en el directorio actual y en el directorio predeterminado
Esta pregunta ya tiene una respuesta aquí:
Soy nuevo en C ++.
¿Cuál es la diferencia entre incluir los archivos de encabezado c ++ usando "" y <>
Estoy tratando de usar algunos de los archivos de encabezado de una biblioteca de código abierto. Todos los archivos de cabecera en esa biblioteca se incluyen con <>. Ahora cuando hago lo mismo en mi archivo de cabecera, falla en el momento de la compilación.
<> se ve en primer lugar en la ruta del encabezado para el archivo de encabezado, mientras que "" se ve en primer lugar en el directorio actual del archivo para el encabezado.
El archivo incluye entre <> se busca en la ruta del compilador, mientras que "" se ve con relación a su directorio actual (o absoluto si especifica una ruta que comienza con / o c:/ pero esto no se recomienda)
En los sistemas Unix, de forma predeterminada, la ruta contiene /usr/include . Esta ruta puede completarse agregando -Isome_directory para que busque en ella.
Por ejemplo, si tiene su archivo test.c y desea incluir include/test.h , tiene diferentes opciones:
Escriba
#include "include/test.h", que se verá relativamente desde el directorio del archivo compilado.Escriba
#include <test.h>, pero esta vez deberá especificar: "-Iincludeal compilador para agregar el directorio./includea la ruta del compilador".
Sin embargo, tenga en cuenta que algunos compiladores aceptan la notación "" para las búsquedas en la ruta, pero eso siempre me confundió y es algo malo de hacer.
Esta pregunta es un duplicado de la Pregunta 21593 . Ninguna de las respuestas anteriores es totalmente correcta. Al igual que muchos programadores, utilicé la convención informal de utilizar el formulario "myApp.hpp" para archivos específicos de la aplicación y el formulario para archivos del sistema de compilación y biblioteca, es decir, archivos especificados en / I y la variable de entorno INCLUDE. Sin embargo, el estándar C establece que el orden de búsqueda es específico de la implementación.
Aquí está la explicación msdn copiada aquí para su conveniencia).
Formulario citado El preprocesador busca 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 compilador / 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 compilador / I.
2. Cuando se produce la compilación en la línea de comando, a lo largo de las rutas especificadas por el INCLUDE
Variable ambiental.
Incluir un archivo usando <> le indicará al compilador que busque esos archivos en las carpetas de inclusión definidas por el entorno. Esas carpetas pueden ser carpetas estándar del sistema, o definidas por su Makefile si usted usa una, etc. Usando "" , el compilador buscará archivos de inclusión solo en la ruta del archivo fuente.
De modo que puede usar "" y usar rutas absolutas o la ruta que es relativa al archivo fuente que intenta incluir, o puede usar <> después de definir sus carpetas de inclusión, y simplemente especifique el nombre del archivo de encabezado para incluir.
En mi humilde opinión, la segunda opción es mejor, especialmente si usa muchos encabezados, o múltiples bibliotecas, etc.
Para definir las carpetas de inclusión en tiempo de compilación: gcc -I ... ( man gcc! )
Las comillas significan incluir desde la carpeta local y la <> significa incluir desde otro directorio especificado usando una bandera a g ++ o MSVC o cualquier compilador que esté usando o los encabezados del sistema.
La distinción es en gran parte implementación definida; el formulario "..." debe aparecer primero en el lugar donde se encuentra el archivo que lo incluye; el <...> no. Más allá de eso, ambos miran en una lista de lugares definida por la implementación, con el requisito adicional de que si el compilador no encuentra un formulario "..." en ninguno de los lugares esperados, reprocesa el include como si fuera un <...> forma.
En la práctica, todos los compiladores que conozco crean una lista de lugares utilizando las opciones -I o /I , seguidas por una cantidad de lugares "estándar" y definidos por el compilador. Esta lista es para <...> ; "..." se busca en el mismo directorio que el archivo incluido, luego se trata como un <...> . (Algunos compiladores, al menos, también tienen opciones para agregar a la lista para "..." ).
No estoy seguro de lo que está sucediendo con respecto a la biblioteca. Normalmente, al utilizar una biblioteca de terceros, debe agregar una o más opciones -I o /I para indicar al compilador dónde encontrar sus encabezados. Una vez que haya hecho eso, tanto su código como el código de la biblioteca deberían encontrar todos los encabezados necesarios. El único caso en el que puedo pensar que una inclusión podría funcionar en un encabezado de biblioteca, y no en sus propios encabezados, es un estilo "..." incluir en un encabezado de biblioteca que se incluyó desde otro encabezado de biblioteca, usando un especificador de ruta, p.ej:
LibraryFile1.hpp:
#include "Subdir/LibraryFile2.hpp"
LibraryFile2.hpp:
#include "LibraryFile3.hpp"
Le habrá indicado al compilador que busque los encabezados (usando la opción -I ) en algo como LibraryRoot/include , que es donde se encuentra LibraryFile1.hpp ; LibraryFile2.hpp es relativo a esta ubicación, y en LibraryFile2.hpp , el compilador encuentra LibraryFile3.hpp porque está en el mismo directorio que el archivo que lo incluye. Si intenta incluir LibraryFile3.hpp directamente, sin embargo, el compilador no lo encontrará.