OVH Cloud OVH Cloud

pas de #include dans un fichier d'en-tête ?

34 réponses
Avatar
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 ?

4 réponses

1 2 3 4
Avatar
Antoine Leca
En , DINH Viêt Hoà va escriure:

Bizarre ; les seules fois où j'ai modifié les entêtes d'une
implémentation (en dehors bien sûr des fois où c'est moi qui les
écrit), c'était pour corriger les erreurs *dedans*... (en
particulier avec les far, _cdecl, et autres joyeusetés non
normalisées).


vaut mieux pas workarounder les problèmes plutôt que modifier les
en-têtes afin d'avoir à refaire la chose sur toutes les machines sur
lesquelles tu vas compiler le code ?


Euh ? Pas sûr que je me sois bien expliqué, là.

J'ai un entête genre <conio.h> d'un compilo commercial, qui ne passe pas en
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 <conio.h> n'est pas
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 <stdio.h> original,
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 <stdio.h>


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


Avatar
fanny Chevalier
--------------2E64D4310CDEF28152FE9B16
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Aie. J'ai peur que le débat sur les profs ne soit rallumé...


Euh, c'est pas vraiment là où je veux en venir... :(
( j'ai constaté qu'il prenait le contre-pieds de la plupart des usages
recommandés, entre autres, par les contributeurs de ce forum, comme par
exemple utiliser des "return" partout dans la fonction plutôt que
d'utiliser une variable et un unique point de sortie, ou des écritures
très condensées, à la limite de la lisibilité).
Je sais très bien qu'il y a une différence entre
l'enseignement/recherche et la pratique professionnelle, aussi je
m'interroge dès qu'une remarque me paraît "bizarre"...


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?

Enfin: quelle est votre pratique personnelle ?


- Protection systématique contre les inclusions
- Inclure partout où c'est nécessaire



En clair, les gardes (#ifndef, #define, #endif) comme indiqué par la faq.
Et inclusion dans les .h si le service proposé par le .h le demande,
sinon dans le.c ?


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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>

<blockquote TYPE=CITE>> Aie. J'ai peur que le d&eacute;bat sur les profs
ne soit rallum&eacute;...
<p>Euh, c'est pas vraiment l&agrave; o&ugrave; je veux en venir... :(
<br>( j'ai constat&eacute; qu'il prenait le contre-pieds de la plupart
des usages
<br>recommand&eacute;s, entre autres, par les contributeurs de ce forum,
comme par
<br>exemple utiliser des "return" partout dans la fonction plut&ocirc;t
que
<br>d'utiliser une variable et un unique point de sortie, ou des &eacute;critures
<br>tr&egrave;s condens&eacute;es, &agrave; la limite de la lisibilit&eacute;).
<br>Je sais tr&egrave;s bien qu'il y a une diff&eacute;rence entre
<br>l'enseignement/recherche et la pratique professionnelle, aussi je
<br>m'interroge d&egrave;s qu'une remarque me para&icirc;t "bizarre"...</blockquote>
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&eacute;matique contre les inclusions
<br>> - Inclure partout o&ugrave; c'est n&eacute;cessaire
<br>>
<p>En clair, les gardes (#ifndef, #define, #endif) comme indiqu&eacute;
par la faq.
<br>Et inclusion dans les .h si le service propos&eacute; par le .h le
demande,
<br>sinon dans le.c ?</blockquote>
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>--&nbsp;
Fanny&nbsp;
Hypnotiseur de castor
</pre>
</html>

--------------2E64D4310CDEF28152FE9B16--



Avatar
DINH Viêt Hoà

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 <stdio.h> original,
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 <stdio.h>


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 <stdio.h>

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.


Ah ben la portabilitié passe par pas mal de trucs laids.

--
DINH V. Hoa,

"dans la famille, on est tous intelligents" -- sunZ

Avatar
Antoine Leca
En , DINH Viêt Hoà va escriure:

Bien sûr, une solution, c'est comme tu le dis, d'écrire une version
à moi de stdio.h [...]

Je trouve plus simple de prendre mon éditeur de texte et de modifier
la version online de <stdio.h>


les autres personnes [couic]


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

pas forcément ton stdio.h et cela m'étonnerait qu'ils trustent ton
stdio.h.


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.


donc, je préconniserai plutôt :
#ifdef ENVIRONNEMENT_DE_MERDE
#define truc truc
#endif

#include <stdio.h>


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


Ah ben la portabilitié passe par pas mal de trucs laids.


Trop à mon goût.


Antoine


1 2 3 4