Voila je veut utiliser regcomp et regexec pour faire des comparaisons. J'ai
donc voulu faire un petit test pour commencer mais cella ne fonctionne pas.
Lors de l'execution, il me dit que les deux chaines ne sont pas les mêmes,
quelqu'un à une idée ?
"Anthony" a écrit dans le message de news:412b4c28$0$22041$
Attention, cette question n'a pas sa place ici logiquement. Ces fonctions sont conformes à POSIX et non à C89 ou C99.
(-: Je me pose une question sommes-nous sur fr.comp.lang.c.norme.cx9 :-)
Je n'ai pas relue la charte récemment, mais je n'ai pas souvenir d'une restriction si contraignante.
Pareil, cependant chaque fois qu'une question sur une extension POSIX est posée ici elle recoit ce type de message (pour les souvenirs que j'en ai). Rien n'a vraiment changé. Seulement, les membres les plus éminents du
service "action" du hezbollah sont en vacances. Ou en pélerinage. Ou en camp de rééducation ... -- Pierre
Anthony <fleury_anthony@_hotmail_.com> a écrit:
K. Ahausse wrote:
"Anthony" <fleury_anthony@_hotmail_.com> a écrit dans le message de
news:412b4c28$0$22041$626a14ce@news.free.fr...
Attention, cette question n'a pas sa place ici logiquement. Ces fonctions
sont conformes à POSIX et non à C89 ou C99.
(-: Je me pose une question sommes-nous sur fr.comp.lang.c.norme.cx9 :-)
Je n'ai pas relue la charte récemment, mais je n'ai pas souvenir d'une
restriction si contraignante.
Pareil, cependant chaque fois qu'une question sur une extension POSIX est
posée ici elle recoit ce type de message (pour les souvenirs que j'en ai).
Rien n'a vraiment changé. Seulement, les membres les plus éminents du
service "action" du hezbollah sont en vacances. Ou en pélerinage. Ou
en camp de rééducation ...
--
Pierre
"Anthony" a écrit dans le message de news:412b4c28$0$22041$
Attention, cette question n'a pas sa place ici logiquement. Ces fonctions sont conformes à POSIX et non à C89 ou C99.
(-: Je me pose une question sommes-nous sur fr.comp.lang.c.norme.cx9 :-)
Je n'ai pas relue la charte récemment, mais je n'ai pas souvenir d'une restriction si contraignante.
Pareil, cependant chaque fois qu'une question sur une extension POSIX est posée ici elle recoit ce type de message (pour les souvenirs que j'en ai). Rien n'a vraiment changé. Seulement, les membres les plus éminents du
service "action" du hezbollah sont en vacances. Ou en pélerinage. Ou en camp de rééducation ... -- Pierre
Richard Delorme
Si la charte est bien ce qui est désigné sous le terme de "conseils d'utilisation" et publié ici 2 fois par mois, moi non plus je n'y ai vu aucun des mots "norme", "standard", "ANSI", "ISO"
Il est quand même fait mention du langage C, or ce qui définit le langage C est la(les) norme(s) du langage.
-- Richard
Si la charte est bien ce qui est désigné sous le terme de
"conseils d'utilisation" et publié ici 2 fois par mois, moi
non plus je n'y ai vu aucun des mots "norme", "standard",
"ANSI", "ISO"
Il est quand même fait mention du langage C, or ce qui définit le
langage C est la(les) norme(s) du langage.
Si la charte est bien ce qui est désigné sous le terme de "conseils d'utilisation" et publié ici 2 fois par mois, moi non plus je n'y ai vu aucun des mots "norme", "standard", "ANSI", "ISO"
Il est quand même fait mention du langage C, or ce qui définit le langage C est la(les) norme(s) du langage.
-- Richard
Richard Delorme
K. Ahausse wrote:
"Anthony" a écrit dans le message de news:412b4c28$0$22041$
Attention, cette question n'a pas sa place ici logiquement. Ces fonctions sont conformes à POSIX et non à C89 ou C99.
(-: Je me pose une question sommes-nous sur fr.comp.lang.c.norme.cx9 :-)
Je n'ai pas relue la charte récemment, mais je n'ai pas souvenir d'une restriction si contraignante.
Pareil, cependant chaque fois qu'une question sur une extension POSIX est posée ici elle recoit ce type de message (pour les souvenirs que j'en ai). Etant donné que j'ai quand même répondu, j'ai précisé ca pour pas me faire insulter de hors sujet ou quoi que ce soit :-)
Pour ma part je serai même pour répondre à toutes questions sur les semaphores, les fork() ou autre ici, mais je pense pas que tout le monde soit de mon avis.
A mon souvenir de la charte, ce groupe parle du langage en lui même, tel qu'il est décrit dans la norme et implémentable sur toute architecture à l'aide des outils adéquates. Je ne programme pas sous windows mais je ne pense pas que les gens sous cet "OS" aient des fonctions reg*() :)
En fait, les API propre à un OS sont clairement exclus par la charte. Si elle mentionne uniquement l'exemple des API windows, cela ne veut pas dire qu'elle autorise les extensions POSIX que l'on peut voir comme des API Unix.
-- Richard
K. Ahausse wrote:
"Anthony" <fleury_anthony@_hotmail_.com> a écrit dans le message de
news:412b4c28$0$22041$626a14ce@news.free.fr...
Attention, cette question n'a pas sa place ici logiquement. Ces fonctions
sont conformes à POSIX et non à C89 ou C99.
(-: Je me pose une question sommes-nous sur fr.comp.lang.c.norme.cx9 :-)
Je n'ai pas relue la charte récemment, mais je n'ai pas souvenir d'une
restriction si contraignante.
Pareil, cependant chaque fois qu'une question sur une extension POSIX est
posée ici elle recoit ce type de message (pour les souvenirs que j'en ai).
Etant donné que j'ai quand même répondu, j'ai précisé ca pour pas me faire
insulter de hors sujet ou quoi que ce soit :-)
Pour ma part je serai même pour répondre à toutes questions sur les
semaphores, les fork() ou autre ici, mais je pense pas que tout le monde
soit de mon avis.
A mon souvenir de la charte, ce groupe parle du langage en lui même, tel
qu'il est décrit dans la norme et implémentable sur toute architecture à
l'aide des outils adéquates. Je ne programme pas sous windows mais je ne
pense pas que les gens sous cet "OS" aient des fonctions reg*() :)
En fait, les API propre à un OS sont clairement exclus par la charte. Si
elle mentionne uniquement l'exemple des API windows, cela ne veut pas
dire qu'elle autorise les extensions POSIX que l'on peut voir comme des
API Unix.
"Anthony" a écrit dans le message de news:412b4c28$0$22041$
Attention, cette question n'a pas sa place ici logiquement. Ces fonctions sont conformes à POSIX et non à C89 ou C99.
(-: Je me pose une question sommes-nous sur fr.comp.lang.c.norme.cx9 :-)
Je n'ai pas relue la charte récemment, mais je n'ai pas souvenir d'une restriction si contraignante.
Pareil, cependant chaque fois qu'une question sur une extension POSIX est posée ici elle recoit ce type de message (pour les souvenirs que j'en ai). Etant donné que j'ai quand même répondu, j'ai précisé ca pour pas me faire insulter de hors sujet ou quoi que ce soit :-)
Pour ma part je serai même pour répondre à toutes questions sur les semaphores, les fork() ou autre ici, mais je pense pas que tout le monde soit de mon avis.
A mon souvenir de la charte, ce groupe parle du langage en lui même, tel qu'il est décrit dans la norme et implémentable sur toute architecture à l'aide des outils adéquates. Je ne programme pas sous windows mais je ne pense pas que les gens sous cet "OS" aient des fonctions reg*() :)
En fait, les API propre à un OS sont clairement exclus par la charte. Si elle mentionne uniquement l'exemple des API windows, cela ne veut pas dire qu'elle autorise les extensions POSIX que l'on peut voir comme des API Unix.
-- Richard
K. Ahausse
"Richard Delorme" a écrit dans le message de news:412e117c$0$313$
En fait, les API propre à un OS sont clairement exclus par la charte. Si elle mentionne uniquement l'exemple des API windows, cela ne veut pas dire qu'elle autorise les extensions POSIX que l'on peut voir comme des API Unix.
Je comprend ton interprétation. Mais cela reste une interpretation de la charte.
La charte ne mentionne pas de norme C, mais seules les questions sur la norme C seraient tolérables.
Il y a comme un bug, dans la charte Si les gens lisent la norme C de la même façon qu'ils lisent la charte, ça promet ...
"Richard Delorme" <abulmo@nospam.fr> a écrit dans le message de
news:412e117c$0$313$7a628cd7@news.club-internet.fr...
En fait, les API propre à un OS sont clairement exclus par la charte. Si
elle mentionne uniquement l'exemple des API windows, cela ne veut pas
dire qu'elle autorise les extensions POSIX que l'on peut voir comme des
API Unix.
Je comprend ton interprétation. Mais cela reste une interpretation de la
charte.
La charte ne mentionne pas de norme C, mais seules les questions sur la
norme C seraient tolérables.
Il y a comme un bug, dans la charte
Si les gens lisent la norme C de la même façon qu'ils lisent la charte, ça
promet ...
"Richard Delorme" a écrit dans le message de news:412e117c$0$313$
En fait, les API propre à un OS sont clairement exclus par la charte. Si elle mentionne uniquement l'exemple des API windows, cela ne veut pas dire qu'elle autorise les extensions POSIX que l'on peut voir comme des API Unix.
Je comprend ton interprétation. Mais cela reste une interpretation de la charte.
La charte ne mentionne pas de norme C, mais seules les questions sur la norme C seraient tolérables.
Il y a comme un bug, dans la charte Si les gens lisent la norme C de la même façon qu'ils lisent la charte, ça promet ...
Jean Claude Calvez
"Richard Delorme" a écrit dans le message de news: 412e1026$0$316$
Si la charte est bien ce qui est désigné sous le terme de "conseils d'utilisation" et publié ici 2 fois par mois, moi non plus je n'y ai vu aucun des mots "norme", "standard", "ANSI", "ISO"
Il est quand même fait mention du langage C,
C'est la moindre des choses ! :-)))
or ce qui définit le langage C est la(les) norme(s) du langage.
Effectivement, mais il n'est dit nulle part dans la charte/conseils d'utilisation qu'il faut se limiter à ça et qu'il est interdit de parler des extensions des diverses implémentations !!!
-- Richard
JCC
"Richard Delorme" <abulmo@nospam.fr> a écrit dans le message de news:
412e1026$0$316$7a628cd7@news.club-internet.fr...
Si la charte est bien ce qui est désigné sous le terme de
"conseils d'utilisation" et publié ici 2 fois par mois, moi
non plus je n'y ai vu aucun des mots "norme", "standard",
"ANSI", "ISO"
Il est quand même fait mention du langage C,
C'est la moindre des choses ! :-)))
or ce qui définit le
langage C est la(les) norme(s) du langage.
Effectivement, mais il n'est dit nulle part dans la
charte/conseils d'utilisation qu'il faut se limiter à
ça et qu'il est interdit de parler des extensions
des diverses implémentations !!!
"Richard Delorme" a écrit dans le message de news: 412e1026$0$316$
Si la charte est bien ce qui est désigné sous le terme de "conseils d'utilisation" et publié ici 2 fois par mois, moi non plus je n'y ai vu aucun des mots "norme", "standard", "ANSI", "ISO"
Il est quand même fait mention du langage C,
C'est la moindre des choses ! :-)))
or ce qui définit le langage C est la(les) norme(s) du langage.
Effectivement, mais il n'est dit nulle part dans la charte/conseils d'utilisation qu'il faut se limiter à ça et qu'il est interdit de parler des extensions des diverses implémentations !!!
-- Richard
JCC
Jean-Marc
"Jean Claude Calvez" a écrit dans le message de news:cgli7j$5g0$
Effectivement, mais il n'est dit nulle part dans la charte/conseils d'utilisation qu'il faut se limiter à ça et qu'il est interdit de parler des extensions des diverses implémentations !!!
Oh! Un vent de révolte souffle sur fclc?
On voit bien que ED est en vacances, il aurait sévi immédiatement :-)
-- Jean-marc
"Jean Claude Calvez" <jecalvez@wanadoo.fr> a écrit dans le message de
news:cgli7j$5g0$1@news-reader5.wanadoo.fr...
Effectivement, mais il n'est dit nulle part dans la
charte/conseils d'utilisation qu'il faut se limiter à
ça et qu'il est interdit de parler des extensions
des diverses implémentations !!!
Oh! Un vent de révolte souffle sur fclc?
On voit bien que ED est en vacances, il aurait sévi immédiatement :-)
"Jean Claude Calvez" a écrit dans le message de news:cgli7j$5g0$
Effectivement, mais il n'est dit nulle part dans la charte/conseils d'utilisation qu'il faut se limiter à ça et qu'il est interdit de parler des extensions des diverses implémentations !!!
Oh! Un vent de révolte souffle sur fclc?
On voit bien que ED est en vacances, il aurait sévi immédiatement :-)
-- Jean-marc
Pierre Maurette
"Jean Claude Calvez" a écrit:
"Richard Delorme" a écrit dans le message de news: 412e1026$0$316$
Si la charte est bien ce qui est désigné sous le terme de "conseils d'utilisation" et publié ici 2 fois par mois, moi non plus je n'y ai vu aucun des mots "norme", "standard", "ANSI", "ISO"
Il est quand même fait mention du langage C,
C'est la moindre des choses ! :-)))
or ce qui définit le langage C est la(les) norme(s) du langage.
Effectivement, mais il n'est dit nulle part dans la charte/conseils d'utilisation qu'il faut se limiter à ça et qu'il est interdit de parler des extensions des diverses implémentations !!! Tout à fait. Il me semble que le trafic C (et C++) sur l'usenet
francophone n'est pas suffisant pour être aussi restrictifs que par exemple les groupes anglophones modérés. Un exemple: les questions sur le lieur ou le gestionnaire de projet make. Où les poser ? Il faut faire la différence entre une question sur les API Windows, pour laquelle la redirection vers fr.comp.os.ms-windows.programmation et utile au posteur, et celles sur les fonctions "quasi standard". Si SetCurrentDirectory() n'a pas le comportement attendu, la question sera mieux honorée sur fcomp. En revanche, à la question fréquente de la manipulation des répertoires, pourquoi ne pas proposer opendir() et closedir()? La question de la manipulation des répertoires en C est une question de C. Elle n'a simplement pas de réponse portable. Et alors ? Elle a des réponses spécifiques, dont une réponse POSIX (qui couvre plus que Unix/Linux). -- Pierre
"Jean Claude Calvez" <jecalvez@wanadoo.fr> a écrit:
"Richard Delorme" <abulmo@nospam.fr> a écrit dans le message de news:
412e1026$0$316$7a628cd7@news.club-internet.fr...
Si la charte est bien ce qui est désigné sous le terme de
"conseils d'utilisation" et publié ici 2 fois par mois, moi
non plus je n'y ai vu aucun des mots "norme", "standard",
"ANSI", "ISO"
Il est quand même fait mention du langage C,
C'est la moindre des choses ! :-)))
or ce qui définit le
langage C est la(les) norme(s) du langage.
Effectivement, mais il n'est dit nulle part dans la
charte/conseils d'utilisation qu'il faut se limiter à
ça et qu'il est interdit de parler des extensions
des diverses implémentations !!!
Tout à fait. Il me semble que le trafic C (et C++) sur l'usenet
francophone n'est pas suffisant pour être aussi restrictifs que par
exemple les groupes anglophones modérés.
Un exemple: les questions sur le lieur ou le gestionnaire de projet
make. Où les poser ?
Il faut faire la différence entre une question sur les API Windows,
pour laquelle la redirection vers fr.comp.os.ms-windows.programmation
et utile au posteur, et celles sur les fonctions "quasi standard". Si
SetCurrentDirectory() n'a pas le comportement attendu, la question
sera mieux honorée sur fcomp.
En revanche, à la question fréquente de la manipulation des
répertoires, pourquoi ne pas proposer opendir() et closedir()?
La question de la manipulation des répertoires en C est une question
de C. Elle n'a simplement pas de réponse portable. Et alors ? Elle a
des réponses spécifiques, dont une réponse POSIX (qui couvre plus que
Unix/Linux).
--
Pierre
"Richard Delorme" a écrit dans le message de news: 412e1026$0$316$
Si la charte est bien ce qui est désigné sous le terme de "conseils d'utilisation" et publié ici 2 fois par mois, moi non plus je n'y ai vu aucun des mots "norme", "standard", "ANSI", "ISO"
Il est quand même fait mention du langage C,
C'est la moindre des choses ! :-)))
or ce qui définit le langage C est la(les) norme(s) du langage.
Effectivement, mais il n'est dit nulle part dans la charte/conseils d'utilisation qu'il faut se limiter à ça et qu'il est interdit de parler des extensions des diverses implémentations !!! Tout à fait. Il me semble que le trafic C (et C++) sur l'usenet
francophone n'est pas suffisant pour être aussi restrictifs que par exemple les groupes anglophones modérés. Un exemple: les questions sur le lieur ou le gestionnaire de projet make. Où les poser ? Il faut faire la différence entre une question sur les API Windows, pour laquelle la redirection vers fr.comp.os.ms-windows.programmation et utile au posteur, et celles sur les fonctions "quasi standard". Si SetCurrentDirectory() n'a pas le comportement attendu, la question sera mieux honorée sur fcomp. En revanche, à la question fréquente de la manipulation des répertoires, pourquoi ne pas proposer opendir() et closedir()? La question de la manipulation des répertoires en C est une question de C. Elle n'a simplement pas de réponse portable. Et alors ? Elle a des réponses spécifiques, dont une réponse POSIX (qui couvre plus que Unix/Linux). -- Pierre
Richard Delorme
Effectivement, mais il n'est dit nulle part dans la charte/conseils d'utilisation qu'il faut se limiter à ça et qu'il est interdit de parler des extensions des diverses implémentations !!!
Tout à fait. Il me semble que le trafic C (et C++) sur l'usenet francophone n'est pas suffisant pour être aussi restrictifs que par exemple les groupes anglophones modérés.
Ce n'est pas un problème de trafic, mais de compétences disponibles pour répondre aux questions.
Un exemple: les questions sur le lieur ou le gestionnaire de projet make. Où les poser ?
Pas ici.
Il faut faire la différence entre une question sur les API Windows, pour laquelle la redirection vers fr.comp.os.ms-windows.programmation et utile au posteur, et celles sur les fonctions "quasi standard". Si SetCurrentDirectory() n'a pas le comportement attendu, la question sera mieux honorée sur fcomp. En revanche, à la question fréquente de la manipulation des répertoires, pourquoi ne pas proposer opendir() et closedir()? La question de la manipulation des répertoires en C est une question de C. Elle n'a simplement pas de réponse portable. Et alors ? Elle a des réponses spécifiques, dont une réponse POSIX (qui couvre plus que Unix/Linux).
opendir(), closedir(), etc. sont définis dans Single Unix Specification version 3, alias Susv3. Tout naturellement, les gens qui programment abondamment les systèmes Unix connaissent mieux opendir() & co que les gens qui utilisent principalement le C standard. Le bon groupe pour opendir(), closedir(), etc. est donc fr.comp.os.unix.programmation, parce que, c'est là que la « question sera mieux honorée.»
A mon avis, il est faux de croire que opendir() est plus standard que SetCurrentDirectory(), même si le premier est défini par un comité de normalisation et le dernier par une entreprise privée. On oublie trop que Windows représente 95% du marché informatique et constitue un standard de fait. On oublie encore plus l'importance des systèmes embarqués (sans doute un ordre de grandeur plus grand que le marché informatique, je n'ai plus les chiffres en tête) et où le langage C est encore abondamment utilisé et où la notion de répertoire a sans doute peu de sens.
-- Richard
Effectivement, mais il n'est dit nulle part dans la
charte/conseils d'utilisation qu'il faut se limiter à
ça et qu'il est interdit de parler des extensions
des diverses implémentations !!!
Tout à fait. Il me semble que le trafic C (et C++) sur l'usenet
francophone n'est pas suffisant pour être aussi restrictifs que par
exemple les groupes anglophones modérés.
Ce n'est pas un problème de trafic, mais de compétences disponibles pour
répondre aux questions.
Un exemple: les questions sur le lieur ou le gestionnaire de projet
make. Où les poser ?
Pas ici.
Il faut faire la différence entre une question sur les API Windows,
pour laquelle la redirection vers fr.comp.os.ms-windows.programmation
et utile au posteur, et celles sur les fonctions "quasi standard". Si
SetCurrentDirectory() n'a pas le comportement attendu, la question
sera mieux honorée sur fcomp.
En revanche, à la question fréquente de la manipulation des
répertoires, pourquoi ne pas proposer opendir() et closedir()?
La question de la manipulation des répertoires en C est une question
de C. Elle n'a simplement pas de réponse portable. Et alors ? Elle a
des réponses spécifiques, dont une réponse POSIX (qui couvre plus que
Unix/Linux).
opendir(), closedir(), etc. sont définis dans Single Unix Specification
version 3, alias Susv3. Tout naturellement, les gens qui programment
abondamment les systèmes Unix connaissent mieux opendir() & co que les
gens qui utilisent principalement le C standard. Le bon groupe pour
opendir(), closedir(), etc. est donc fr.comp.os.unix.programmation,
parce que, c'est là que la « question sera mieux honorée.»
A mon avis, il est faux de croire que opendir() est plus standard que
SetCurrentDirectory(), même si le premier est défini par un comité de
normalisation et le dernier par une entreprise privée. On oublie trop
que Windows représente 95% du marché informatique et constitue un
standard de fait. On oublie encore plus l'importance des systèmes
embarqués (sans doute un ordre de grandeur plus grand que le marché
informatique, je n'ai plus les chiffres en tête) et où le langage C est
encore abondamment utilisé et où la notion de répertoire a sans doute
peu de sens.
Effectivement, mais il n'est dit nulle part dans la charte/conseils d'utilisation qu'il faut se limiter à ça et qu'il est interdit de parler des extensions des diverses implémentations !!!
Tout à fait. Il me semble que le trafic C (et C++) sur l'usenet francophone n'est pas suffisant pour être aussi restrictifs que par exemple les groupes anglophones modérés.
Ce n'est pas un problème de trafic, mais de compétences disponibles pour répondre aux questions.
Un exemple: les questions sur le lieur ou le gestionnaire de projet make. Où les poser ?
Pas ici.
Il faut faire la différence entre une question sur les API Windows, pour laquelle la redirection vers fr.comp.os.ms-windows.programmation et utile au posteur, et celles sur les fonctions "quasi standard". Si SetCurrentDirectory() n'a pas le comportement attendu, la question sera mieux honorée sur fcomp. En revanche, à la question fréquente de la manipulation des répertoires, pourquoi ne pas proposer opendir() et closedir()? La question de la manipulation des répertoires en C est une question de C. Elle n'a simplement pas de réponse portable. Et alors ? Elle a des réponses spécifiques, dont une réponse POSIX (qui couvre plus que Unix/Linux).
opendir(), closedir(), etc. sont définis dans Single Unix Specification version 3, alias Susv3. Tout naturellement, les gens qui programment abondamment les systèmes Unix connaissent mieux opendir() & co que les gens qui utilisent principalement le C standard. Le bon groupe pour opendir(), closedir(), etc. est donc fr.comp.os.unix.programmation, parce que, c'est là que la « question sera mieux honorée.»
A mon avis, il est faux de croire que opendir() est plus standard que SetCurrentDirectory(), même si le premier est défini par un comité de normalisation et le dernier par une entreprise privée. On oublie trop que Windows représente 95% du marché informatique et constitue un standard de fait. On oublie encore plus l'importance des systèmes embarqués (sans doute un ordre de grandeur plus grand que le marché informatique, je n'ai plus les chiffres en tête) et où le langage C est encore abondamment utilisé et où la notion de répertoire a sans doute peu de sens.
-- Richard
Pierre Maurette
Richard Delorme a écrit: [...]
standard de fait. On oublie encore plus l'importance des systèmes embarqués (sans doute un ordre de grandeur plus grand que le marché informatique, je n'ai plus les chiffres en tête) et où le langage C est encore abondamment utilisé et où la notion de répertoire a sans doute peu de sens. Je ne saisis pas bien.
En quoi les "gens de l'embarqué" pourraient-ils être génés par le fait que d'autres s'intéressent à la gestion des répertoires ?
Pour le reste, je respecte votre opinion, vous avez sans doute plus de droits que moi sur ce forum, et certainement un avis plus pertinent. Je n'en ai pas moins un avis. -- Pierre
Richard Delorme <abulmo@nospam.fr> a écrit:
[...]
standard de fait. On oublie encore plus l'importance des systèmes
embarqués (sans doute un ordre de grandeur plus grand que le marché
informatique, je n'ai plus les chiffres en tête) et où le langage C est
encore abondamment utilisé et où la notion de répertoire a sans doute
peu de sens.
Je ne saisis pas bien.
En quoi les "gens de l'embarqué" pourraient-ils être génés par le fait
que d'autres s'intéressent à la gestion des répertoires ?
Pour le reste, je respecte votre opinion, vous avez sans doute plus de
droits que moi sur ce forum, et certainement un avis plus pertinent.
Je n'en ai pas moins un avis.
--
Pierre
standard de fait. On oublie encore plus l'importance des systèmes embarqués (sans doute un ordre de grandeur plus grand que le marché informatique, je n'ai plus les chiffres en tête) et où le langage C est encore abondamment utilisé et où la notion de répertoire a sans doute peu de sens. Je ne saisis pas bien.
En quoi les "gens de l'embarqué" pourraient-ils être génés par le fait que d'autres s'intéressent à la gestion des répertoires ?
Pour le reste, je respecte votre opinion, vous avez sans doute plus de droits que moi sur ce forum, et certainement un avis plus pertinent. Je n'en ai pas moins un avis. -- Pierre
K. Ahausse
"Richard Delorme" a écrit dans le message de news:412eda10$0$313$
Effectivement, mais il n'est dit nulle part dans la charte/conseils d'utilisation qu'il faut se limiter à ça et qu'il est interdit de parler des extensions des diverses implémentations !!!
Tout à fait. Il me semble que le trafic C (et C++) sur l'usenet francophone n'est pas suffisant pour être aussi restrictifs que par exemple les groupes anglophones modérés.
Ce n'est pas un problème de trafic, mais de compétences disponibles pour répondre aux questions.
Un exemple: les questions sur le lieur ou le gestionnaire de projet make. Où les poser ?
Pas ici.
Il faut faire la différence entre une question sur les API Windows, pour laquelle la redirection vers fr.comp.os.ms-windows.programmation et utile au posteur, et celles sur les fonctions "quasi standard". Si SetCurrentDirectory() n'a pas le comportement attendu, la question sera mieux honorée sur fcomp. En revanche, à la question fréquente de la manipulation des répertoires, pourquoi ne pas proposer opendir() et closedir()? La question de la manipulation des répertoires en C est une question de C. Elle n'a simplement pas de réponse portable. Et alors ? Elle a des réponses spécifiques, dont une réponse POSIX (qui couvre plus que Unix/Linux).
opendir(), closedir(), etc. sont définis dans Single Unix Specification version 3, alias Susv3. Tout naturellement, les gens qui programment abondamment les systèmes Unix connaissent mieux opendir() & co que les gens qui utilisent principalement le C standard. Le bon groupe pour opendir(), closedir(), etc. est donc fr.comp.os.unix.programmation, parce que, c'est là que la « question sera mieux honorée.»
Il faudrait déjà que "fr.comp.os.unix.programmation" existât pour questionner les experts unix .
A mon avis, il est faux de croire que opendir() est plus standard que SetCurrentDirectory(), même si le premier est défini par un comité de normalisation et le dernier par une entreprise privée. On oublie trop que Windows représente 95% du marché informatique et constitue un standard de fait. On oublie encore plus l'importance des systèmes embarqués (sans doute un ordre de grandeur plus grand que le marché informatique, je n'ai plus les chiffres en tête) et où le langage C est encore abondamment utilisé et où la notion de répertoire a sans doute peu de sens.
Je ne comprends pas le rapport entre le fait que sur l'embarqué "où la notion de répertoire a sans doute peu de sens", et le pauvre débutant qui pose une question sur opendir et qui se fait gifler par un hors-norme-donc-hors-charte abusif.
"Richard Delorme" <abulmo@nospam.fr> a écrit dans le message de
news:412eda10$0$313$7a628cd7@news.club-internet.fr...
Effectivement, mais il n'est dit nulle part dans la
charte/conseils d'utilisation qu'il faut se limiter à
ça et qu'il est interdit de parler des extensions
des diverses implémentations !!!
Tout à fait. Il me semble que le trafic C (et C++) sur l'usenet
francophone n'est pas suffisant pour être aussi restrictifs que par
exemple les groupes anglophones modérés.
Ce n'est pas un problème de trafic, mais de compétences disponibles pour
répondre aux questions.
Un exemple: les questions sur le lieur ou le gestionnaire de projet
make. Où les poser ?
Pas ici.
Il faut faire la différence entre une question sur les API Windows,
pour laquelle la redirection vers fr.comp.os.ms-windows.programmation
et utile au posteur, et celles sur les fonctions "quasi standard". Si
SetCurrentDirectory() n'a pas le comportement attendu, la question
sera mieux honorée sur fcomp.
En revanche, à la question fréquente de la manipulation des
répertoires, pourquoi ne pas proposer opendir() et closedir()?
La question de la manipulation des répertoires en C est une question
de C. Elle n'a simplement pas de réponse portable. Et alors ? Elle a
des réponses spécifiques, dont une réponse POSIX (qui couvre plus que
Unix/Linux).
opendir(), closedir(), etc. sont définis dans Single Unix Specification
version 3, alias Susv3. Tout naturellement, les gens qui programment
abondamment les systèmes Unix connaissent mieux opendir() & co que les
gens qui utilisent principalement le C standard. Le bon groupe pour
opendir(), closedir(), etc. est donc fr.comp.os.unix.programmation,
parce que, c'est là que la « question sera mieux honorée.»
Il faudrait déjà que "fr.comp.os.unix.programmation" existât pour
questionner les experts unix .
A mon avis, il est faux de croire que opendir() est plus standard que
SetCurrentDirectory(), même si le premier est défini par un comité de
normalisation et le dernier par une entreprise privée. On oublie trop
que Windows représente 95% du marché informatique et constitue un
standard de fait. On oublie encore plus l'importance des systèmes
embarqués (sans doute un ordre de grandeur plus grand que le marché
informatique, je n'ai plus les chiffres en tête) et où le langage C est
encore abondamment utilisé et où la notion de répertoire a sans doute
peu de sens.
Je ne comprends pas le rapport entre le fait que sur l'embarqué "où la
notion de répertoire a sans doute
peu de sens", et le pauvre débutant qui pose une question sur opendir et
qui se fait gifler par un hors-norme-donc-hors-charte abusif.
"Richard Delorme" a écrit dans le message de news:412eda10$0$313$
Effectivement, mais il n'est dit nulle part dans la charte/conseils d'utilisation qu'il faut se limiter à ça et qu'il est interdit de parler des extensions des diverses implémentations !!!
Tout à fait. Il me semble que le trafic C (et C++) sur l'usenet francophone n'est pas suffisant pour être aussi restrictifs que par exemple les groupes anglophones modérés.
Ce n'est pas un problème de trafic, mais de compétences disponibles pour répondre aux questions.
Un exemple: les questions sur le lieur ou le gestionnaire de projet make. Où les poser ?
Pas ici.
Il faut faire la différence entre une question sur les API Windows, pour laquelle la redirection vers fr.comp.os.ms-windows.programmation et utile au posteur, et celles sur les fonctions "quasi standard". Si SetCurrentDirectory() n'a pas le comportement attendu, la question sera mieux honorée sur fcomp. En revanche, à la question fréquente de la manipulation des répertoires, pourquoi ne pas proposer opendir() et closedir()? La question de la manipulation des répertoires en C est une question de C. Elle n'a simplement pas de réponse portable. Et alors ? Elle a des réponses spécifiques, dont une réponse POSIX (qui couvre plus que Unix/Linux).
opendir(), closedir(), etc. sont définis dans Single Unix Specification version 3, alias Susv3. Tout naturellement, les gens qui programment abondamment les systèmes Unix connaissent mieux opendir() & co que les gens qui utilisent principalement le C standard. Le bon groupe pour opendir(), closedir(), etc. est donc fr.comp.os.unix.programmation, parce que, c'est là que la « question sera mieux honorée.»
Il faudrait déjà que "fr.comp.os.unix.programmation" existât pour questionner les experts unix .
A mon avis, il est faux de croire que opendir() est plus standard que SetCurrentDirectory(), même si le premier est défini par un comité de normalisation et le dernier par une entreprise privée. On oublie trop que Windows représente 95% du marché informatique et constitue un standard de fait. On oublie encore plus l'importance des systèmes embarqués (sans doute un ordre de grandeur plus grand que le marché informatique, je n'ai plus les chiffres en tête) et où le langage C est encore abondamment utilisé et où la notion de répertoire a sans doute peu de sens.
Je ne comprends pas le rapport entre le fait que sur l'embarqué "où la notion de répertoire a sans doute peu de sens", et le pauvre débutant qui pose une question sur opendir et qui se fait gifler par un hors-norme-donc-hors-charte abusif.
