Discussion :

[senvedgi]

Bonjour � tous,
J'appelle cette �criture une entr�e implicite.
Une variable fixe propose un code depdep="abc";
Si on fait entr�e sur dep on accepte implicitement la proposition.
Si on n'accepte pas dep on entre autre chose,
mais je n'arrive pas � trouver en C++ comment tester string dep "vide".

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
 
string dep;
string qqchose;
string depdep="abc";
cout<<dep;cin>>dep;
if (dep == 0) {qqchose = depdep;}
if (dep != 0) {qqchose = dep;}
cout<<qqchose<<endl;

J'ai recherch� mais rien ne colle.
Merci par avance.
cin.sync()????

[Neckara]

Bonjour,
Il me semble qu'il faut faire ceci :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
string qqchose;
string depdep="abc";
cout<<dep;
cin>>dep;
if (dep != "")
       qqchose = depdep;
else 
       qqchose = dep;
cout<<qqchose<<endl;

[senvedgi]

Bonjour,
Merci pour cette r�ponse.
Mais dep n'est pas d�fini je l'ai oubli�:c'�tait un code de principe!
Je n'aime pas else car les programmes d�couvrent toujours une autre r�ponse
Je pr�f�re d�crire chaque cas positivement.

M�me avec string dep; que j'ai rajout�,
la modif avec else ne marche pas.
"cin>>dep" contient quoi qu'il faut tester si dep="<E>"?

[Neckara]

Le probl�me vient de l'op�rateur >>.

Pour ce que tu veux faire, il faut :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
string qqchose;
string depdep="abc";
cout<<dep;
getline(cin, dep);
if (dep != "")
       qqchose = depdep;
else 
       qqchose = dep;
cout<<qqchose<<endl;

Sinon, je ne comprend pas ce que tu voulais dire :

Je n'aime pas else car les programmes d�couvrent toujours une autre r�ponse

[senvedgi]

Cette fois �� marche...

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
 
string dep;//oubli de cette ligne
string qqchose;
string depdep="abc";
cout<<dep;
getline(cin, dep);////////////tout est là!
if (dep != "")
       qqchose = dep;//au lieu de depdep
else 
       qqchose = depdep;//depdep au lieu de dep
cout<<qqchose<<endl;

...apr�s correction de 3 erreurs de ma part.
Accepter une valeur:if(....) pour obtenir un r�sultat {::::} c'est �tre s�r de la cha�ne de code.
Accepter une autre:idem.
Mais mettre un else c'est accepter toutes sortes de r�sultats coh�rents ou incoh�rents car les codes ne sont jamais parfaits et les machines savent toujours trouver le petit/gros bug.
C'est pourquoi je n'utilise jamais de else:c'est mon style..!!..
Donc MERCI beaucoup.

[koala01]

salut,

C'est pourquoi je n'utilise jamais de else:c'est mon style..!!..
Donc MERCI beaucoup.

Te rends tu compte que cela revient quasiment au m�me que de dire que tu ne tournes jamais � gauche, sous un pr�texte quelconque

Dans 90 % des cas, tu pourras peut etre effectivement tourner 3 fois � droite pour arriver au m�me r�sultat, mais il y a des fois o� cela te fera faire un s�rieux d�tour pour arriver � destination

Le else n'est pas obligatoire s'il n'y a rien � faire lorsque la condition n'est pas remplie ou si tu d�cide de quitter la fonction si la condition est remplie, mais il faut avouer qu'il y a des situations dans lesquelles ca sert quand m�me beaucoup, m�me s'il est toujours possible de s'en passer, apr�s ton premier if v�rifiant une condition donn�e, d'obtenir un r�sultat �quivalent en mettant un deuxi�me if v�rifier la condition inverse.

Le probl�me �tant alors qu'il est parfois difficile de trouver l'inverse pr�cis de la condition pr�c�dente

[Bousk]

Mais mettre un else c'est accepter toutes sortes de r�sultats coh�rents ou incoh�rents car les codes ne sont jamais parfaits et les machines savent toujours trouver le petit/gros bug.
C'est pourquoi je n'utilise jamais de else:c'est mon style..!!..

Non �crire un else c'est �tre conscient que le if peut �chouer et avoir une action � faire en cas d'�chec de ce premier test.
Quant au fait qu'une machine soit capable de se tromper dans un binaire... on peut ais�ment imputer 99.99999% des "bugs machines" � l'utilisateur avant que la machine te retourne true quand elle rencontre un 0.
Sans compter que qui dit 2 tests, dit double source d'erreur
- si la condition a un effet de bord
- si la premi�re condition est vraie, il r�alise quand m�me la 2� (qui est pourtant fausse)
- � l'inverse, si la 1� est fausse, il doit quand m�me r�aliser le test pour �tre sur que la 2� est vraie
- si la 2� est mal �crite (voir les exemples ci-dessus, c'est parfois tr�s simple), tu peux y rentrer et c'est alors tout le programme qui peut �tre faux
et un test c'est pas toujours if (i == 2), �a peut impliquer un algo plus ou moins lourd derri�re.

Avoir un style c'est bien, mais qu'il soit justifi� c'est mieux.