Pourquoi avoir des fichiers d'en-tête .fichiers cpp?

La compilation C++

Une compilation en C++ se fait en 2 phases principales:

1. La première est la compilation de "source", des fichiers texte en binaire "objet" des fichiers: Le fichier CPP est le fichier compilé et est compilé sans connaître les autres fichiers CPP (ou même les bibliothèques), à moins que la fed biais de la crue de la déclaration ou de l'en-tête de l'inclusion. Le fichier CPP est généralement compilé dans un .OBJ ou .O "objet" fichier.

2. Le second est le lien entre tous les "objets" des fichiers, et donc, la création de la finale de fichier binaire (soit une bibliothèque ou d'un fichier exécutable).

D'où vient la centrale de tenir dans tout ce processus?

Un pauvre solitaire d'un fichier CPP...

La compilation de chaque fichier CPP est indépendant de tous les autres fichiers CPP, ce qui signifie que si A.CPP besoin d'un symbole défini dans B.CPP comme par exemple:

//A.CPP
void doSomething()
{
   doSomethingElse(); //Defined in B.CPP
}

//B.CPP
void doSomethingElse()
{
   //Etc.
}

Il ne compile pas car A.CPP n'a aucun moyen de savoir "doSomethingElse" existe... à Moins qu'il y est une déclaration A.CPP comme par exemple:

//A.CPP
void doSomethingElse() ; //From B.CPP

void doSomething()
{
   doSomethingElse() ; //Defined in B.CPP
}

Alors, si vous avez C.CPP qui utilise le même symbole, ensuite, vous copiez/collez la déclaration...

COPIER/COLLER ALERTE!

Oui, il y a un problème. Copie/colle sont dangereux et difficile à maintenir. Ce qui signifie que ce serait cool si on avait une certaine façon de ne PAS copier/coller, et continuent à déclarer le symbole... Comment pouvons-nous le faire? Par l'include d'un fichier texte, qui est communément suffixé par .h, .hxx, .h++ ou, mon préféré pour les fichiers C++, .hpp:

//B.HPP (here, we decided to declare every symbol defined in B.CPP)
void doSomethingElse() ;

//A.CPP
#include "B.HPP"

void doSomething()
{
   doSomethingElse() ; //Defined in B.CPP
}

//B.CPP
#include "B.HPP"

void doSomethingElse()
{
   //Etc.
}

//C.CPP
#include "B.HPP"

void doSomethingAgain()
{
   doSomethingElse() ; //Defined in B.CPP
}

Comment include travail?

Y compris un fichier, en substance, d'analyser puis de copier-coller son contenu dans le fichier CPP.

Par exemple, dans le code suivant, avec l'A. HPP-tête:

//A.HPP
void someFunction();
void someOtherFunction();

... la source B.CPP:

//B.CPP
#include "A.HPP"

void doSomething()
{
   //Etc.
}

... deviendra après l'inclusion:

//B.CPP
void someFunction();
void someOtherFunction();

void doSomething()
{
   //Etc.
}

Une petite chose - pourquoi inclure B. HPP dans B.CPP?

Dans le cas actuel, il n'est pas nécessaire, et B. HPP a la doSomethingElse déclaration de la fonction, et B.CPP a la doSomethingElse définition de la fonction (qui est, par elle-même une déclaration). Mais dans un cas plus général, où B. PHP est utilisé pour les déclarations (et code en ligne), il n'y aurait pas de définition correspondant (par exemple, les énumérations, de la plaine aux structures, etc.), donc l'inclure pourraient être nécessaires si B.CPP utilise ceux de la déclaration de B. HPP. Dans l'ensemble, il est "de bon goût" pour une source d'inclure par défaut son en-tête.

Conclusion

Le fichier d'en-tête est donc nécessaire, parce que le compilateur C++ est incapable de recherche de symbole déclarations seul, et vous devez donc l'aider en incluant ces déclarations.

Un dernier mot: Vous devriez mettre de l'en-tête des gardes autour du contenu de votre PHP les fichiers, pour être sûr de multiples inclusions de ne pas casser quelque chose, mais dans l'ensemble, je crois que la raison principale de l'existence de PHP des fichiers est expliqué ci-dessus.

#ifndef B_HPP_
#define B_HPP_

//The declarations in the B.hpp file

#endif //B_HPP_

Parce qu'en C++, le code exécutable final ne portent pas le symbole de l'information, c'est plus ou moins pure du code machine.

Donc, vous avez besoin d'un moyen de décrire l'interface d'un morceau de code, qui est distinct du code lui-même. Cette description se trouve dans le fichier d'en-tête.

Parce que les gens qui ont conçu la bibliothèque de format n'est pas pour les "déchets" de l'espace pour les très rarement utilisé des informations comme le préprocesseur C macros et les déclarations de fonction.

Car vous avez besoin de cette info pour dire à votre compilateur "cette fonction n'est disponible que plus tard, lorsque l'éditeur de liens est en train de faire son travail", ils ont dû venir avec un deuxième fichier où ce partage d'informations pourraient être stockées.

La plupart des langues après le C/C++ de stocker cette information dans la sortie (le bytecode Java, par exemple) ou qu'ils n'utilisent pas un fichier de format, toujours distribué sous forme de code source et le compiler à la volée (Python, Perl).

Souvent, vous voulez avoir une définition d'une interface sans avoir à expédier l'ensemble du code. Par exemple, si vous avez une bibliothèque partagée, vous expédier un fichier d'en-tête avec elle qui définit toutes les fonctions et les symboles utilisés dans la bibliothèque partagée. Sans les fichiers d'en-tête, vous devez envoyer le source.

Sein d'un même projet, les fichiers d'en-tête sont utilisés, à mon humble avis, pour au moins deux raisons:

• Clarté, qui est, en gardant les interfaces distinctes de la mise en œuvre, il est plus facile de lire le code
• Moment de la compilation. En utilisant uniquement l'interface, si possible, au lieu de la pleine mise en œuvre, le temps de compilation peut être réduite car le compilateur ne peut se contenter de faire une référence à l'interface au lieu d'avoir à analyser le code (qui, idéalement, n'ont besoin d'être fait qu'une seule fois).