Tester type variable entrée

[...]

en assembleur on dit aussi "sous-programme" ;-)
Le vocabulaire importe peu, et surtout en assembleur. Je vois qu'en

Fortran, on différencie "sous-programmes" et deux types de "fonctions"
sous le terme globale de "procédures".
En assembleur (MASM), le terme générique serait plutôt procédure. Mais
en fait c'est libre. On va utiliser les macros fournies, ou en écrire de
nouvelles avec du code de prologue et d'épilogue, pour choisir un
contexte de convention d'appel. En autonomie, on peut même être créatif.
On va également utiliser des bibliothèques qui imposent leurs
conventions et en quelque sorte leur vocabulaire, souvent celui du C.
--
Pierre

Pierre Maurette wrote:

(Evite également de parler de méthode)

Et pourtant, j'en parle tout le temps. J'insiste, par exemple,
sur l'importance de faire la conception avec méthode, de faire
les tests avec méthode, de faire ...

En fait, une bonne méthode, c'est essentiel si tu veux faire
l'informatique.

--
James Kanze mailto: james.kanze@free.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34

Fabien LE LEZ wrote:

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

(le +/- au début

C'est aussi valable pour un int.

Au moins qu'on l'interdise. Les constantes numérique du langage
C++ (entier ou flottant) ne permettent pas une signe au début.
(Ce qui pose certains problèmes sur des machines à complément à
deux.)

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Alexandre wrote:

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.

Pourquoi faire simple quand on peut faire compliqué, n'est pas.

pour int c'est simple, par exemple : (encore que l'exemple ne
vérifie pas

que ça "tient" dans un int)

bool IsInt(const std::string& str)
{
bool bIsInt=true;
bool bFinParse = (str.length()==0);
int iPos=0;
while(!bFinParse)
{
if(iPos>=str.length())
bFinParse=true;
else if(!isdigit(str[i])
{
bFinParse=true;
bIsInt=false;
}
else
++i;
return bIsInt;
}

D'abord, évidemment, rien ne prouve que ça « tient » dans un
int. Il acceptera 1000000000000000, par exemple, qui ne tient
pas dans un int chez moi. Mais surtout :

-- l'opérateur >> est obligé à faire ce travail déjà ; ce n'est
pas la peine de le faire une deuxième fois si on veut
appeler opérateur >> par la suite, et

-- j'aurais écrit la même chose dans beaucoup moins de lignes :

static const boost::regex entier( "^s*[+-]?d+s*$" ) ;
return regex_match( str, entier ) ;

En général, ça ne vaut pas la peine d'écrire un parseur pour des
choses aussi simple.

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...)

static const boost::regex flottant(
"^s*[+-]?("
"d+.d*|"
".d+([Ee][+-]?d+)?|"
"d+(.d*)?[Ee][+-]?d+"
")s*$" ) ;
return regex_match( str, flottant ) ;

Effectivement, un peu plus compliqué, mais une fois qu'on a
maîtrisé la technique...

mais le principe est le même.

Exactement.

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.

On trouve des expressions régulières chez Boost ; je crois même
que cette partie de Boost est en considération pour devenir
partie de la norme.

En revanche, une implémentation des expressions régulières est
bien un bon exercise, mais pour quelqu'un qui a déjà une
certaine expérience.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On 23 Mar 2005 03:26:06 -0800, kanze@gabi-soft.fr:

entier( "^s*[+-]?d+s*$" ) ;

Ça me paraît bizarre comme expression (mais je ne connais pas la
version Boost des regex). C'est pas plutôt "^\s*[+-]?\d+\s*$" ?


--
;-)

Bon ben merci à tous pour ces points de vocabulaire !!

@+

Bonjour,

Au lieu d'utiliser toutes ces méthodes peut-être très efficaces, mais pas
simples à comprendre pour moi, est-ce qu'on ne peut pas utiliser tout
simplement !cin ????

Merci !!

@+

-- j'aurais écrit la même chose dans beaucoup moins de lignes :

static const boost::regex entier( "^s*[+-]?d+s*$" ) ;
return regex_match( str, entier ) ;

En général, ça ne vaut pas la peine d'écrire un parseur pour des
choses aussi simple.

et regex, ce n'est pas (en quelque sorte) un parseur ? ;-)

On trouve des expressions régulières chez Boost ; je crois même
que cette partie de Boost est en considération pour devenir
partie de la norme.

ce qui serait une bonne chose.

En revanche, une implémentation des expressions régulières est
bien un bon exercise, mais pour quelqu'un qui a déjà une
certaine expérience.

c'est vrai, je l'ai fait faire une fois à des étudiants, et bien ils ont
vraiment ramé. ;-)

Rudy wrote:

Au lieu d'utiliser toutes ces méthodes peut-être très
efficaces, mais pas simples à comprendre pour moi, est-ce
qu'on ne peut pas utiliser tout simplement !cin ????

Dans la pratique, pas directement. Mais si on connaît cin, on
connaît les flux, et Ivan et moi avons tous les deux proposé des
solutions à base des flux.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Dans la pratique, pas directement. Mais si on connaît cin, on
connaît les flux, et Ivan et moi avons tous les deux proposé des
solutions à base des flux.

Oui, mais je ne connais pa du tout les syntaxes que vous m'avez proposé.
Alors que if(!cin), je connais très bien ... lol

Donc si vous conniassez une solution qui utilise des boucles simples, je
préfèrerai vraiment : je serai totalement incapable d'expliquer le reste !

Notamment "^s*[+-]?d+s*$" ; pour moi c'est un truc qu'on a écrit et qu'il
faut après remplacer par ce qu'on veut ! MDRRR !

Merci !

@+