bibliotheque et fichiers d'en-tete pour l'utilisateur
50 réponses
Vincent Lefevre
Bonjour et bonne année,
J'aimerais avoir votre avis sur le point suivant (je n'ai pas vu
d'indications dans les FAQ). Dans la bibliothèque qu'on développe
(MPFR), il y a des fonctions qui ne sont liées aucunement à la
bibliothèque standard et d'autres qui sont liées à certaines choses
de <stdio.h> (par exemple utilisent FILE en argument, parce que ce
sont des fonctions d'entrées/sorties). Y a-t-il une ou des solutions
recommandées concernant les fichiers d'en-tête fournis par la
bibliothèque (pour l'utilisateur de la bibliothèque), avec une
volonté de portabilité?
1) La solution actuelle est celle de GMP, qui est d'essayer de
détecter automatiquement si <stdio.h> a été #inclus avant gmp.h,
auquel cas gmp.h déclare les fonctions d'entrées/sorties. Mais cela
pose notamment deux gros problèmes: comme il n'y a pas de standard
pour cette détection, cela risque d'échouer sur les plateformes non
testées (et cela arrive en pratique) ou à cause de changements futurs
sur les plateformes existantes (cf tous les problèmes qu'a posés le
changement lié au errno dans la glibc); d'autre part, cette méthode
empiète sur le domaine de l'utilisateur. Par exemple, le programme
suivant ne compile pas:
#define H_STDIO 1
#include <gmp.h>
int main(void)
{
return 0;
}
(à noter que H_STDIO ne fait pas partie des macros réservées par GMP,
qui commencent par "GMP_", par convention).
2) Il y a la solution d'inclure systématiquement <stdio.h> dans le
fichier d'en-tête qu'on fournit (mpfr.h), éventuellement sauf si telle
macro, e.g. MPFR_NO_STDIO, est définie auparavant par l'utilisateur
(évidemment, tout cela devant être parfaitement documenté...).
3) Il y a la solution de fournir plusieurs fichiers d'en-tête, e.g.
mpfr.h et mpfrIO.h, où <stdio.h> n'est inclus que dans "mpfrIO.h".
C'est une sorte de (2) modulaire.
Dans les quelques bibliothèques que j'ai regardées (à part GMP), c'est
soit (2) sans la possibilité d'empêcher l'inclusion, soit (3).
Pour info, ma préférence personnelle va pour (3), pour son aspect
modulaire en particulier.
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
2) Il y a la solution d'inclure systématiquement <stdio.h> dans le fichier d'en-tête qu'on fournit (mpfr.h), éventuellement sauf si telle macro, e.g. MPFR_NO_STDIO, est définie auparavant par l'utilisateur (évidemment, tout cela devant être parfaitement documenté...).
J'utilise cette méthode et je me base sur le fait que cet en-tête (stdio.h par exemple) dispose de méthode pour ne pas s'inclure deux fois.
-- DINH V. Hoa,
etPan! - newsreader, mail user agent -- http://libetpan.sf.net/etpan
2) Il y a la solution d'inclure systématiquement <stdio.h> dans le
fichier d'en-tête qu'on fournit (mpfr.h), éventuellement sauf si telle
macro, e.g. MPFR_NO_STDIO, est définie auparavant par l'utilisateur
(évidemment, tout cela devant être parfaitement documenté...).
J'utilise cette méthode et je me base sur le fait que cet en-tête
(stdio.h par exemple) dispose de méthode pour ne pas s'inclure deux
fois.
--
DINH V. Hoa,
etPan! - newsreader, mail user agent -- http://libetpan.sf.net/etpan
2) Il y a la solution d'inclure systématiquement <stdio.h> dans le fichier d'en-tête qu'on fournit (mpfr.h), éventuellement sauf si telle macro, e.g. MPFR_NO_STDIO, est définie auparavant par l'utilisateur (évidemment, tout cela devant être parfaitement documenté...).
J'utilise cette méthode et je me base sur le fait que cet en-tête (stdio.h par exemple) dispose de méthode pour ne pas s'inclure deux fois.
-- DINH V. Hoa,
etPan! - newsreader, mail user agent -- http://libetpan.sf.net/etpan
Jean-Marc Bourguet
Vincent Lefevre <vincent+ writes:
Dans les quelques bibliothèques que j'ai regardées (à part GMP), c'est soit (2) sans la possibilité d'empêcher l'inclusion, soit (3).
Le 1 est une horreur. Je pratique 2 ou 3 suivant les circonstances.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Vincent Lefevre <vincent+news@vinc17.org> writes:
Dans les quelques bibliothèques que j'ai regardées (à part GMP), c'est
soit (2) sans la possibilité d'empêcher l'inclusion, soit (3).
Le 1 est une horreur. Je pratique 2 ou 3 suivant les circonstances.
A+
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Dans les quelques bibliothèques que j'ai regardées (à part GMP), c'est soit (2) sans la possibilité d'empêcher l'inclusion, soit (3).
Le 1 est une horreur. Je pratique 2 ou 3 suivant les circonstances.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Emmanuel Delahaye
In 'fr.comp.lang.c', Vincent Lefevre <vincent+ wrote:
J'aimerais avoir votre avis sur le point suivant (je n'ai pas vu d'indications dans les FAQ). Dans la bibliothèque qu'on développe (MPFR), il y a des fonctions qui ne sont liées aucunement à la bibliothèque standard et d'autres qui sont liées à certaines choses de <stdio.h> (par exemple utilisent FILE en argument, parce que ce sont des fonctions d'entrées/sorties). Y a-t-il une ou des solutions recommandées concernant les fichiers d'en-tête fournis par la bibliothèque (pour l'utilisateur de la bibliothèque), avec une volonté de portabilité?
Il me semble que ça a déjà été débattu et que le principe d'inclure le header selon les besoins est la façon la plus simple et la plus évidente de procéder. Si par malheur une implémentation avait des headers non protégés, il ne couterait pas bien cher d'ajouter ces protections. En tout cas, je fais comme ça depuis 10 ans et je n'ai aucun problèmes...
2) Il y a la solution d'inclure systématiquement <stdio.h> dans le fichier d'en-tête qu'on fournit (mpfr.h), éventuellement sauf si telle macro, e.g. MPFR_NO_STDIO, est définie auparavant par l'utilisateur (évidemment, tout cela devant être parfaitement documenté...).
Si le header en question en a besoin, oui, sinon, c'est inutile.
-- -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/
In 'fr.comp.lang.c', Vincent Lefevre <vincent+news@vinc17.org> wrote:
J'aimerais avoir votre avis sur le point suivant (je n'ai pas vu
d'indications dans les FAQ). Dans la bibliothèque qu'on développe
(MPFR), il y a des fonctions qui ne sont liées aucunement à la
bibliothèque standard et d'autres qui sont liées à certaines choses
de <stdio.h> (par exemple utilisent FILE en argument, parce que ce
sont des fonctions d'entrées/sorties). Y a-t-il une ou des solutions
recommandées concernant les fichiers d'en-tête fournis par la
bibliothèque (pour l'utilisateur de la bibliothèque), avec une
volonté de portabilité?
Il me semble que ça a déjà été débattu et que le principe d'inclure le header
selon les besoins est la façon la plus simple et la plus évidente de
procéder. Si par malheur une implémentation avait des headers non protégés,
il ne couterait pas bien cher d'ajouter ces protections. En tout cas, je fais
comme ça depuis 10 ans et je n'ai aucun problèmes...
2) Il y a la solution d'inclure systématiquement <stdio.h> dans le
fichier d'en-tête qu'on fournit (mpfr.h), éventuellement sauf si telle
macro, e.g. MPFR_NO_STDIO, est définie auparavant par l'utilisateur
(évidemment, tout cela devant être parfaitement documenté...).
Si le header en question en a besoin, oui, sinon, c'est inutile.
--
-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', Vincent Lefevre <vincent+ wrote:
J'aimerais avoir votre avis sur le point suivant (je n'ai pas vu d'indications dans les FAQ). Dans la bibliothèque qu'on développe (MPFR), il y a des fonctions qui ne sont liées aucunement à la bibliothèque standard et d'autres qui sont liées à certaines choses de <stdio.h> (par exemple utilisent FILE en argument, parce que ce sont des fonctions d'entrées/sorties). Y a-t-il une ou des solutions recommandées concernant les fichiers d'en-tête fournis par la bibliothèque (pour l'utilisateur de la bibliothèque), avec une volonté de portabilité?
Il me semble que ça a déjà été débattu et que le principe d'inclure le header selon les besoins est la façon la plus simple et la plus évidente de procéder. Si par malheur une implémentation avait des headers non protégés, il ne couterait pas bien cher d'ajouter ces protections. En tout cas, je fais comme ça depuis 10 ans et je n'ai aucun problèmes...
2) Il y a la solution d'inclure systématiquement <stdio.h> dans le fichier d'en-tête qu'on fournit (mpfr.h), éventuellement sauf si telle macro, e.g. MPFR_NO_STDIO, est définie auparavant par l'utilisateur (évidemment, tout cela devant être parfaitement documenté...).
Si le header en question en a besoin, oui, sinon, c'est inutile.
-- -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/
Gabriel Dos Reis
Vincent Lefevre <vincent+ writes:
| 1) La solution actuelle est celle de GMP, qui est d'essayer de | détecter automatiquement si <stdio.h> a été #inclus avant gmp.h,
C'est une bonne pratique pour créer des situations cauchemardesques pendant la maintenance ou l'intégration dans des systèmes plus larges. Dépendre de l'ordre d'inclusion est mauvais pour la santé.
[...]
| 2) Il y a la solution d'inclure systématiquement <stdio.h> dans le | fichier d'en-tête qu'on fournit (mpfr.h), éventuellement sauf si telle | macro, e.g. MPFR_NO_STDIO, est définie auparavant par l'utilisateur | (évidemment, tout cela devant être parfaitement documenté...).
Je n'aime pas particulièrement les inclusions d'entêtes controllées par les macros. En général, cela veut dire que des tests avec des outils comme les autotools peuvent données des réponses qui en fait ne sont pas bonnes. Aussi elle ne marche pas bien avec l'idiome
<compiler> -DMACRO=VALUE file.c ....
Je conseillerais d'inclure systématiquement -- et puisque nous sommes en C, de le documenter.
| 3) Il y a la solution de fournir plusieurs fichiers d'en-tête, e.g. | mpfr.h et mpfrIO.h, où <stdio.h> n'est inclus que dans "mpfrIO.h". | C'est une sorte de (2) modulaire.
À la longue, ceci pose aussi des problèmes de maintenance.
-- Gaby
Vincent Lefevre <vincent+news@vinc17.org> writes:
| 1) La solution actuelle est celle de GMP, qui est d'essayer de
| détecter automatiquement si <stdio.h> a été #inclus avant gmp.h,
C'est une bonne pratique pour créer des situations cauchemardesques
pendant la maintenance ou l'intégration dans des systèmes plus larges.
Dépendre de l'ordre d'inclusion est mauvais pour la santé.
[...]
| 2) Il y a la solution d'inclure systématiquement <stdio.h> dans le
| fichier d'en-tête qu'on fournit (mpfr.h), éventuellement sauf si telle
| macro, e.g. MPFR_NO_STDIO, est définie auparavant par l'utilisateur
| (évidemment, tout cela devant être parfaitement documenté...).
Je n'aime pas particulièrement les inclusions d'entêtes controllées
par les macros. En général, cela veut dire que des tests avec des
outils comme les autotools peuvent données des réponses qui en fait ne
sont pas bonnes. Aussi elle ne marche pas bien avec l'idiome
<compiler> -DMACRO=VALUE file.c ....
Je conseillerais d'inclure systématiquement -- et puisque nous sommes
en C, de le documenter.
| 3) Il y a la solution de fournir plusieurs fichiers d'en-tête, e.g.
| mpfr.h et mpfrIO.h, où <stdio.h> n'est inclus que dans "mpfrIO.h".
| C'est une sorte de (2) modulaire.
À la longue, ceci pose aussi des problèmes de maintenance.
| 1) La solution actuelle est celle de GMP, qui est d'essayer de | détecter automatiquement si <stdio.h> a été #inclus avant gmp.h,
C'est une bonne pratique pour créer des situations cauchemardesques pendant la maintenance ou l'intégration dans des systèmes plus larges. Dépendre de l'ordre d'inclusion est mauvais pour la santé.
[...]
| 2) Il y a la solution d'inclure systématiquement <stdio.h> dans le | fichier d'en-tête qu'on fournit (mpfr.h), éventuellement sauf si telle | macro, e.g. MPFR_NO_STDIO, est définie auparavant par l'utilisateur | (évidemment, tout cela devant être parfaitement documenté...).
Je n'aime pas particulièrement les inclusions d'entêtes controllées par les macros. En général, cela veut dire que des tests avec des outils comme les autotools peuvent données des réponses qui en fait ne sont pas bonnes. Aussi elle ne marche pas bien avec l'idiome
<compiler> -DMACRO=VALUE file.c ....
Je conseillerais d'inclure systématiquement -- et puisque nous sommes en C, de le documenter.
| 3) Il y a la solution de fournir plusieurs fichiers d'en-tête, e.g. | mpfr.h et mpfrIO.h, où <stdio.h> n'est inclus que dans "mpfrIO.h". | C'est une sorte de (2) modulaire.
À la longue, ceci pose aussi des problèmes de maintenance.
-- Gaby
Laurent Deniau
Vincent Lefevre wrote:
Bonjour et bonne année,
Pareillement.
J'aimerais avoir votre avis sur le point suivant (je n'ai pas vu
[...]
2) Il y a la solution d'inclure systématiquement <stdio.h> dans le fichier d'en-tête qu'on fournit (mpfr.h), éventuellement sauf si telle macro, e.g. MPFR_NO_STDIO, est définie auparavant par l'utilisateur (évidemment, tout cela devant être parfaitement documenté...).
C'est la solution que j'utilise et que je consisdere comme etant la moins mauvaise (et de loin) pour cause de flexibilite. Je fourni un config.h dans lequel toutes les macros sont definies et commentees.
Cela permet si besoin est de faire du code conditionnel, de demander le path d'un include a l'installateur, de configurer des niveaux de check/debug, etc... de maniere tres simple a quiconque connait un peu le C. Les autotools sont trop compliques et pas assez repandus pour un utilisateur lambda comme moi.
Si en plus on veut exporter certains settings du config.h dans les Makefiles, un petit script perl (ou awk) permet de le faire aisement.
3) Il y a la solution de fournir plusieurs fichiers d'en-tête, e.g. mpfr.h et mpfrIO.h, où <stdio.h> n'est inclus que dans "mpfrIO.h". C'est une sorte de (2) modulaire.
Pour info, ma préférence personnelle va pour (3), pour son aspect modulaire en particulier.
3) necessite de modifier les sources si on change d'avis et donc de connaitre les implications de ces changements.
2) est au moins aussi modulaire/flexible et pose moins de probleme de maintenance a terme que 3) si on centralise les configurations globales (e.g. config.h), les configurations locales etant a proscrire a mon avis.
a+, ld.
Vincent Lefevre wrote:
Bonjour et bonne année,
Pareillement.
J'aimerais avoir votre avis sur le point suivant (je n'ai pas vu
[...]
2) Il y a la solution d'inclure systématiquement <stdio.h> dans le
fichier d'en-tête qu'on fournit (mpfr.h), éventuellement sauf si telle
macro, e.g. MPFR_NO_STDIO, est définie auparavant par l'utilisateur
(évidemment, tout cela devant être parfaitement documenté...).
C'est la solution que j'utilise et que je consisdere comme etant la
moins mauvaise (et de loin) pour cause de flexibilite. Je fourni un
config.h dans lequel toutes les macros sont definies et commentees.
Cela permet si besoin est de faire du code conditionnel, de demander le
path d'un include a l'installateur, de configurer des niveaux de
check/debug, etc... de maniere tres simple a quiconque connait un peu le
C. Les autotools sont trop compliques et pas assez repandus pour un
utilisateur lambda comme moi.
Si en plus on veut exporter certains settings du config.h dans les
Makefiles, un petit script perl (ou awk) permet de le faire aisement.
3) Il y a la solution de fournir plusieurs fichiers d'en-tête, e.g.
mpfr.h et mpfrIO.h, où <stdio.h> n'est inclus que dans "mpfrIO.h".
C'est une sorte de (2) modulaire.
Pour info, ma préférence personnelle va pour (3), pour son aspect
modulaire en particulier.
3) necessite de modifier les sources si on change d'avis et donc de
connaitre les implications de ces changements.
2) est au moins aussi modulaire/flexible et pose moins de probleme de
maintenance a terme que 3) si on centralise les configurations globales
(e.g. config.h), les configurations locales etant a proscrire a mon avis.
J'aimerais avoir votre avis sur le point suivant (je n'ai pas vu
[...]
2) Il y a la solution d'inclure systématiquement <stdio.h> dans le fichier d'en-tête qu'on fournit (mpfr.h), éventuellement sauf si telle macro, e.g. MPFR_NO_STDIO, est définie auparavant par l'utilisateur (évidemment, tout cela devant être parfaitement documenté...).
C'est la solution que j'utilise et que je consisdere comme etant la moins mauvaise (et de loin) pour cause de flexibilite. Je fourni un config.h dans lequel toutes les macros sont definies et commentees.
Cela permet si besoin est de faire du code conditionnel, de demander le path d'un include a l'installateur, de configurer des niveaux de check/debug, etc... de maniere tres simple a quiconque connait un peu le C. Les autotools sont trop compliques et pas assez repandus pour un utilisateur lambda comme moi.
Si en plus on veut exporter certains settings du config.h dans les Makefiles, un petit script perl (ou awk) permet de le faire aisement.
3) Il y a la solution de fournir plusieurs fichiers d'en-tête, e.g. mpfr.h et mpfrIO.h, où <stdio.h> n'est inclus que dans "mpfrIO.h". C'est une sorte de (2) modulaire.
Pour info, ma préférence personnelle va pour (3), pour son aspect modulaire en particulier.
3) necessite de modifier les sources si on change d'avis et donc de connaitre les implications de ces changements.
2) est au moins aussi modulaire/flexible et pose moins de probleme de maintenance a terme que 3) si on centralise les configurations globales (e.g. config.h), les configurations locales etant a proscrire a mon avis.
a+, ld.
Bertrand Mollinier Toublet
Vincent Lefevre wrote:
2) Il y a la solution d'inclure systématiquement <stdio.h> dans le fichier d'en-tête qu'on fournit (mpfr.h), éventuellement sauf si telle macro, e.g. MPFR_NO_STDIO, est définie auparavant par l'utilisateur (évidemment, tout cela devant être parfaitement documenté...).
3) Il y a la solution de fournir plusieurs fichiers d'en-tête, e.g. mpfr.h et mpfrIO.h, où <stdio.h> n'est inclus que dans "mpfrIO.h". C'est une sorte de (2) modulaire.
Ca doit etre le manque d'experience, mais je n'ai jamais ressenti le besoin de *ne pas* include un fichier d'entete. C'est pour te proteger contre un entete mal foutu qui ne gere pas les inclusions multiples ?
-- Bertrand Mollinier Toublet - Le top-posting. - Quelle est la pratique la plus chiante sur Usenet ?
Vincent Lefevre wrote:
2) Il y a la solution d'inclure systématiquement <stdio.h> dans le
fichier d'en-tête qu'on fournit (mpfr.h), éventuellement sauf si telle
macro, e.g. MPFR_NO_STDIO, est définie auparavant par l'utilisateur
(évidemment, tout cela devant être parfaitement documenté...).
3) Il y a la solution de fournir plusieurs fichiers d'en-tête, e.g.
mpfr.h et mpfrIO.h, où <stdio.h> n'est inclus que dans "mpfrIO.h".
C'est une sorte de (2) modulaire.
Ca doit etre le manque d'experience, mais je n'ai jamais ressenti le
besoin de *ne pas* include un fichier d'entete. C'est pour te proteger
contre un entete mal foutu qui ne gere pas les inclusions multiples ?
--
Bertrand Mollinier Toublet
- Le top-posting.
- Quelle est la pratique la plus chiante sur Usenet ?
2) Il y a la solution d'inclure systématiquement <stdio.h> dans le fichier d'en-tête qu'on fournit (mpfr.h), éventuellement sauf si telle macro, e.g. MPFR_NO_STDIO, est définie auparavant par l'utilisateur (évidemment, tout cela devant être parfaitement documenté...).
3) Il y a la solution de fournir plusieurs fichiers d'en-tête, e.g. mpfr.h et mpfrIO.h, où <stdio.h> n'est inclus que dans "mpfrIO.h". C'est une sorte de (2) modulaire.
Ca doit etre le manque d'experience, mais je n'ai jamais ressenti le besoin de *ne pas* include un fichier d'entete. C'est pour te proteger contre un entete mal foutu qui ne gere pas les inclusions multiples ?
-- Bertrand Mollinier Toublet - Le top-posting. - Quelle est la pratique la plus chiante sur Usenet ?
DINH Viêt Hoà
C'est pour te proteger contre un entete mal foutu qui ne gere pas les inclusions multiples ?
précisemment.
-- DINH V. Hoa,
etPan! - newsreader, mail user agent -- http://libetpan.sf.net/etpan
C'est pour te proteger
contre un entete mal foutu qui ne gere pas les inclusions multiples ?
précisemment.
--
DINH V. Hoa,
etPan! - newsreader, mail user agent -- http://libetpan.sf.net/etpan
In 'fr.comp.lang.c', DINH =?iso-8859-15?Q?Viêt_Hoà?= wrote:
C'est pour te proteger contre un entete mal foutu qui ne gere pas les inclusions multiples ?
précisemment.
Dans ce cas, il suffit de le modifier et l'affaire est reglée.
-- -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/
DINH Viêt Hoà
In 'fr.comp.lang.c', DINH =?iso-8859-15?Q?Viêt_Hoà?= wrote:
C'est pour te proteger contre un entete mal foutu qui ne gere pas les inclusions multiples ?
précisemment.
Dans ce cas, il suffit de le modifier et l'affaire est reglée.
Heu ... ben dans un projet distribué, ce n'est pas si évident que ça de modifier l'en-tête mal foutu vu que ce ne sera pas forcément le même partout mais il est clair que c'est aux gens à qui appartiennent les en-têtes de corriger ce problème.
-- DINH V. Hoa,
etPan! - newsreader, mail user agent -- http://libetpan.sf.net/etpan
In 'fr.comp.lang.c', DINH =?iso-8859-15?Q?Viêt_Hoà?=
<dinh.viet.hoa@free.fr> wrote:
C'est pour te proteger
contre un entete mal foutu qui ne gere pas les inclusions multiples ?
précisemment.
Dans ce cas, il suffit de le modifier et l'affaire est reglée.
Heu ... ben dans un projet distribué, ce n'est pas si évident que ça de
modifier l'en-tête mal foutu vu que ce ne sera pas forcément le même
partout mais il est clair que c'est aux gens à qui appartiennent les
en-têtes de corriger ce problème.
--
DINH V. Hoa,
etPan! - newsreader, mail user agent -- http://libetpan.sf.net/etpan
In 'fr.comp.lang.c', DINH =?iso-8859-15?Q?Viêt_Hoà?= wrote:
C'est pour te proteger contre un entete mal foutu qui ne gere pas les inclusions multiples ?
précisemment.
Dans ce cas, il suffit de le modifier et l'affaire est reglée.
Heu ... ben dans un projet distribué, ce n'est pas si évident que ça de modifier l'en-tête mal foutu vu que ce ne sera pas forcément le même partout mais il est clair que c'est aux gens à qui appartiennent les en-têtes de corriger ce problème.
-- DINH V. Hoa,
etPan! - newsreader, mail user agent -- http://libetpan.sf.net/etpan
Gabriel Dos Reis
Bertrand Mollinier Toublet writes:
| Ca doit etre le manque d'experience, mais je n'ai jamais ressenti le | besoin de *ne pas* include un fichier d'entete.
Amen.
| C'est pour te proteger | contre un entete mal foutu qui ne gere pas les inclusions multiples ?
Il y a pas de programmeurs C qui pensent que si leurs voisins agissent des porcs alors ils peuvent faire comme lui.
