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".