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 ?
Vos réponses Page 1 / 4
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Jean-Marc
Le #601760
"gregg" news:407038f0$0$31085$
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
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 ?


Hello,

pour la part je n'y vois rien à redire. C'est une pratique courante et sans
aucun inconvénients tant que:
- On utilise bien les garde fous (comme tu le signales)
- On ne fait pas de déclarations de variables dans les header

Par exemple, on peut dans un .h définir un type,
et dans un autre placer le prototype d'une fonction dont les arguments sont
du type défini dans l'autre .h

Jean-Marc

Éric Lévénez
Le #601759
Le 4/04/04 18:34, dans
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".


Dans un projet on a toujours plusieurs de .h. Chaque .h a des gardes fous
pour les inclusions multiples. Certains .h peuvent dépendre d'autres .h.
Dans ce cas on doit faire les includes dans le .c dans un ordre bien défini.
Pour éviter cela il est courant que chaque .h appelle les .h dont il a
besoin (et dans le bon ordre) pour marcher sans erreur. Ainsi on n'a plus le
problème de placer les includes dans un ordre défini, il suffit de les
mettre quand on en a besoin.

L'include d'includes est une bonne chose quand il est bien utilisé.

--
Éric Lévénez -- Unix is not only an OS, it's a way of life.

Emmanuel Delahaye
Le #601758
In 'fr.comp.lang.c', gregg
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

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

En une phrase : "Mauvais prof, changer de prof".

Enfin: quelle est votre pratique personnelle ?


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

--
-ed- [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=cpp
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/

Emmanuel Delahaye
Le #601757
In 'fr.comp.lang.c', Emmanuel Delahaye
- Protection systématique contre les inclusions
... multiples.


--
-ed- [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=cpp
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/

gregg
Le #601756
Emmanuel Delahaye wrote:
In 'fr.comp.lang.c', gregg

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


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


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 ?


Alexandre BACQUART
Le #601755
gregg wrote:
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".


Toutes les librairies un tant soi peu évoluées utilisent cette
technique, les garde-fou étant là justement pour éviter les problèmes
que ça peut engendrer. Au contraire, il faut apprendre à l'utiliser car
c'est utile, voire indispensable sur de gros projet.

Ton prof est certainement un névrosé de la récursivité dont le coté
tranchant à fait souffrir beaucoup de gens :)

(Il ne s'agit pas de
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.


Aujourd'hui, aucun. Le tout étant de le faire sciemment pour éviter les
confusions.

--
Tek
void main() {printf("Free The World !");} /* copyleft */

Emmanuel Delahaye
Le #601754
In 'fr.comp.lang.c', gregg
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 ?


Absolument.

--
-ed- [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=cpp
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/

Stephane Legras-Decussy
Le #601571
"Alexandre BACQUART" 407079bb$0$12802
void main() {printf("Free The World !");} /* copyleft */


int main() ....

DINH Viêt Hoà
Le #601570

Toutes les librairies un tant soi peu évoluées utilisent cette
technique, les garde-fou étant là justement pour éviter les problèmes
que ça peut engendrer. Au contraire, il faut apprendre à l'utiliser car
c'est utile, voire indispensable sur de gros projet.


C'est clair que dans une bibliothèque bien segmentée au niveau du code,
je vois mal la bibliothèque en question contraindre l'utilisateur à
faire un milliers d'include afin de faire marcher une fonctionnalité.

#include #include #include
int main(void)
{
coincoin * a;
pingouin * b;

arsunik(&a, &b);

exit(EXIT_SUCCESS);
}

alors que l'utilisateur préférerait :

#include
int main(void)
{
coincoin * a;
pingouin * b;

arsunik(&a, &b);

exit(EXIT_SUCCESS);
}

ça lui fait déjà assez de code à écrire.

--
DINH V. Hoa,

"on peut rouler dans une épave avec un caisson de basse" -- sunZ

DINH Viêt Hoà
Le #601569

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

Il s'agit plus d'un choix politique que d'interdire
d'inclure un .h dans un .h

--
DINH V. Hoa,

"on peut rouler dans une épave avec un caisson de basse" -- sunZ

Publicité
Poster une réponse
Anonyme