Information sur compilation

J'aimerais me faire eclaircir sur des petits points lors de la compilation d'un programme (surtout par rapport au .h)

Les constantes declarees dans le .h sont-elles inserees dans chaques obj qui en faisait reference?

A quoi l'utilite de declarer une fonction dans un .h?

Je vais essayer de te répondre, mais je ne te garantie pas l'exactitude de mes explications :p

Dès que tu inclus un .h, les constantes que tu as déclarées dedans sont en effet utilisables par tous les objets.

L'intéret du .h est surtout la lisibilité de ton code (le "squelette" de tes objets dans le .h, et le code de ses fonctions dans le .cpp). Mis à part ca, ca te permet de ne pas insérer 15 fois le meme code lors de la compilation, si tu dois inclure plusieurs fois tes fichiers. En effet, dans ton .h, tu mets un truc du genre :

#ifndef __tonnom_H__
#define __tonnom_H__
...
#endif

Donc à la compilation, ton fichier ne sera inclu qu'une seule fois... Sans ca, à chaque #include, ton code serait ajouté (problème de taille, et tes variables globales pourraient etre définiers 36 fois, par exemple)


J'espère ne pas avoir dit de bétises ;)

C"est bien beau mais que ce passe-t-il lorsque je compile une librairie qui inclus des constantes globales et que je compile des fichiers qui font references a ces constantes.... ces constantes sont definies ou au juste?

Elles sont definis statique je crois !

A la limite, on aurait pas besoin de declarer des fonctions!

le #include "xxx.h" est finalement très simple : tout se passe comme si le texte de xxx.h était écrit dans le fichier à l'endroit où se trouve la directive #include. A partir de là, tu as le fonctionnement du couplage d'un .h avec le(s) .cpp. Cela signifie que le .h ne doit pas comporter la définition de variables, mais seulement, si besoin, leur déclaration en extern. Par contre il comporte en général la définition des types , des constantes (notamment des enum), qui peuvent être utilisées dans d'autres unités de compilation et c'est pourquoi il est souvent "protégé" ,comme l'explique ChriGoLioNaDor, contre des inclusions multiples qui provoqueraient une redéfinition de ces identificateurs

Mais justement, les enum et constantes doivent etre en memoire... mais ou?

Comment se contruit un exécutable?

A partir de chaque .cpp, le compilateur fait un fichier objet (.o ou des .obj suivant le système).

On peut si on veut rassembler des fichiers objets dans des bibliothèques. Il y en a de deux types, des bibliothèques statiques (.a/.lib) et des bibliothèques dynamiques (.so/.dll); je reviendrai sur la différence entre les deux plus tard.

Ensuite l'éditeur de liens prend une série de fichiers objet et de bibliothèques pour en faire un exécutable. Parmis ces fichiers objet et ces bibliothèques, la plupart sont spécifiées par l'utilisateur mais certains sont fournis par le compilateur (ils contiennent le code de démarrage et la bibliothèque standard). Les détails varient, mais en gros tous les fichiers objet se retrouvent dans l'exécutable, l'éditeur de liens sort des bibliothèques statiques les fichiers objets nécessaires pour remplir les dépendances (mais pas les autres) et indique dans l'exécutable qu'il faudra récupérer les bibliothèques dynamiques lors de l'exécution.

A l'execution, le système d'exploitation lit l'exécutable, récupère les bibliothèques dynamiques et crée un processus auquel il passe la main.

Revenons au processus de compilation. Pour pouvoir compiler correctement un appel de fonction, le compilateur doit connaitre non seulement le nom de la fonction mais aussi le type des paramètres. Pour permettre de vérifier qu'on passe bien les bons types, le C++ demande qu'on ait vu une déclaration de la fonction avant tout appel. De même pour utiliser un type, il faut avoir vu avant sa définition.

Plutôt que de recopier dans chaque .cpp la déclaration des fonctions utilisées et la définition des types et éviter des erreurs, on les mets dans des fichiers qu'on inclus, ce qui a le même effet que de recopier le contenu à l'endroit de la directive d'inclusion.

