J'ai des pb bizarres : dans une fonction j'ai besoin que l'utilisateur
me donne plusieurs infos, je fais donc des printf("question") et des scanf.
Sur les 3 premieres questions, ca marche bien, sur les 2 dernières, le
programme les affiche, mais le scanf ne semble pas marcher. Pourtant le
scanf recup sur les 5 fois un char *. C'est un bug? D'ailleurs si je ne
mets pas de \n sur le printf, parfois c'est encore pire...
voici un ex :
char *nom;
printf("nom\n");
scanf("%s", nom);
etc .. prenom, adress, tel, mail...
Parfois le scanf est comme sauté. Dans une autre fonction, je fais la
meme chose : une question, une reponse. Il m'affiche bien la question,
mais le scanf comme s'il était inactif, le programme ne me laisse pas
répondre, et passe à l'instruction suivante...
L'utilisation de + en javascript ne donne pas de résultat satisfaisant non plus...
+ est clairement de l'abus.
Que fait-il ?
--drkm
drkm
"Charlie Gordon" writes:
"Jean-Marc Bourguet" wrote in message news:
Pour les sorties, l'interet principal de l'utilisation des formats est l'internationalisation et la possibilite de mettre les parametres dans des ordres differents suivant les langages.
[...]
Il est clair qu'en C++, le mécanisme des streams rend tout cela carrément impossible sans recompilation.
Que veux-tu dire ?
--drkm
"Charlie Gordon" <news@chqrlie.org> writes:
"Jean-Marc Bourguet" <jm@bourguet.org> wrote in message
news:pxbu0s4ti2a.fsf@news.bourguet.org...
Pour les sorties, l'interet principal de l'utilisation des formats est
l'internationalisation et la possibilite de mettre les parametres dans
des ordres differents suivant les langages.
[...]
Il est clair qu'en C++, le mécanisme des streams rend tout cela carrément
impossible sans recompilation.
Pour les sorties, l'interet principal de l'utilisation des formats est l'internationalisation et la possibilite de mettre les parametres dans des ordres differents suivant les langages.
[...]
Il est clair qu'en C++, le mécanisme des streams rend tout cela carrément impossible sans recompilation.
Que veux-tu dire ?
--drkm
Jean-Marc Bourguet
drkm writes:
Jean-Marc Bourguet writes:
"Charlie Gordon" writes:
L'utilisation de + en javascript ne donne pas de résultat satisfaisant non plus...
+ est clairement de l'abus.
Que fait-il ?
Je ne connais pas javascript, mais utiliser + pour effectuer des E/S comme à l'air de l'indiquer Charlie c'est pire que du Perl...
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
drkm <usenet.fclcxx@fgeorges.org> writes:
Jean-Marc Bourguet <jm@bourguet.org> writes:
"Charlie Gordon" <news@chqrlie.org> writes:
L'utilisation de + en
javascript ne donne pas de résultat satisfaisant non
plus...
+ est clairement de l'abus.
Que fait-il ?
Je ne connais pas javascript, mais utiliser + pour effectuer
des E/S comme à l'air de l'indiquer Charlie c'est pire que
du Perl...
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
L'utilisation de + en javascript ne donne pas de résultat satisfaisant non plus...
+ est clairement de l'abus.
Que fait-il ?
Je ne connais pas javascript, mais utiliser + pour effectuer des E/S comme à l'air de l'indiquer Charlie c'est pire que du Perl...
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
Jean-Marc Bourguet
drkm writes:
"Charlie Gordon" writes:
"Jean-Marc Bourguet" wrote in message news:
Pour les sorties, l'interet principal de l'utilisation des formats est l'internationalisation et la possibilite de mettre les parametres dans des ordres differents suivant les langages.
[...]
Il est clair qu'en C++, le mécanisme des streams rend tout cela carrément impossible sans recompilation.
Que veux-tu dire ?
Que si tu utilises les IOStreams et que tu veux modifier l'ordre de deux éléments dans un sortie (ce qui est possible simplement en changeant le format -- récupéré par le méchanisme de localisation -- avec un printf POSIX ou avec le formatage de boost) il faut modifier ton code et recompiler.
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
drkm <usenet.fclcxx@fgeorges.org> writes:
"Charlie Gordon" <news@chqrlie.org> writes:
"Jean-Marc Bourguet" <jm@bourguet.org> wrote in message
news:pxbu0s4ti2a.fsf@news.bourguet.org...
Pour les sorties, l'interet principal de l'utilisation des formats est
l'internationalisation et la possibilite de mettre les parametres dans
des ordres differents suivant les langages.
[...]
Il est clair qu'en C++, le mécanisme des streams rend tout cela carrément
impossible sans recompilation.
Que veux-tu dire ?
Que si tu utilises les IOStreams et que tu veux modifier
l'ordre de deux éléments dans un sortie (ce qui est possible
simplement en changeant le format -- récupéré par le
méchanisme de localisation -- avec un printf POSIX ou avec
le formatage de boost) il faut modifier ton code et
recompiler.
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
Pour les sorties, l'interet principal de l'utilisation des formats est l'internationalisation et la possibilite de mettre les parametres dans des ordres differents suivant les langages.
[...]
Il est clair qu'en C++, le mécanisme des streams rend tout cela carrément impossible sans recompilation.
Que veux-tu dire ?
Que si tu utilises les IOStreams et que tu veux modifier l'ordre de deux éléments dans un sortie (ce qui est possible simplement en changeant le format -- récupéré par le méchanisme de localisation -- avec un printf POSIX ou avec le formatage de boost) il faut modifier ton code et recompiler.
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
drkm
Jean-Marc Bourguet writes:
drkm writes:
Jean-Marc Bourguet writes:
"Charlie Gordon" writes:
L'utilisation de + en javascript ne donne pas de résultat satisfaisant non plus...
+ est clairement de l'abus.
Que fait-il ?
Je ne connais pas javascript, mais utiliser + pour effectuer des E/S comme à l'air de l'indiquer Charlie c'est pire que du Perl...
Ok. Une sorte d'opérateur de concaténation avec entrée. J'étais resté dans les caractères spéciaux dans les chaînes de formatage (a.k.a. '%').
--drkm
Jean-Marc Bourguet <jm@bourguet.org> writes:
drkm <usenet.fclcxx@fgeorges.org> writes:
Jean-Marc Bourguet <jm@bourguet.org> writes:
"Charlie Gordon" <news@chqrlie.org> writes:
L'utilisation de + en
javascript ne donne pas de résultat satisfaisant non
plus...
+ est clairement de l'abus.
Que fait-il ?
Je ne connais pas javascript, mais utiliser + pour effectuer
des E/S comme à l'air de l'indiquer Charlie c'est pire que
du Perl...
Ok. Une sorte d'opérateur de concaténation avec entrée. J'étais
resté dans les caractères spéciaux dans les chaînes de formatage
(a.k.a. '%').
L'utilisation de + en javascript ne donne pas de résultat satisfaisant non plus...
+ est clairement de l'abus.
Que fait-il ?
Je ne connais pas javascript, mais utiliser + pour effectuer des E/S comme à l'air de l'indiquer Charlie c'est pire que du Perl...
Ok. Une sorte d'opérateur de concaténation avec entrée. J'étais resté dans les caractères spéciaux dans les chaînes de formatage (a.k.a. '%').
--drkm
drkm
Jean-Marc Bourguet writes:
drkm writes:
"Charlie Gordon" writes:
Il est clair qu'en C++, le mécanisme des streams rend tout cela carrément impossible sans recompilation.
Que veux-tu dire ?
Que si tu utilises les IOStreams et que tu veux modifier l'ordre de deux éléments dans un sortie (ce qui est possible simplement en changeant le format -- récupéré par le méchanisme de localisation -- avec un printf POSIX ou avec le formatage de boost) il faut modifier ton code et recompiler.
Mais Boost.Format permet justement de spécifier l'ordre dans la chaîne de formatage, sans modifier l'ordre des opérandes dans les sources. Et il utilise bien les IOStreams standards, non ?
Le GB_Format de James également, si je ne m'abuse.
--drkm
Jean-Marc Bourguet <jm@bourguet.org> writes:
drkm <usenet.fclcxx@fgeorges.org> writes:
"Charlie Gordon" <news@chqrlie.org> writes:
Il est clair qu'en C++, le mécanisme des streams rend tout cela carrément
impossible sans recompilation.
Que veux-tu dire ?
Que si tu utilises les IOStreams et que tu veux modifier
l'ordre de deux éléments dans un sortie (ce qui est possible
simplement en changeant le format -- récupéré par le
méchanisme de localisation -- avec un printf POSIX ou avec
le formatage de boost) il faut modifier ton code et
recompiler.
Mais Boost.Format permet justement de spécifier l'ordre dans la
chaîne de formatage, sans modifier l'ordre des opérandes dans les
sources. Et il utilise bien les IOStreams standards, non ?
Le GB_Format de James également, si je ne m'abuse.
Il est clair qu'en C++, le mécanisme des streams rend tout cela carrément impossible sans recompilation.
Que veux-tu dire ?
Que si tu utilises les IOStreams et que tu veux modifier l'ordre de deux éléments dans un sortie (ce qui est possible simplement en changeant le format -- récupéré par le méchanisme de localisation -- avec un printf POSIX ou avec le formatage de boost) il faut modifier ton code et recompiler.
Mais Boost.Format permet justement de spécifier l'ordre dans la chaîne de formatage, sans modifier l'ordre des opérandes dans les sources. Et il utilise bien les IOStreams standards, non ?
Le GB_Format de James également, si je ne m'abuse.
--drkm
Jean-Marc Bourguet
drkm writes:
Jean-Marc Bourguet writes:
drkm writes:
"Charlie Gordon" writes:
Il est clair qu'en C++, le mécanisme des streams rend tout cela carrément impossible sans recompilation.
Que veux-tu dire ?
Que si tu utilises les IOStreams et que tu veux modifier l'ordre de deux éléments dans un sortie (ce qui est possible simplement en changeant le format -- récupéré par le méchanisme de localisation -- avec un printf POSIX ou avec le formatage de boost) il faut modifier ton code et recompiler.
Mais Boost.Format permet justement de spécifier l'ordre dans la chaîne de formatage, sans modifier l'ordre des opérandes dans les sources. Et il utilise bien les IOStreams standards, non ?
Le GB_Format de James également, si je ne m'abuse.
C'est la beauté des templates :-)
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
drkm <usenet.fclcxx@fgeorges.org> writes:
Jean-Marc Bourguet <jm@bourguet.org> writes:
drkm <usenet.fclcxx@fgeorges.org> writes:
"Charlie Gordon" <news@chqrlie.org> writes:
Il est clair qu'en C++, le mécanisme des streams rend tout cela carrément
impossible sans recompilation.
Que veux-tu dire ?
Que si tu utilises les IOStreams et que tu veux modifier
l'ordre de deux éléments dans un sortie (ce qui est possible
simplement en changeant le format -- récupéré par le
méchanisme de localisation -- avec un printf POSIX ou avec
le formatage de boost) il faut modifier ton code et
recompiler.
Mais Boost.Format permet justement de spécifier l'ordre dans la
chaîne de formatage, sans modifier l'ordre des opérandes dans les
sources. Et il utilise bien les IOStreams standards, non ?
Le GB_Format de James également, si je ne m'abuse.
C'est la beauté des templates :-)
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
Il est clair qu'en C++, le mécanisme des streams rend tout cela carrément impossible sans recompilation.
Que veux-tu dire ?
Que si tu utilises les IOStreams et que tu veux modifier l'ordre de deux éléments dans un sortie (ce qui est possible simplement en changeant le format -- récupéré par le méchanisme de localisation -- avec un printf POSIX ou avec le formatage de boost) il faut modifier ton code et recompiler.
Mais Boost.Format permet justement de spécifier l'ordre dans la chaîne de formatage, sans modifier l'ordre des opérandes dans les sources. Et il utilise bien les IOStreams standards, non ?
Le GB_Format de James également, si je ne m'abuse.
C'est la beauté des templates :-)
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
| Jean-Marc Bourguet writes: | | > C'est la beauté des templates :-) | | Bof. En C, on a les macros de préprocesseur ;-)
T'as essayé ? semi ;-)
-- Gaby
Charlie Gordon
"Jean-Marc Bourguet" wrote in message news:
drkm writes:
Jean-Marc Bourguet writes:
"Charlie Gordon" writes:
L'utilisation de + en javascript ne donne pas de résultat satisfaisant non plus...
+ est clairement de l'abus.
Que fait-il ?
Je ne connais pas javascript, mais utiliser + pour effectuer des E/S comme à l'air de l'indiquer Charlie c'est pire que du Perl...
Non, + fait juste la concaténation des chaines en javascript. Le problème est à la fois une question de lisibilité et un problème de typage. On peut comparer la lisibilité respective de :
C: printf("x=%d, y=%dn", x, y); C++: cout << "x=" << x << ", y=" << y << "n"; Javascript: document.write("x=" + x + ", y=" + y + "n"); Perl: print("x=$x, y=$yn");
Il faut bien reconnaitre que Perl est de loin le plus lisible.
Le problème de typage est causé par la combinaison du polymorphisme de l'opérateur + et du typage dynamique des variables en javascript. Il arrive souvent que les variables n'ont pas le type que le programmeur intuite lorsqu'il écrit une expression. Or la sémantique de l'addition des nombres et de la concaténation des chaines sont fort différentes, comme la comparaison numérique et lexicographique. Utiliser la meme syntaxe pour ces deux concepts est une source de bugs. Ce problème ne se pose pas en C : il n'y a pas d'opérateur de concaténation de chaines. En C++ ou en java, le type des opérandes est mieux contrôlé par le programmeur parce que le typage est statique. Mais il arrive quand meme lors des comparaisons si les conventions de nommages ne sont pas assez claires. Le grand classique est :
if (this->montant > this->montant_max) { /* traiter l'erreur */ }
si ces champs sont des chaines, le code reste correct, mais la sémantique change. C++, javascript, et surtout PHP ont ce problème. Il peut meme se produire en C ! En Perl, les opérations de comparaisons numériques et lexicographiques s'expriment avec des opérateurs différents. Pareil pour l'addition et la concaténation.
Enfin pour ce qui est de la flexibilité pour la traduction avec changement d'ordre des paramètres, des quatre seuls C et Perl s'y prêtent, et encore pour C il faut une extension POSIX assez illisible, et pour Perl c'est grâce à la recompilation que cela se fait bien.
J'ai étudié comment faire une extension de syntaxe au langage C pour supporter la substitution de variables dans les chaines, avec autant que possible de bonnes propriétés pour la localisation sans recompilation : on peut obtenir des résultats intéressants dans des contextes spécifiques comme le formatage des sorties, mais pour le cas général, il faut un mécanisme de gestion des chaines de caractères dynamiques, qui a des implications assez lourdes partout. Ce serait beaucoup plus facile à faire pour java.
Chqrlie.
"Jean-Marc Bourguet" <jm@bourguet.org> wrote in message
news:87y8hckos3.fsf@news.bourguet.org...
drkm <usenet.fclcxx@fgeorges.org> writes:
Jean-Marc Bourguet <jm@bourguet.org> writes:
"Charlie Gordon" <news@chqrlie.org> writes:
L'utilisation de + en
javascript ne donne pas de résultat satisfaisant non
plus...
+ est clairement de l'abus.
Que fait-il ?
Je ne connais pas javascript, mais utiliser + pour effectuer
des E/S comme à l'air de l'indiquer Charlie c'est pire que
du Perl...
Non, + fait juste la concaténation des chaines en javascript.
Le problème est à la fois une question de lisibilité et un problème de typage.
On peut comparer la lisibilité respective de :
C: printf("x=%d, y=%dn", x, y);
C++: cout << "x=" << x << ", y=" << y << "n";
Javascript: document.write("x=" + x + ", y=" + y + "n");
Perl: print("x=$x, y=$yn");
Il faut bien reconnaitre que Perl est de loin le plus lisible.
Le problème de typage est causé par la combinaison du polymorphisme de
l'opérateur + et du typage dynamique des variables en javascript. Il arrive
souvent que les variables n'ont pas le type que le programmeur intuite lorsqu'il
écrit une expression. Or la sémantique de l'addition des nombres et de la
concaténation des chaines sont fort différentes, comme la comparaison numérique
et lexicographique. Utiliser la meme syntaxe pour ces deux concepts est une
source de bugs.
Ce problème ne se pose pas en C : il n'y a pas d'opérateur de concaténation de
chaines.
En C++ ou en java, le type des opérandes est mieux contrôlé par le programmeur
parce que le typage est statique. Mais il arrive quand meme lors des
comparaisons si les conventions de nommages ne sont pas assez claires. Le grand
classique est :
if (this->montant > this->montant_max) {
/* traiter l'erreur */
}
si ces champs sont des chaines, le code reste correct, mais la sémantique
change.
C++, javascript, et surtout PHP ont ce problème. Il peut meme se produire en C
!
En Perl, les opérations de comparaisons numériques et lexicographiques
s'expriment avec des opérateurs différents. Pareil pour l'addition et la
concaténation.
Enfin pour ce qui est de la flexibilité pour la traduction avec changement
d'ordre des paramètres, des quatre seuls C et Perl s'y prêtent, et encore pour C
il faut une extension POSIX assez illisible, et pour Perl c'est grâce à la
recompilation que cela se fait bien.
J'ai étudié comment faire une extension de syntaxe au langage C pour supporter
la substitution de variables dans les chaines, avec autant que possible de
bonnes propriétés pour la localisation sans recompilation : on peut obtenir des
résultats intéressants dans des contextes spécifiques comme le formatage des
sorties, mais pour le cas général, il faut un mécanisme de gestion des chaines
de caractères dynamiques, qui a des implications assez lourdes partout. Ce
serait beaucoup plus facile à faire pour java.
L'utilisation de + en javascript ne donne pas de résultat satisfaisant non plus...
+ est clairement de l'abus.
Que fait-il ?
Je ne connais pas javascript, mais utiliser + pour effectuer des E/S comme à l'air de l'indiquer Charlie c'est pire que du Perl...
Non, + fait juste la concaténation des chaines en javascript. Le problème est à la fois une question de lisibilité et un problème de typage. On peut comparer la lisibilité respective de :
C: printf("x=%d, y=%dn", x, y); C++: cout << "x=" << x << ", y=" << y << "n"; Javascript: document.write("x=" + x + ", y=" + y + "n"); Perl: print("x=$x, y=$yn");
Il faut bien reconnaitre que Perl est de loin le plus lisible.
Le problème de typage est causé par la combinaison du polymorphisme de l'opérateur + et du typage dynamique des variables en javascript. Il arrive souvent que les variables n'ont pas le type que le programmeur intuite lorsqu'il écrit une expression. Or la sémantique de l'addition des nombres et de la concaténation des chaines sont fort différentes, comme la comparaison numérique et lexicographique. Utiliser la meme syntaxe pour ces deux concepts est une source de bugs. Ce problème ne se pose pas en C : il n'y a pas d'opérateur de concaténation de chaines. En C++ ou en java, le type des opérandes est mieux contrôlé par le programmeur parce que le typage est statique. Mais il arrive quand meme lors des comparaisons si les conventions de nommages ne sont pas assez claires. Le grand classique est :
if (this->montant > this->montant_max) { /* traiter l'erreur */ }
si ces champs sont des chaines, le code reste correct, mais la sémantique change. C++, javascript, et surtout PHP ont ce problème. Il peut meme se produire en C ! En Perl, les opérations de comparaisons numériques et lexicographiques s'expriment avec des opérateurs différents. Pareil pour l'addition et la concaténation.
Enfin pour ce qui est de la flexibilité pour la traduction avec changement d'ordre des paramètres, des quatre seuls C et Perl s'y prêtent, et encore pour C il faut une extension POSIX assez illisible, et pour Perl c'est grâce à la recompilation que cela se fait bien.
J'ai étudié comment faire une extension de syntaxe au langage C pour supporter la substitution de variables dans les chaines, avec autant que possible de bonnes propriétés pour la localisation sans recompilation : on peut obtenir des résultats intéressants dans des contextes spécifiques comme le formatage des sorties, mais pour le cas général, il faut un mécanisme de gestion des chaines de caractères dynamiques, qui a des implications assez lourdes partout. Ce serait beaucoup plus facile à faire pour java.
