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.