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 ?
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
En etPan.407331b7.763dce2d.4ddd@homer, 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.
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.
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...
<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <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 <br>m'interroge dès qu'une remarque me paraî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é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, <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>-- Fanny Hypnotiseur de castor </pre> </html>
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...
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<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
<br>m'interroge dès qu'une remarque me paraî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é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,
<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>--
Fanny
Hypnotiseur de castor
</pre>
</html>
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...
<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <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 <br>m'interroge dès qu'une remarque me paraî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é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, <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>-- Fanny Hypnotiseur de castor </pre> </html>
--------------2E64D4310CDEF28152FE9B16--
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.
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
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.
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
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.
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
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.
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
En etPan.4073c353.7606e3f8.4ddd@homer, 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.
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.
