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

"gregg" <greggory@netJUSTSAYNOcourrier.com> a écrit dans le message de
news:407038f0$0$31085$636a15ce@news.free.fr...

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 ?

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

Le 4/04/04 18:34, dans <407038f0$0$31085$636a15ce@news.free.fr>, « gregg »
<greggory@netJUSTSAYNOcourrier.com> a écrit :

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 -- <http://www.levenez.com>
Unix is not only an OS, it's a way of life.

In 'fr.comp.lang.c', gregg <greggory@netJUSTSAYNOcourrier.com> wrote:

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)

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- emdelYOURBRA@noos.fr [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/

In 'fr.comp.lang.c', Emmanuel Delahaye <emdelYOURBRA@noos.fr> wrote:

- Protection systématique contre les inclusions
... multiples.

--
-ed- emdelYOURBRA@noos.fr [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 wrote:

In 'fr.comp.lang.c', gregg <greggory@netJUSTSAYNOcourrier.com> wrote:

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)

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 ?

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

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

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

In 'fr.comp.lang.c', gregg <greggory@netJUSTSAYNOcourrier.com> wrote:

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- emdelYOURBRA@noos.fr [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/

"Alexandre BACQUART" <tek512@hotmail.com> a écrit dans le message de news:
407079bb$0$12802

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

int main() ....

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 <coincoin.h> /* types de données 1 */
#include <pingouin.h> /* types de données 2 */
#include <arsunik.h> /* fonctions */

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

arsunik(&a, &b);

exit(EXIT_SUCCESS);
}

alors que l'utilisateur préférerait :

#include <arsunik.h>

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

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)

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