Pourquoi ? J'ai eu vu refuser ici l'emploi de "méthode" à la place de "fonction
membre". C'est tout ;-) -- Pierre
Ivan Vecerina
"Rudy" wrote in message news:423f0f17$0$5076$
J'aimerai faire une action en fonction du type de la variable enregistrée avec un cin.
Ainsi, si c'est un entier, il se passe quelque chose, sinon il se passe autre chose ... Au cas où, une solution pratique:
1) lire l'entrée comme une chaîne de caractères: std::string input; bool ok1 = ( cin >> input ); // ou getline...
2) voir si l'on parvient à lire la chaîne comme un nombre std::istringstream stringReader(input); int nb; bool okTrouveNombre = ( stringReader >> nb ); bool okRienNeSuit = stringReader.eof(); // sinon il reste autre caracs. if( okTrouveNombre && okRienNeSuit ) { // nb est le nombre qui fut entré } else { // input ne contient pas (uniquement) un nombre }
(Alternativement, il y a une fonction du C: strtol...)
-- http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form
"Rudy" <rudy.vogel@free.fr> wrote in message
news:423f0f17$0$5076$626a14ce@news.free.fr...
J'aimerai faire une action en fonction du type de la variable enregistrée
avec un cin.
Ainsi, si c'est un entier, il se passe quelque chose, sinon il se passe
autre chose ...
Au cas où, une solution pratique:
1) lire l'entrée comme une chaîne de caractères:
std::string input;
bool ok1 = ( cin >> input ); // ou getline...
2) voir si l'on parvient à lire la chaîne comme un nombre
std::istringstream stringReader(input);
int nb;
bool okTrouveNombre = ( stringReader >> nb );
bool okRienNeSuit = stringReader.eof(); // sinon il reste autre caracs.
if( okTrouveNombre && okRienNeSuit )
{
// nb est le nombre qui fut entré
}
else
{
// input ne contient pas (uniquement) un nombre
}
(Alternativement, il y a une fonction du C: strtol...)
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form
J'aimerai faire une action en fonction du type de la variable enregistrée avec un cin.
Ainsi, si c'est un entier, il se passe quelque chose, sinon il se passe autre chose ... Au cas où, une solution pratique:
1) lire l'entrée comme une chaîne de caractères: std::string input; bool ok1 = ( cin >> input ); // ou getline...
2) voir si l'on parvient à lire la chaîne comme un nombre std::istringstream stringReader(input); int nb; bool okTrouveNombre = ( stringReader >> nb ); bool okRienNeSuit = stringReader.eof(); // sinon il reste autre caracs. if( okTrouveNombre && okRienNeSuit ) { // nb est le nombre qui fut entré } else { // input ne contient pas (uniquement) un nombre }
(Alternativement, il y a une fonction du C: strtol...)
-- http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form
Loïc Joly
Pierre Maurette wrote:
(Evite également de parler de méthode)
Pourquoi ?
Méthode n'est pas un mot défini en C++. Et le problème est que pour certains, il signifie fonction membre, pour d'autres fonctions membre virtuelle. Donc, devant l'ambiguité, autant éviter ce mot.
-- Loïc
Pierre Maurette wrote:
(Evite également de parler de méthode)
Pourquoi ?
Méthode n'est pas un mot défini en C++. Et le problème est que pour
certains, il signifie fonction membre, pour d'autres fonctions membre
virtuelle. Donc, devant l'ambiguité, autant éviter ce mot.
Méthode n'est pas un mot défini en C++. Et le problème est que pour certains, il signifie fonction membre, pour d'autres fonctions membre virtuelle. Donc, devant l'ambiguité, autant éviter ce mot.
-- Loïc
kanze
Rudy wrote:
Il te faut mettre les caractères tapés dans une chaîne (avec std::getline() si possible, histoire de gérer le cas où l'utilisateur tape un espace) et analyser la chaîne en question.
Par exemple, si la chaîne contient un point, l'utilisateur a rentré un flottant. Si la chaîne ne contient pas de point, c'est un entier. Si elle en contient deux, c'est une erreur.
Mais ttention aux cas tordus : 1e+3 = 1000.0, pas de souci. Mais que vaut 1e3 ? 1000.0 ou 0x1e3 == 483 ?
Et si l'utilisateur tape 123456789012345678901234 ? C'est un entier, mais il lui faut plus de 64 bits, et il y a peu de chances que ton compilo supporte ça en natif. On peut le mettre dans un double, mais avec perte de précision.
En fait, il faudrait considérer le cas où il n'y a pas d'espace, ni de
points ; la chaîne est soit un entier, soit des lettres ; il n'y a pas de
risques de dépasser la capacité ; et il n'y a pas de cas tordus ;-)
En somme, il s'agit de la validation des entrées, tout simplement.
Pour le cas général, il y a boost::regex, mais d'après d'autres postings dans ce thread, je ne crois pas que tu en es encore là. (Mais pour je ne sais pas quelle raison, ce thread apparaît dans le désordre complet chez moi ; j'ai donc du mal à le suivre réelement.) S'il s'agit simplement des entrées d'un entier par ligne que tu veux valider, la plus simple, c'est de lire ligne par ligne, puis d'utiliser un std::istringstream pour en extraire la valeur entière et vérifier l'erreur :
std::string line ; while ( std::getline( std::cin, line ) ) { std::istringstream data( line ) ; int value ; if ( data >> value >> std::ws && data.get() == EOF ) { // c'est bon. } else { // il y a une erreur dans la ligne } }
Je suppose que tu connais déjà istringstream -- sinon, c'est juste un flux comme les autres, mais qui lit d'une chaîne de caractères, et non d'une périphérique. Quand à l'expression dans l'« if » :
-- Le résultat de l'opérateur >> sur un flux, c'est une référence au flux. On peut donc les enchaîner.
-- Il existe des types et des valeurs spéciaux, appeler manipulateurs, qui ne stockent pas de valeur en entrée (et qui n'en sortent pas en sortie), mais qui effectue une opération particulière sur le flux ; on les appelle des manipulateurs. Tu les as probablement vus en sortie, par exemple std::setw. Ici, je me suis servi de std::ws en entrée, qui extrait les caractères blancs du flux (sans les stocker nul part). (Un caractère « blanc », ici, c'est tout caractère pour lequel isspace est vrai. Donc, des blancs, des tabs, des sauts de ligne...)
-- Point principal : un flux peut servir de valeur booléene ; dans tel cas, il évalue vrai s'il n'y a pas eu d'erreur, et faux s'il y a eu une erreur.
Quand on lit un entier, le flux saute les blancs. Puis, il essaie de convertir un entier. S'il n'y a pas d'entier, c'est une erreur. Sinon, il s'arrête au premier caractère qui ne pourrait pas faire partie de l'entier, et convertit les caractères qu'il a trouvé. Donc, si tu entres "a", la conversion en entier va échouer, et tu aurais une erreur. Si tu entres "12a", la conversion en entier réussit, et donne la valeur 12.
Aussi, en passant, l'erreur est persistante ; une fois que le flux a detecté une erreur, il reste en état d'erreur jusqu'à ce que quelqu'un remet à zéro l'erreur explicitement (fonction clear()).
-- Enfin, les flux ont aussi des fonctions classiques pour lire des caractères sans formattage -- get() lit le prochain caractère, et le renvoie sur un int (non un char), avec soit la valeur du caractère (entre 0 et UCHAR_MAX), soit EOF (qui est garanti négatif). Ici, puisqu'on a lu un entier, puis sauter des blancs qui aurait pû le suivre, on doit être à la fin. Sinon, c'est qu'il y a eu un caractère autre qu'un chiffre ou un espace (ou qu'il y a eu des espaces entre deux chiffres). C-à-d une erreur.
Cette dernière partie (après le &&) sert à attrapper les erreurs comme "12a".
Si j'en ai parlé aussi longuement, c'est que cet idiome est consacré, et il vaut vraiment la peine de l'apprendre bien. Lire ligne par ligne, puis enchaîner une séquence d'opérateurs >> sur un istringstream initialisé avec la ligne, c'est la façon classique à interpréter un flux avec un format simple orienté ligne ; il vaut la peine d'être connu.
En réalité, l'utilisateur, c'est moi ; et je risque juste de me tromper en tapant "(" au lieu de "5" par ex, étant donné que j'utilise un ordi portable sans pavé numérique ...
Et un clavier français :-). (C'est le seul clavier que je connais où il faut faire shift pour avoir les chiffres.)
Rudy wrote:
Il te faut mettre les caractères tapés dans une chaîne (avec
std::getline() si possible, histoire de gérer le cas où
l'utilisateur tape un espace) et analyser la chaîne en
question.
Par exemple, si la chaîne contient un point, l'utilisateur a
rentré un flottant. Si la chaîne ne contient pas de point,
c'est un entier. Si elle en contient deux, c'est une erreur.
Mais ttention aux cas tordus : 1e+3 = 1000.0, pas de souci.
Mais que vaut 1e3 ? 1000.0 ou 0x1e3 == 483 ?
Et si l'utilisateur tape 123456789012345678901234 ? C'est un
entier, mais il lui faut plus de 64 bits, et il y a peu de
chances que ton compilo supporte ça en natif. On peut le
mettre dans un double, mais avec perte de précision.
En fait, il faudrait considérer le cas où il n'y a pas d'espace, ni
de
points ; la chaîne est soit un entier, soit des lettres ; il n'y a
pas de
risques de dépasser la capacité ; et il n'y a pas de cas tordus ;-)
En somme, il s'agit de la validation des entrées, tout
simplement.
Pour le cas général, il y a boost::regex, mais d'après d'autres
postings dans ce thread, je ne crois pas que tu en es encore là.
(Mais pour je ne sais pas quelle raison, ce thread apparaît dans
le désordre complet chez moi ; j'ai donc du mal à le suivre
réelement.) S'il s'agit simplement des entrées d'un entier par
ligne que tu veux valider, la plus simple, c'est de lire ligne
par ligne, puis d'utiliser un std::istringstream pour en
extraire la valeur entière et vérifier l'erreur :
std::string line ;
while ( std::getline( std::cin, line ) ) {
std::istringstream data( line ) ;
int value ;
if ( data >> value >> std::ws && data.get() == EOF ) {
// c'est bon.
} else {
// il y a une erreur dans la ligne
}
}
Je suppose que tu connais déjà istringstream -- sinon, c'est
juste un flux comme les autres, mais qui lit d'une chaîne de
caractères, et non d'une périphérique. Quand à l'expression dans
l'« if » :
-- Le résultat de l'opérateur >> sur un flux, c'est une
référence au flux. On peut donc les enchaîner.
-- Il existe des types et des valeurs spéciaux, appeler
manipulateurs, qui ne stockent pas de valeur en entrée (et
qui n'en sortent pas en sortie), mais qui effectue une
opération particulière sur le flux ; on les appelle des
manipulateurs. Tu les as probablement vus en sortie, par
exemple std::setw. Ici, je me suis servi de std::ws en
entrée, qui extrait les caractères blancs du flux (sans les
stocker nul part). (Un caractère « blanc », ici, c'est tout
caractère pour lequel isspace est vrai. Donc, des blancs,
des tabs, des sauts de ligne...)
-- Point principal : un flux peut servir de valeur booléene ;
dans tel cas, il évalue vrai s'il n'y a pas eu d'erreur, et
faux s'il y a eu une erreur.
Quand on lit un entier, le flux saute les blancs. Puis, il
essaie de convertir un entier. S'il n'y a pas d'entier,
c'est une erreur. Sinon, il s'arrête au premier caractère
qui ne pourrait pas faire partie de l'entier, et convertit
les caractères qu'il a trouvé. Donc, si tu entres "a", la
conversion en entier va échouer, et tu aurais une erreur. Si
tu entres "12a", la conversion en entier réussit, et donne
la valeur 12.
Aussi, en passant, l'erreur est persistante ; une fois que
le flux a detecté une erreur, il reste en état d'erreur
jusqu'à ce que quelqu'un remet à zéro l'erreur
explicitement (fonction clear()).
-- Enfin, les flux ont aussi des fonctions classiques pour lire
des caractères sans formattage -- get() lit le prochain
caractère, et le renvoie sur un int (non un char), avec soit
la valeur du caractère (entre 0 et UCHAR_MAX), soit EOF (qui
est garanti négatif). Ici, puisqu'on a lu un entier, puis
sauter des blancs qui aurait pû le suivre, on doit être à la
fin. Sinon, c'est qu'il y a eu un caractère autre qu'un
chiffre ou un espace (ou qu'il y a eu des espaces entre deux
chiffres). C-à-d une erreur.
Cette dernière partie (après le &&) sert à attrapper les
erreurs comme "12a".
Si j'en ai parlé aussi longuement, c'est que cet idiome est
consacré, et il vaut vraiment la peine de l'apprendre bien. Lire
ligne par ligne, puis enchaîner une séquence d'opérateurs >> sur
un istringstream initialisé avec la ligne, c'est la façon
classique à interpréter un flux avec un format simple orienté
ligne ; il vaut la peine d'être connu.
En réalité, l'utilisateur, c'est moi ; et je risque juste de
me tromper en tapant "(" au lieu de "5" par ex, étant donné
que j'utilise un ordi portable sans pavé numérique ...
Et un clavier français :-). (C'est le seul clavier que je
connais où il faut faire shift pour avoir les chiffres.)
Il te faut mettre les caractères tapés dans une chaîne (avec std::getline() si possible, histoire de gérer le cas où l'utilisateur tape un espace) et analyser la chaîne en question.
Par exemple, si la chaîne contient un point, l'utilisateur a rentré un flottant. Si la chaîne ne contient pas de point, c'est un entier. Si elle en contient deux, c'est une erreur.
Mais ttention aux cas tordus : 1e+3 = 1000.0, pas de souci. Mais que vaut 1e3 ? 1000.0 ou 0x1e3 == 483 ?
Et si l'utilisateur tape 123456789012345678901234 ? C'est un entier, mais il lui faut plus de 64 bits, et il y a peu de chances que ton compilo supporte ça en natif. On peut le mettre dans un double, mais avec perte de précision.
En fait, il faudrait considérer le cas où il n'y a pas d'espace, ni de
points ; la chaîne est soit un entier, soit des lettres ; il n'y a pas de
risques de dépasser la capacité ; et il n'y a pas de cas tordus ;-)
En somme, il s'agit de la validation des entrées, tout simplement.
Pour le cas général, il y a boost::regex, mais d'après d'autres postings dans ce thread, je ne crois pas que tu en es encore là. (Mais pour je ne sais pas quelle raison, ce thread apparaît dans le désordre complet chez moi ; j'ai donc du mal à le suivre réelement.) S'il s'agit simplement des entrées d'un entier par ligne que tu veux valider, la plus simple, c'est de lire ligne par ligne, puis d'utiliser un std::istringstream pour en extraire la valeur entière et vérifier l'erreur :
std::string line ; while ( std::getline( std::cin, line ) ) { std::istringstream data( line ) ; int value ; if ( data >> value >> std::ws && data.get() == EOF ) { // c'est bon. } else { // il y a une erreur dans la ligne } }
Je suppose que tu connais déjà istringstream -- sinon, c'est juste un flux comme les autres, mais qui lit d'une chaîne de caractères, et non d'une périphérique. Quand à l'expression dans l'« if » :
-- Le résultat de l'opérateur >> sur un flux, c'est une référence au flux. On peut donc les enchaîner.
-- Il existe des types et des valeurs spéciaux, appeler manipulateurs, qui ne stockent pas de valeur en entrée (et qui n'en sortent pas en sortie), mais qui effectue une opération particulière sur le flux ; on les appelle des manipulateurs. Tu les as probablement vus en sortie, par exemple std::setw. Ici, je me suis servi de std::ws en entrée, qui extrait les caractères blancs du flux (sans les stocker nul part). (Un caractère « blanc », ici, c'est tout caractère pour lequel isspace est vrai. Donc, des blancs, des tabs, des sauts de ligne...)
-- Point principal : un flux peut servir de valeur booléene ; dans tel cas, il évalue vrai s'il n'y a pas eu d'erreur, et faux s'il y a eu une erreur.
Quand on lit un entier, le flux saute les blancs. Puis, il essaie de convertir un entier. S'il n'y a pas d'entier, c'est une erreur. Sinon, il s'arrête au premier caractère qui ne pourrait pas faire partie de l'entier, et convertit les caractères qu'il a trouvé. Donc, si tu entres "a", la conversion en entier va échouer, et tu aurais une erreur. Si tu entres "12a", la conversion en entier réussit, et donne la valeur 12.
Aussi, en passant, l'erreur est persistante ; une fois que le flux a detecté une erreur, il reste en état d'erreur jusqu'à ce que quelqu'un remet à zéro l'erreur explicitement (fonction clear()).
-- Enfin, les flux ont aussi des fonctions classiques pour lire des caractères sans formattage -- get() lit le prochain caractère, et le renvoie sur un int (non un char), avec soit la valeur du caractère (entre 0 et UCHAR_MAX), soit EOF (qui est garanti négatif). Ici, puisqu'on a lu un entier, puis sauter des blancs qui aurait pû le suivre, on doit être à la fin. Sinon, c'est qu'il y a eu un caractère autre qu'un chiffre ou un espace (ou qu'il y a eu des espaces entre deux chiffres). C-à-d une erreur.
Cette dernière partie (après le &&) sert à attrapper les erreurs comme "12a".
Si j'en ai parlé aussi longuement, c'est que cet idiome est consacré, et il vaut vraiment la peine de l'apprendre bien. Lire ligne par ligne, puis enchaîner une séquence d'opérateurs >> sur un istringstream initialisé avec la ligne, c'est la façon classique à interpréter un flux avec un format simple orienté ligne ; il vaut la peine d'être connu.
En réalité, l'utilisateur, c'est moi ; et je risque juste de me tromper en tapant "(" au lieu de "5" par ex, étant donné que j'utilise un ordi portable sans pavé numérique ...
Et un clavier français :-). (C'est le seul clavier que je connais où il faut faire shift pour avoir les chiffres.)
Fabien LE LEZ
On 22 Mar 2005 00:31:27 -0800, :
Et un clavier français :-). (C'est le seul clavier que je connais où il faut faire shift pour avoir les chiffres.)
C'est normal, la France est toujours en retard, du coup le problème des claviers de portable s'est posé trop tard ;-p
-- ;-)
On 22 Mar 2005 00:31:27 -0800, kanze@gabi-soft.fr:
Et un clavier français :-). (C'est le seul clavier que je
connais où il faut faire shift pour avoir les chiffres.)
C'est normal, la France est toujours en retard, du coup le problème
des claviers de portable s'est posé trop tard ;-p
Et un clavier français :-). (C'est le seul clavier que je connais où il faut faire shift pour avoir les chiffres.)
C'est normal, la France est toujours en retard, du coup le problème des claviers de portable s'est posé trop tard ;-p
-- ;-)
Alexandre
Ah ouais ?!?!?! La prof nous a dit qu'il existait des fonctions ET des procédures !!!
oui, elle a raison sur le principe algorithmique. Simplement C++ (et C) ne font pas vraiment la différence. Une procédure C++ est une fonction qui renvoie void.
Alors comme ca il n'y a pas de procédures ??
mais si ;-)
SI c'est vrai, je lui en parlerai pour voir ... ca peut me rajouter des points au partiel ; MDRRRRRRRRRRRRR !! ;-)
la j'en doute ;-)
@+
Ah ouais ?!?!?! La prof nous a dit qu'il existait des fonctions ET des
procédures !!!
oui, elle a raison sur le principe algorithmique. Simplement C++ (et C) ne
font pas vraiment la différence. Une procédure C++ est une fonction qui
renvoie void.
Alors comme ca il n'y a pas de procédures ??
mais si ;-)
SI c'est vrai, je lui en parlerai pour voir ... ca peut me rajouter des
points au partiel ; MDRRRRRRRRRRRRR !! ;-)
Ah ouais ?!?!?! La prof nous a dit qu'il existait des fonctions ET des procédures !!!
oui, elle a raison sur le principe algorithmique. Simplement C++ (et C) ne font pas vraiment la différence. Une procédure C++ est une fonction qui renvoie void.
Alors comme ca il n'y a pas de procédures ??
mais si ;-)
SI c'est vrai, je lui en parlerai pour voir ... ca peut me rajouter des points au partiel ; MDRRRRRRRRRRRRR !! ;-)
la j'en doute ;-)
@+
Alexandre
Yep. Le partiel porte sur le cours de la prof en question, pas sur le C++ en général. Par conséquent, il faut employer les mêmes termes et méthodes qu'elle pendant le partiel, quitte à parler ici de ce qui peut apparaître comme un sujet totalement différent.
surtout que je trouverais louche de faire un cours de C++. Un cours de programmation objet, d'accord. Un cours d'algo, d'accord.
Il n'y a effectivement que des fonctions en C comme en C++. Mais il n'y a pas mort d'homme à décréter qu'une fonction renvoyant void correspond à la *notion* de procédure.
Mais de là à parler de sous-programmes... Je n'avais pas entendu le terme depuis le Basic.
en assembleur on dit aussi "sous-programme" ;-)
Quant au terme "procédure", il ne me fait pas trop tiquer, mais je n'aurais pas eu l'idée de l'employer.
question d'habitude ;-) Dans certains langages (pascal, ada par ex) la différence entre fonction et procédure n'est pas négligeable.
(Evite également de parler de méthode)
Sauf quand on parle de méthodes de programmation...
-- ;-)
Yep. Le partiel porte sur le cours de la prof en question, pas sur le
C++ en général. Par conséquent, il faut employer les mêmes termes et
méthodes qu'elle pendant le partiel, quitte à parler ici de ce qui
peut apparaître comme un sujet totalement différent.
surtout que je trouverais louche de faire un cours de C++. Un cours de
programmation objet, d'accord. Un cours d'algo, d'accord.
Il n'y a effectivement que des fonctions en C comme en C++. Mais il n'y
a pas mort d'homme à décréter qu'une fonction renvoyant void correspond
à la *notion* de procédure.
Mais de là à parler de sous-programmes...
Je n'avais pas entendu le terme depuis le Basic.
en assembleur on dit aussi "sous-programme" ;-)
Quant au terme "procédure", il ne me fait pas trop tiquer, mais je
n'aurais pas eu l'idée de l'employer.
question d'habitude ;-)
Dans certains langages (pascal, ada par ex) la différence entre fonction et
procédure n'est pas négligeable.
(Evite également de parler de méthode)
Sauf quand on parle de méthodes de programmation...
Yep. Le partiel porte sur le cours de la prof en question, pas sur le C++ en général. Par conséquent, il faut employer les mêmes termes et méthodes qu'elle pendant le partiel, quitte à parler ici de ce qui peut apparaître comme un sujet totalement différent.
surtout que je trouverais louche de faire un cours de C++. Un cours de programmation objet, d'accord. Un cours d'algo, d'accord.
Il n'y a effectivement que des fonctions en C comme en C++. Mais il n'y a pas mort d'homme à décréter qu'une fonction renvoyant void correspond à la *notion* de procédure.
Mais de là à parler de sous-programmes... Je n'avais pas entendu le terme depuis le Basic.
en assembleur on dit aussi "sous-programme" ;-)
Quant au terme "procédure", il ne me fait pas trop tiquer, mais je n'aurais pas eu l'idée de l'employer.
question d'habitude ;-) Dans certains langages (pascal, ada par ex) la différence entre fonction et procédure n'est pas négligeable.
(Evite également de parler de méthode)
Sauf quand on parle de méthodes de programmation...
-- ;-)
Alexandre
en fait le +
N'hésite pas à écrire "plus" en toutes lettres, ça ne coûte pas plus cher.
oui, désolé.
À part ça, ta solution ne me paraît pas répondre à la question, puisqu'elle présuppose qu'on connaît le type de la variable avant la saisie.
exact, elle dépend plutôt de type de variable dans lequel on range. J'ai lu trop vite :-( Alors dans ce cas, la seule solution serait de parser la chaine, et de vérifier si elle satisfait à certaines conditions. Avec une expression régulière par ex ?
-- ;-)
en fait le +
N'hésite pas à écrire "plus" en toutes lettres, ça ne coûte pas plus
cher.
oui, désolé.
À part ça, ta solution ne me paraît pas répondre à la question,
puisqu'elle présuppose qu'on connaît le type de la variable avant la
saisie.
exact, elle dépend plutôt de type de variable dans lequel on range.
J'ai lu trop vite :-(
Alors dans ce cas, la seule solution serait de parser la chaine, et de
vérifier si elle satisfait à certaines conditions.
Avec une expression régulière par ex ?
N'hésite pas à écrire "plus" en toutes lettres, ça ne coûte pas plus cher.
oui, désolé.
À part ça, ta solution ne me paraît pas répondre à la question, puisqu'elle présuppose qu'on connaît le type de la variable avant la saisie.
exact, elle dépend plutôt de type de variable dans lequel on range. J'ai lu trop vite :-( Alors dans ce cas, la seule solution serait de parser la chaine, et de vérifier si elle satisfait à certaines conditions. Avec une expression régulière par ex ?
-- ;-)
Alexandre
Merci beaucoup pour toutes ces explications !!!
En fait, tu as bien dit ce que je voudrais faire : analyser une chaîne pour voir qi elle ne contient que des chiffres ou non ... Et ensuite, faire une action s'il n'y a pas que des chiffres, une autre s'il n'y a que des chiffres ...
alors il faut écrire un parser pour la chaine. pour int c'est simple, par exemple : (encore que l'exemple ne vérifie pas que ça "tient" dans un int)
pour un float/double, il faut un petit automate car certains caractères sont possibles sous certaines conditions (le +/- au début, le . après des chiffres mais avec des chiffres après et un seul, etc...)
mais le principe est le même. Tu parcoures la chaîne, dès qu'elle ne satisfait pas à ta condition, c'est foutu, tu t'arretes. Tu devrais d'ailleurs assez facilement trouver une classe qui fait ce type de boulot (vérifier si une chaine correspond à un masque donné, en gros les expressions régulières), sinon... ben c'est un bon exercice à faire.
Merci beaucoup pour toutes ces explications !!!
En fait, tu as bien dit ce que je voudrais faire : analyser une chaîne
pour voir qi elle ne contient que des chiffres ou non ... Et ensuite,
faire une action s'il n'y a pas que des chiffres, une autre s'il n'y a que
des chiffres ...
alors il faut écrire un parser pour la chaine.
pour int c'est simple, par exemple : (encore que l'exemple ne vérifie pas
que ça "tient" dans un int)
pour un float/double, il faut un petit automate car certains caractères sont
possibles sous certaines conditions (le +/- au début, le . après des
chiffres mais avec des chiffres après et un seul, etc...)
mais le principe est le même. Tu parcoures la chaîne, dès qu'elle ne
satisfait pas à ta condition, c'est foutu, tu t'arretes.
Tu devrais d'ailleurs assez facilement trouver une classe qui fait ce type
de boulot (vérifier si une chaine correspond à un masque donné, en gros les
expressions régulières), sinon... ben c'est un bon exercice à faire.
En fait, tu as bien dit ce que je voudrais faire : analyser une chaîne pour voir qi elle ne contient que des chiffres ou non ... Et ensuite, faire une action s'il n'y a pas que des chiffres, une autre s'il n'y a que des chiffres ...
alors il faut écrire un parser pour la chaine. pour int c'est simple, par exemple : (encore que l'exemple ne vérifie pas que ça "tient" dans un int)
pour un float/double, il faut un petit automate car certains caractères sont possibles sous certaines conditions (le +/- au début, le . après des chiffres mais avec des chiffres après et un seul, etc...)
mais le principe est le même. Tu parcoures la chaîne, dès qu'elle ne satisfait pas à ta condition, c'est foutu, tu t'arretes. Tu devrais d'ailleurs assez facilement trouver une classe qui fait ce type de boulot (vérifier si une chaine correspond à un masque donné, en gros les expressions régulières), sinon... ben c'est un bon exercice à faire.
Fabien LE LEZ
On Tue, 22 Mar 2005 19:09:15 +0100, "Alexandre" :
il faut un petit automate car certains caractères sont possibles sous certaines conditions
(le +/- au début
C'est aussi valable pour un int.
-- ;-)
On Tue, 22 Mar 2005 19:09:15 +0100, "Alexandre"
<alex.g@netcourrier.com>:
il faut un petit automate car certains caractères sont
possibles sous certaines conditions
