Bonjour
J'essaye de developper une application en C actuellement et pour se faire j'ai besoin d'inclure dans un fichier .h un autre fichier .h. Cependant est ce que ds le #include, présent ds mon premier fichier.h, je me le chemin a partir d'ici vers l'autre fichier.h ? ou je pars de l'endroit ou mon main se trouve?
 
un petit exemple sera plus simple.
j'ai un dossier "travail" qui contient, mon "main", un dossier "include" et un dossier "lib".  
 
Dans le dossier include, j'ai un fichier "math.h" ou je veux inclure le fichier calcul.h qui se trouve dans lib.
Je fais #include "lib/calcul.h"
ou
#include "../lib/calcul.h" ?
 
merci d'avance

Cela peut varier d'un compilateur à l'autre (par exemple, avant qu'il n'y ait de standards bien établis, le Borland C ne traitait pas les includes exactement de la même manière que le Microsoft C). En général, on ne met pas le chemin. Ce dernier est habituellement spécifié dans les paramètres de compilation.

Il y a un standard bien établi?  Je n'en connais pas.  Et je ne connais qu'une tentative de synthétiser les comportements observés (http://www.bourguet.org/cpp/include).  S'il y en a d'autres -- comportement ou tentative de les rassembler tous --, je suis intéressé.
 
En ce qui concerne les chemins relatifs, je ne me souviens pas avoir jamais utilisé un compilateur qui considérait les chemins relatifs autrement que qu'un nom de fichier simple: il est considéré relativement à tous les répertoires cherchés (donc une forme avec "" va généralement le chercher relativement au fichier contenant la directive si on n'a pas désactivé volontairement ou involontairement la possibilité).

Voir l'article de Wikipedia sur le preprocesseur qui donne quelques renseignements de base : http://en.wikipedia.org/wiki/C_preprocessor
 
Voir le standard actuel du C qui est en lien en bas de la page de Wikipedia : http://www.open-std.org/jtc1/sc22/ [...] /n1124.pdf
Ce document de 500 pages contient deux paragraphes (6.4.7 Header names et 7.1.2 Standard headers) plus particulièrement dédiés à la directive #include.
 
Voir la documentation du compilateur, par exemple la documentation de Microsoft Visual Studio 2005 sur la directive #include : http://msdn.microsoft.com/en-us/li [...] S.80).aspx . La description commence par ce qui est standard et se poursuit par une partie qui est spécifique à ce compilateur.
 
Bref, comme dit précédemment, d'habitude on ne met pas le chemin, juste le nom du fichier. Le chemin est indiqué, si besoin est, dans les paramètres de compilation que l'on spédifie soit sur la ligne de commande, soit à l'aide d'une boite de dialogue de configuration du projet.

Rien sur le sujet qui nous concerne: où précisément sont cherchés les fichiers inclus.

idem

Comme je le disais: rien de standardisé -- même de manière informelle -- et pas de ressources décrivant les comportements observés pour s'assurer que ce qu'on utilise a un minum de portabilité.

Une habitude qui est beaucoup moins universelle que tu ne le penses.  Il est courant de spécifier un répertoire pour des fichiers publics (voir POSIX et tous les <sys/XXX> par exemple, en C++ un exemple bien connu de cette technique est boost dont on inclut les entêtes par <boost/XXX> ). Il est encore plus courant de spécifier des répertoires pour des fichiers privés inclus dans des fichiers publics, en les incluant avec la forme "" (voir le répertoire bits de gcc).

Ca suffit. Vous êtes télépathe ? Vous êtes de la police de la pensée ? Non, alors s'il vous plait, ne faites pas comme d'autres personnes de ce forum qui invectivent et tutoient ceux qui répondent bénévolement et gentiment pour aider celui qui pose la question initialement. Sur les forums plus civilisés, par exemple les forums anglais, les gens ne critiquent pas les solutions présentées par d'autres intervenants. Tant pis si quelqu'un d'autre se trompe. Ce qui compte c'est que chacun puisse exposer son point de vue, s'il est sincère, par rapport à la question initiale sans se montrer désagréable vis-à-vis des autres intervenants.
 
Bien sûr que je connais boost/.. et sys/... et même ddk/.... etc. Je n'ai pas dit qu'il ne fallait jamais mettre un chemin, ou du moins un partie de chemin dans une directive #include. Mais la question posée concerne un fichier ".h" qui ne fait partie des headers standards. Donc, ce header ne doit pas, en théorie, être mis dans le répertoire, ou le sous-répertoire des headers standards. Sa meilleure place, selon moi et ma petitie expérience de 20 ans de programmation en C, mais on peut penser autrement, est de mettre ce header maison dans un répertoire qui est référencé dans le makefile.

 
Et on arrive sur un forum façon developpez.con ou le rapport signale sur bruit est proche de 0.
 
Aprés deux points :
1/ on ne te retiens pas
2/ faudra aussi apprendre à lire le sarcasme et l'ironie dans les posts et arreter de prendre otut au zeroieme degré

Pourtant, il existe des sites bien modérés qui prospèrent. Le problème de developpez.com doit donc être causé par autre chose.  

Merci, ça fait plaisir ! C'est le monde à l'envers ! Il faudrait au contraire garder ceux qui répondent aux questions posées, et ne pas retenir ceux qui trollent en prenant à partie les autres forumeurs.

Qu'est-ce que c'est que ce nouveau procès d'intention ? Pourquoi pensez-vous que je ne connaisse pas le sarcasme et l'ironie, etc. C'est un jugement qui est faux. Arrêter de juger les autres.
 
Dans le "tu penses" cité plus haut, il n'y avait pas de sarcasme et d'ironie. C'était juste pour me contredire. Cette contradiction était injustifiée parce que je n'avais pas dit que l'absence de chemin dans le #include était "universel" mais "habituel", et je l'avais dit en connaissance de cause. Je fais du C depuis vingt ans. J'ai vu des centaines de milliers de code C écrites par des personnes très diverses, et j'ai constaté qu'il y a très peu de cas ou le chemin (surtout le chemin absolu) était indiqué dans cette directive du préprocesseur.
 
Quand à l'absence de norme, là encore, on a cherché à me contredire d'une manière exagérée car le C a une norme ISO. J'ai connu l'époque antérieur, où il n'y avait pas encore de norme, où plutôt quand le livre de K & R était la norme sans être très suivie. C'était autre chose que maintenant où la plupart des compilateurs C sont assez proche les uns des autres, surtout sur le sujet ed la directive #include. Par ailleurs, comme c'est une question d'un débutant, il ne me semble pas opportun de souligner que la directive #include serait utilisée de manière très différente d'un compilateur à l'autre, car les différences sur ce point précis sont en réalité assez minimes, et notamment, il ne faudrait pas que ce débutant, comme tant d'autres, tombent dans le piège des anciens et des nouveaux headers standards du C++ (iostream, etc), en pensant qu'il n'y aurait pas de norme.
 
Enfin, vous pouvez continuer à troller et à dénigrer les autres. De mon côté, je continuerai à essayer de répondre aux questions des internautes quand j'ai la réponse et à me défendre quand on me prend à parti avec des "tu penses" et des "apprends à lire".

 
Bah si tu avais sortie ça et juste ça sans te braquer sur le 'tu penses", on aurait rien dit
 
PS : se renseigner sur la signification de avant de bondir

Je comprend pas trop ce que tu veux dire sur developpez.com. Je trouve que là bas il y a très peu de bruit, en tout cas beaucoup moins qu'ici, parce que les modérateurs enlèvent systématiquemen tout ce qui est "bruit". En tout cas sur les forums C.

Merci !