Discussion :

[mok_tun]

Bonjour à tous,
J'utilise Visual Studio 2013 et je voudrais prendre vos avis concernant le fichier stdafx.h.
Car à chaque fois que je crée un projet, ce fichier apparaît avec l'obligation de l'inclure.
Est-ce que il y a quelqu'un pourrait m expliquer son utilité?
Est-ce qu'il faut définir tous les #include de fichiers header de l'utilisateur dans stdafx.h ?
Est-ce que ce nécessaire de l'utiliser?

Merci

[Bousk]

C'est le header précompilé. Ce n'est en aucun cas une obligation. Ca permet d'inclure des fichiers dans chaque unité de compilation et compiler une partie nécessaire au reste du projet dans l'implémentation qui va souvent avec (stdafx.cpp).

[koala01]

Salut,

Le fait est que la notion d'en-têtes pré compilées est une notion qui peut à la fois être la meilleure et la pire des choses. Mais pour comprendre cela, il faut comprendre ce qui se passe avec les fichiers d'en-tête.

Il faut donc commencer par comprendre comment fonctionne l'inclusion de fichiers d'en-tête . Et ca, c'est relativement simple: quand le préprocesseur va rencontrer une ligne#include <un fichier quelconque il va "tout simplement" remplacer la ligne en question par le contenu du fichier indiqué.

Si bien que, par la suite, le préprocesseur et le compilateur vont utiliser le contenu de ce fichier exactement comme ce qu'il est désormais: une partie intégrante de l'unité de compilation (pour faire simple: le fichier *.cpp) dont il fait désormais partie.

Seulement, le fait de rajouter ainsi le contenu de fichiers entiers, et, pire encore, de le faire de manière récursive (*) aura forcément pour résultat que le préprocesseur et le compilateur devront... traiter l'ensemble du code que le fichier inclus contient. Et ca, ca prend forcément du temps.

Pire encore, si on inclut un fichier d'en-tête dans vingt unités de compilation (dans vingt fichier .cpp), comme le préprocesseur et le compilateur oublient systématiquement tout ce qu'ils ont pu faire pendant qu'ils traitaient une unité de compilation particulière au moment de passer à la suivante, le contenu du fichier d'en-tête sera traité "une nouvelle fois" pour chaque unité de compilation dans laquelle il est inclus.

Tu l'auras sans doute compris, mais, comme ce sont les petits ruisseaux qui font les grands fleuves, même si on peut considérer que cela ne prend pas "si longtemps que cela" de traiter à chaque fois le même fichier d'en-tête, quand il faut le faire vingt, trente ou XXX fois, le temps passé à traiter le fichier d'en-tête fini par s'accumuler, et par représenter une perte de "temps perceptible".

L'idée qu'il y a derrière les en-têtes précompilées est donc de se dire : on va faire tous les traitements requis par les différents fichiers d'en-tête une bonne fois pour toutes, et on va garder le résultat bien au chaud, de cette manière, au lieu d'inclure vingt fois le fichier d'en-tête et de devoir le traiter vingt fois, nous pourrons réutiliser le résultat du traitement et... gagner du temps.

L'idée est... merveilleuse, en soi... Mais elle présente malgré tout deux problèmes majeurs:

Le premier, c'est que l'on va souvent demander de pré compiler plusieurs fichiers d'en-tête. Tant qu'à faire, autant faire en sorte que tous les fichiers d'en-tête dont on a régulièrement besoins soient pré compilés en une fois, non

A priori, oui, mais cela a un effet retors, car, du coup, lorsque l'on inclura stdafx.h (qui est le fichier qui permettra, dans le cas présent, d'utiliser les en-têtes précompilées) dans une unité de compilation, nous permettrons à cette unité de compilation d'avoir connaissance... de toutes les fonctionnalités décalrées dans tous les fichiers d'en-tête qui ont été pré compilés.

Dans certaines circonstances (par exemple: si tous les fichiers d'en-tête définissant l'ensemble des classes dérivées d'une hiérarchie de classe ont été pré compilés) cela peut être vachement problématique au niveau conceptuel, car le développeur aura l'impression (tout à fait fausse au demeurant) que, s'il a accès à la définition d'une classe dérivée, il n'a sans doute aucune raison de ne pas essayer d'y accéder directement.

Le deuxième problème que pose le système, c'est que la pré compilation des fichiers d'en-tête est un processus qui prend du temps, quoi que l'on en dise. Or, il suffit que l'on change une seule virgule dans un des fichiers d'en-tête que l'on veut pré compiler pour... que le processus doive être repris à zéro.

Du coup, si tu décides de pré compiler un fichier d'en-tête qui n'est pas parfaitement stable (comprends: qui ne cours aucun risque d'être modifié avant plusieurs mois, ou, plutôt, qui court le risque d'être modifié dix fois sur la journée), tu vas rapidement perdre tout le bénéfice du fait d'avoir recouru à un tel système.

En plus, il faut savoir que, même si la notion d'en-tête pré compilée existe pour la plupart des compilateur, la manière dont elle est mise en oeuvre varie énormément d'un compilateur à l'autre, au point d'être totalement incompatible avec "un autre compilateur".

Si bien que le meilleur conseil que l'on puisse te donner à ce sujet ne peut qu'être une réponse de normand, à savoir:

Les en-tête pré compilées sont une pratique qui peut être très utiles, si elles sont utilisées à bon escient, c'est à dire:

1. Si tu veilles à n'inclure que des fichiers d'en-tête parfaitement stable (par exemple: les fichiers d'en-tête de la bibliothèque standard ou d'une bibliothèque externe) et
2. Si tu n'envisage pas de rendre ton code portable "dans l'immédiat".