pas de #include dans un fichier d'en-tête ?
Le
gregg
Bonsoir,
Un professeur de faculté a "assassiné" mon code sous prétexte qu'on n'a
pas le droit "d'inclure un .h dans un .h".
(Il ne s'agit pas de <stdio.h>, mais de "xxx.h" personnels)
J'avoue que ça me choque un peu (j'ai appris le C en compulsant les
sources de FreeBSD, et accessoirement de la bibliothèque standard, et
cette façon de faire ne semble pas gêner)
Je ne vois pas vraiment d'argument contre une telle pratique.
Il ne risque pas d'y avoir inclusions multiples, ou récursives,
puisqu'il y a des gardes-fous ( #ifndef machin #define machin #endif)
Ca me paraît même plus dans l'esprit "déclaration de services".
J'ai lu la faq, mais cet aspect n'apparaît pas.
Enfin: quelle est votre pratique personnelle ?
Un professeur de faculté a "assassiné" mon code sous prétexte qu'on n'a
pas le droit "d'inclure un .h dans un .h".
(Il ne s'agit pas de <stdio.h>, mais de "xxx.h" personnels)
J'avoue que ça me choque un peu (j'ai appris le C en compulsant les
sources de FreeBSD, et accessoirement de la bibliothèque standard, et
cette façon de faire ne semble pas gêner)
Je ne vois pas vraiment d'argument contre une telle pratique.
Il ne risque pas d'y avoir inclusions multiples, ou récursives,
puisqu'il y a des gardes-fous ( #ifndef machin #define machin #endif)
Ca me paraît même plus dans l'esprit "déclaration de services".
J'ai lu la faq, mais cet aspect n'apparaît pas.
Enfin: quelle est votre pratique personnelle ?
Euh ? Pas sûr que je me sois bien expliqué, là.
J'ai un entête genre mode "conforme à la norme", parce que au lieu d'utiliser des mots clés
"compatibles" genre _Far ou __cdecl, les programmeurs ont laissé far et
cdecl. Et se moquent de corriger parce que "comme standard, c'est HS pour la norme" ;-).
Bien sûr, une solution, c'est comme tu le dis, d'écrire une version à moi de
stdio.h, avec d'abord des #define far _Far au début, puis #inclure (avec un
chemin absolu, donc fragile -- ce n'est pas sur Unix) le puis #undef far pour éliminer les horreurs qui gênent. Et ensuite insérer le
chemin d'accès à ce stdio.h perso _avant_ les INCLUDE normaux du
compilateurs.
Je trouve plus simple de prendre mon éditeur de texte et de modifier la
version online de
Un autre problème est quand je veux que du code à moi dans un projet public
passe sur un tel compilateur, tout en utilisant un de ces entêtes non
standard (c'est rare, mais cela m'est déjà arrivé; beaucoup moins souvent
que le premier cas, cependant). Alors là, oui, je passe par des
contournements (que je distribue avec le projet). Mais c'est très laid.
Antoine
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Je suis en DEA (recherche) et j'avoue que je programme comme mes confreres
de DESS (professionnel) a savoir, un #include "xxx.h" dans mes .h lorsqu'il
y en
a besoin.
En effet, a partir du moment ou tu utilise correctement les #ifndef,
#define, #endif
pas de problemes.
En quelle annee es-tu ? C'est quoi la section d'enseignement de ton prof?
Pareil...
J'inclus dans le .c pour tous les appels de foncitons...
Dans le .h des que j'ai besoin d'un type ou d'une structure definis
par un autre module...
--
Fanny
Hypnotiseur de castor
--------------2E64D4310CDEF28152FE9B16
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<html>
<blockquote TYPE=CITE>> Aie. J'ai peur que le débat sur les profs
ne soit rallumé...
<p>Euh, c'est pas vraiment là où je veux en venir... :(
<br>( j'ai constaté qu'il prenait le contre-pieds de la plupart
des usages
<br>recommandés, entre autres, par les contributeurs de ce forum,
comme par
<br>exemple utiliser des "return" partout dans la fonction plutôt
que
<br>d'utiliser une variable et un unique point de sortie, ou des écritures
<br>très condensées, à la limite de la lisibilité).
<br>Je sais très bien qu'il y a une différence entre
<br>l'enseignement/recherche et la pratique professionnelle, aussi je
Je suis en DEA (recherche) et j'avoue que je programme comme mes confreres
<br>de DESS (professionnel) a savoir, un #include "xxx.h" dans mes .h lorsqu'il
y en
<br>a besoin.
<br>En effet, a partir du moment ou tu utilise correctement les #ifndef,
#define, #endif
<br>pas de problemes.
<br>En quelle annee es-tu ? C'est quoi la section d'enseignement de ton
prof?
<blockquote TYPE=CITE>>>Enfin: quelle est votre pratique personnelle ?
<br>>
<br>> - Protection systématique contre les inclusions
<br>> - Inclure partout où c'est nécessaire
<br>>
<p>En clair, les gardes (#ifndef, #define, #endif) comme indiqué
par la faq.
<br>Et inclusion dans les .h si le service proposé par le .h le
demande,
Pareil...
<br>J'inclus dans le .c pour tous les appels de foncitons...
<br>Dans le .h des que j'ai besoin d'un type ou d'une structure definis
<br>par un autre module...
<pre>--
Fanny
Hypnotiseur de castor
</pre>
</html>
--------------2E64D4310CDEF28152FE9B16--
les autres personnes qui vont vouloir compiler ton logiciel n'auront pas
forcément ton stdio.h et cela m'étonnerait qu'ils trustent ton stdio.h.
donc, je préconniserai plutôt :
#ifdef ENVIRONNEMENT_DE_MERDE
#define truc truc
#endif
#include
Ah ben la portabilitié passe par pas mal de trucs laids.
--
DINH V. Hoa,
"dans la famille, on est tous intelligents" -- sunZ
En fait, ce que je cherche à dire, c'est qu'il n'y en a pas !
Je fais cela pour mes propres programmes, par exemple quand je récupère un
source écrit ailleurs (je suis essentiellement un utilisateur. Une race
bizarre, qui n'a pas les mêmes besoins que les autres).
Par expérience, tu as (beaucoup) plus de succès en distribuant un .diff de
conio.h "pour que cela marche avec tel compilo". Ce qui revient à modifier
le fichier.
Mmmm. Pas plus tard qu'hier, pan, planté. Le source que je voulais compiler
avait une variable truc.
D'où nécessité d'une ligne supplémentaire,
#undef truc
Trop à mon goût.
Antoine