Quando puoi omettere l’estensione del file in una direttiva #include?

Sto giocando con gmock e ho notato che contiene questa linea:

#include  

Mi sarei aspettato tuple.h .

Quando va bene escludere l’estensione e conferisce alla direttiva un significato diverso?

Le intestazioni standard C ++ non hanno un suffisso “.h”. Credo che la ragione sia che ci sono state molte, diverse implementazioni pre-standard che lo standard si sarebbe rotto. Quindi, invece di richiedere che i produttori cambino l’intestazione “iostream.h” (ad esempio) per essere conformi agli standard (che potrebbe rompere il codice dell’utente esistente), il comitato degli standard ha deciso che avrebbero rilasciato il suffisso (che, credo, non allora l’implementazione esistente aveva già fatto).

In questo modo, i programmi esistenti e non standard continuerebbero a funzionare utilizzando le librerie non standard del fornitore. Quando l’utente voleva rendere i propri programmi conformi agli standard, uno dei passi che avrebbero preso è quello di cambiare la direttiva ” #include ” per eliminare il suffisso “.h”.

Così

 #include  // include the standard library version #include  // include a vendor specific version (which by // now might well be the same) 

Come hanno già detto altre risposte, gli scrittori di librerie non standard possono scegliere le convenzioni di denominazione, ma credo che vorrebbero continuare a usare “.h” o “.hpp” (come ha fatto Boost) per un paio di motivi:

  1. se e quando la libreria viene standardizzata, la versione standard non sovrascriverà automaticamente quella precedente, non standard (causando il codice utente rotto con ogni probabilità)
  2. sembra essere una convenzione (più o meno) che le intestazioni senza suffisso siano librerie standard e quelle con un suffisso (diverso dalle vecchie intestazioni C) non standard.

Si noti che un problema simile si è verificato quando il comitato è andato ad aggiungere mappe hash all’STL – hanno scoperto che esistono già molte (diverse) implementazioni hash_map , quindi invece di creare uno standard che rompe un sacco di cose là fuori oggi chiamano l’implementazione standard ” unordered_map “. I namespace dovevano aiutare a prevenire questo tipo di salti mortali, ma non sembrava funzionare abbastanza bene (o essere usato abbastanza bene) per consentire loro di usare il nome più naturale senza rompere un sacco di codice.

Nota che per le intestazioni ‘C’, C ++ ti permette di includere una o . Quella che inizia con ‘c’ e non ha suffisso “.h” inserisce le loro dichiarazioni nello spazio dei nomi std (e possibilmente nello spazio dei nomi globale), quelli con il suffisso “.h” mettono i nomi nello spazio dei nomi globale (alcuni compilatori anche metti i nomi nello spazio dei nomi std – non è chiaro per me se questo è conforms agli standard, anche se non vedo il danno).

Se il file è denominato tuple allora è necessario #include se si chiama tuple.h allora è necessario #include

E ‘così semplice. Non stai omettendo alcuna estensione.

Include un file chiamato semplicemente “tupla” – il file stesso manca di un’estensione.

Lo standard putativo per i file include di C ++ è di nominarli senza l’estensione .h; molti scrittori di librerie seguono questo standard (STL, ecc.) ma altri no.

Non c’è niente di speciale in corso. Il file è semplicemente chiamato tuple .

Il motivo per questo … che le intestazioni di libreria standard non hanno estensione di file sono a causa dello namespace dei namespace .

I namespace sono stati aggiunti allo standard C ++ in ritardo con lo standard C ++ 98, incluso lo spazio dei nomi std cui risiedono tutte le entity framework di libreria standard.

Quando la libreria standard veniva spostata nello spazio dei nomi std , ciò significava che tutto il codice C ++ esistente si sarebbe interrotto dal momento in cui tutti si aspettavano che la libreria si trovasse nello spazio dei nomi globale. La soluzione era di lasciare da solo i vecchi file di intestazione “dot-h” e fornire la libreria namespace in file privi di estensione.

In questo modo, il vecchio codice che avrebbe #include poteva aspettarsi un cout globale mentre il nuovo codice poteva #include e aspettarsi un std::cout .

La mia comprensione era che #include tuple avrebbe “puntato” su tuple.h.

Controlla questo: iostream vs iostream.h

Oltre alle risposte corrette già pubblicate, va notato che lo standard C ++ non richiede la direttiva “# include ” per leggere un file chiamato “iostream”, o anche “iostream.h”. Potrebbe essere chiamato “fuzzball”. Oppure, non esiste alcun file corrispondente e le definizioni devono essere incorporate nel compilatore e triggerste dalla direttiva include.

gente,

Penso che l’accordo sia: #include allways pre- impends / lib / include al path di ricerca (il .h è infranto) mentre #include cerca solo -I .

Si noti che potrei sbagliarmi … È solo come penso che funzioni (in Forte cc su Solaris).