estoy jugando un poco con gmock y se dio cuenta que contiene esta línea:¿Cuándo se puede omitir la extensión del archivo en una directiva #include?
#include <tuple>
lo que habría esperado tuple.h.
¿Cuándo está permitido excluir la extensión y le da a la directiva un significado diferente?
El C++ cabeceras estándar no tienen un sufijo ".h". Creo que la razón es que hubo muchas implementaciones diferentes de estándares que romperían el estándar. Por lo tanto, en lugar de exigir que los proveedores cambien el encabezado exitante "iostream.h" (por ejemplo) para cumplir con los estándares (lo que rompería el código de usuario existente), el comité de estándares decidió que eliminarían el sufijo (que, creo que no entonces la implementación existente ya lo había hecho).
De esta forma, los programas existentes no estándar seguirían funcionando con las bibliotecas no estándar del proveedor. Cuando el usuario quería hacer que sus programas cumplieran con los estándares, uno de los pasos que tomarían es cambiar la directiva "#include" para soltar el sufijo ".h".
Así
#include <iostream> // include the standard library version
#include <iostream.h> // include a vendor specific version (which by
// now might well be the same)
Como han mencionado otras respuestas, escritores de las bibliotecas no estándar puede elegir cualquiera convención de nomenclatura, pero me gustaría pensar que les gustaría seguir utilizando ".h" o ".hpp" (como se ha hecho Boost) por un par de razones:
Tenga en cuenta que un problema similar ocurrió cuando el comité fue a añadir mapas de hash a la STL - se encontraron con que ya hay muchos (diferentes) hash_map implementaciones que existen, así que en vez de salir con una norma que rompe Hoy hay muchas cosas que llaman la implementación estándar "unordered_map". Se suponía que los espacios de nombres ayudaban a evitar este tipo de salto a través de los aros, pero no parecía funcionar lo suficientemente bien (ni se usaba lo suficientemente bien) para permitirles usar el nombre más natural sin romper un montón de código.
Tenga en cuenta que para las cabeceras 'C', C++ le permite incluir una variante <cxxxxxx> o . El que comienza con 'c' y no tiene el sufijo ".h" pone sus declaraciones en el espacio de nombres std (y posiblemente el espacio de nombres global), los que tienen el sufijo ".h" ponen los nombres en el espacio de nombres global (algunos compiladores también poner los nombres en el espacio de nombres std - no está claro para mí si eso cumple con los estándares, aunque no veo el daño).
Si el archivo se llama tuple entonces necesita #include <tuple> si es nombrado tuple.h entonces necesita #include <tuple.h>
Es tan simple como eso. No estás omitiendo ninguna extensión.
Incluye un archivo que simplemente se llama "tuple": el archivo en sí carece de una extensión.
El estándar putativo para incluir archivos en C++ es nombrarlos sin la extensión .h; muchos escritores de bibliotecas siguen este estándar (STL, etc.) pero otros no.
Hasta donde yo sé, los archivos Boost tienen la extensión .hpp. – mannicken
¡Oh! Tienes razón. Repararé la respuesta. – Crashworks
Según entendí, #include tuple "apuntaría" a tuple.h.
mira esto: iostream vs iostream.h
El artículo vinculado es bastante bueno. –
El compilador puede decidir que sí. La conversión de la cadena en el código fuente para completar la ruta del archivo para el sistema operativo depende del compilador. El prefijo de directorio es bastante común, pero las extensiones de sufijo no son – MSalters
artículo muy interesante, thx –
No pasa nada especial. El archivo simplemente se llama tuple.
La razón de esto ... que los encabezados de biblioteca estándar no tienen extensión de archivo se deben a namespace s.
Los espacios de nombres se añadieron a la altura de C++ al final del partido con el estándar C++ 98, incluyendo el std espacio de nombres que todas las entidades de la biblioteca estándar residen.
Cuando la biblioteca estándar que cambiar a la std espacio de nombres, eso significaba que todo el código C++ existente se rompería, ya que todos esperaban que la biblioteca estuviera en el espacio de nombres global. La solución fue dejar solos los viejos archivos de encabezado "dot-h" y proporcionar la biblioteca de espacio de nombres en los archivos que no tienen extensión.
De esta manera, el código anterior que #include<iosteam.h> podría esperar un cout global, mientras que el nuevo código podría #include<iostream> y esperar un std::cout.
Además de las buenas respuestas ya publicadas, debe tenerse en cuenta que el estándar C++ no requiere la directiva "#include <iostream>" para leer un archivo llamado "iostream", o incluso "iostream.h". Podría llamarse "fuzzball". O bien, no puede existir ningún archivo correspondiente y las definiciones se integran en el compilador y se activan mediante la directiva include.
gente,
creo que el acuerdo es: # include <lib> Allways pre pende/lib/include a la ruta de búsqueda (el .h se infrerred), mientras que # include <lib.h> búsquedas solo -I < ruta nombre >.
Tenga en cuenta que podría estar equivocado ... Así es como creo que funciona (en Forte cc en Solaris).
Piensa mal: el estándar C++ no especifica las rutas de búsqueda. –
Estrecho evitó un -1 al admitir que podría estar equivocado ... lo que es. :-) –
otro (probablemente el motivo principal :)) podría ser señalar que los encabezados estándar no requieren ser archivos en absoluto. por lo que podrían haber decidido soltar el ".h", porque sugiere una extensión de archivo. –
Esto ha sido cierto desde ANSI C 1989, que tiene como nota al pie: "Un encabezado no es necesariamente un archivo fuente ..." Por cierto, ¿alguien sabe de un compilador que hace algo diferente a los archivos fuente normales para encabezados estándar ? –
@MichaelBurr ¿Los encabezados precompilados no encajarían en esa factura? –