Les fichiers inclus (on parle d'entete) peuvent avoir besoin de déclarations ou de définition contenues dans d'autres entêtes (par exemple pour hériter d'une classe, il faut avoir vu la définition de la classe). On met donc des directives d'inclusion dans les entêtes. Il y a donc un risque qu'un même entete soit inclus plusieurs fois. Mais certaines choses (les définitions de classes par exemple) ne peuvent pas être répétée. On a donc l'habitude de mettre le contenu des fichiers d'entetes dans une structure

Code:

---

1 2 3 4 5 6

#ifndef TOTO_H_INCLUDED #define TOTO_H_INCLUDED   // le contenu de toto.h   #endif

---

qui fait que la répétition n'est pas vue.

Pour revenir à tes constantes: j'en vois de trois types:

• celles du préprocesseur: le remplacement est purement textuel, la constante est remplacée par sa valeur et elle se comporte comme des littéraux;
• celles définies avec
  Code:

  ---

  int const i = 42;

  ---

  on une liaison interne: c'est à dire que si le compilateur décide qu'il faut lui réserver de la mémoire (ce qui n'est pas obligatoire, il peut souvent remplacer i par sa valeur simplement, comme avec le préprocesseur), cette mémoire ne sera pas partagée entre fichiers objet
• celles déclarées avec
  Code:

  ---

  extern int const i;

  ---

  et définies avec
  Code:

  ---

  extern int const i = 42;

  ---

  dans ce cas la liaison est externe et il y aura réservation de la mémoire dans l'unique .cpp qui contient la définition

Il me semble qu'il est possible de declarer une constante dans un .h de cette facon :

Code:

---

const int i = 42;

---

Il me semble que ca passe a la compilation tout comme le fait de faire

Code:

---

1 2 3 4 5

class tata { public: const int i = 42; };

---

Dans les deux cas je crois que le compilateur rend la constante statique a l'objet qu'il la inclus.

Pour revenir au fonction, le compilateur pourrait aisement creer la decoration pour l'appel de la fonction lors du link... il n'aurait pas besoin de definition! C'est sure que ce n'est pas souhaitable...question de bien savoir programmer et avoir un peu d'ordre.

Citation:

---

Envoyé par oxor3

Il me semble qu'il est possible de declarer une constante dans un .h de cette facon :

Code:

---

const int i = 42;

---

Il me semble que ca passe a la compilation tout comme le fait de faire

Code:

---

1 2 3 4 5

class tata { public: const int i = 42; };

---

Dans les deux cas je crois que le compilateur rend la constante statique a l'objet qu'il la inclus.

---

Non, les deux cas sont différents. Dans le premier cas, la liaison (le linkage) de i est bien interne, c'est en effet la même chose qu'on aurait eu en mettant static.

Dans le deuxième cas, la liaison est externe mais on n'est pas obligé de mettre une définition pour tata::i tant qu'on n'en prend pas l'adresse. Le programme suivant en trois unités de compilation:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

#include <iostream> #include <ostream> #include <iomanip>   int const* f(); int const* g(); int const* h(); int const* j();   int main() { std::cout << std::boolalpha; std::cout << (f() == g()) << std::endl; std::cout << (h() == j()) << std::endl; }

---

Code:

---

1 2 3 4 5 6 7

struct C { static int const j = 42; }; int const i = C::j;   int const* f() { return &i; } int const* h() { return &C::j; }

---

Code:

---

1 2 3 4 5 6 7 8 9 10

struct C { static int const j = 42; };   int const C::j;   int const i = 42;   int const* g() { return &i; } int const* j() { return &C::j; }

---

affiche

Code:

---

1 2	false true

---

et ne passe pas l'édition de liens si

Code:

---

int const C::j;

---

n'est pas présent.

Citation:

---

Pour revenir au fonction, le compilateur pourrait aisement creer la decoration pour l'appel de la fonction lors du link... il n'aurait pas besoin de definition! C'est sure que ce n'est pas souhaitable...question de bien savoir programmer et avoir un peu d'ordre.

---

Je ne suis pas sur d'avoir compris ce que tu veux dire. Mais si j'ai bien compris entre les template, la surchage et les conversions implicites, il faudrait que l'éditeur de liens fasse beaucoup plus que ce qu'il fait traditionnellement.

Tu as bien compris ce que je veux dire.... on aurait plus de travail à l'édition des liens