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

[senvedgi]

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

La réponse est là!!
J'accepte la condition a ou/et b et c'est tout.b n'étant pas obligatoirement l'inverse de a,b est une AUTRE réponse attentable(!).
Ou uniquement la condition a.
Si mon code trouve autre chose je m'en moque:c'est pourquoi je tourne 3 fois à droite pour aller à gauche et je ne risque pas de trouver un gus qui me coupe la route.

[Neckara]

Justement, tu fais :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
if(a || b)
{
 
}

Et tu veux faire autre chose si jamais la première condition n'est pas vérifier.
C'est beaucoup plus facile de faire un else et là tu seras sûr de ne pas te tromper.
Que d'essayer de trouver l'inverse précis :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
if(! (a || b) )
{
 
}
//ou
if( !a && !b)
{
 
}

C'est à ce moment là que tu pourras te tromper.

De plus, si tu n'utilises pas de else, je suppose que tu n'utilise pas de else if.
Dans certaines circonstances, remplacer des else if par uniquement des if peut devenir très compliqué...

Pour reprendre la métaphore de koala01, je dirais plutôt que tu préfère tourner 3 fois à gauche que de tourner une seule fois à droite.

else signifie tout simplement sinon.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
if(x || y && z )
       a = z;
else
       a = 0;

Qu'est-ce qui pourrait poser problème à mettre un else ?
Au contraire, tu as une garantie de ne pas te tromper.

Si jamais il y a un cas que tu n'as pas envisagé, c'est encore plus dangereux d'utiliser les if :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
int * ptr;
int c = getc(fichier);
if( '0' <= c && c <= '9')
       ptr = [c];
if('0' >= c || c >= '9')
       ptr = NULL;

Déjà c'est moins lisible.
Tu peux te tromper dans la rédaction de la 2ème condition et tu ne trouveras peut être pas forcément l'erreur au premier coup d’œil.
Et si jamais tu n'as pas envisagé une possibilité, ton pointeur ptr aura une valeur indéterminée et tu vas avoir un segfault qui ne sera pas toujours facile à trouver.

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

[oodini]

De plus, si tu n'utilises pas de else, je suppose que tu n'utilise pas de else if.
Dans certaines circonstances, remplacer des else if par uniquement des if peut devenir très compliqué...

Et surtout moins efficace : car même si le premier if est vérifié, tu te tapes tous les autres tests.

[koala01]

Et surtout moins efficace : car même si le premier if est vérifié, tu te tapes tous les autres tests.

... Et parfois même en double, car si tu teste A et que la condition n'est pas vérifiée, tu n'effectues peut etre pas ce qui est conditionné, mais tu as déjà fait le test.

Si, après, tu testes !A, tu refais le test et tu inverses le résultat...

tu te retrouves donc avec un test effectué deux fois là où un seul aurait suffit, bien que tu n'entres que dans un bloc d'instructions, en plus toutes les autres possibilités que tu peux vouloir vérifier.

Comprenons nous bien, il ne s'agit pas de prétendre qu'il faille toujours un else dés qu'il y a un if, car il est tout à fait possible qu'il n'y ait simplement rien à faire si la condition n'est pas vérifiée!

Mais il s'agit de dire que, s'il advient qu'il y ait quelque chose de cohérent à faire si une condition n'est pas vérifiée, il y a vraiment tout intérêt à le faire... dans le else de préférence à toute autre possibilité

[Invité]

et le retuuuuuuurn!

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
void f(){
 if(badCondition(x)) return
 //normal flow
 return
}

[koala01]

et le retuuuuuuurn!

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
void f(){
 if(badCondition(x)) return
 //normal flow
 return
}

A la condition expresse qu'il soit cohérent de sortir de la fonction, uniquement

D'autant plus que ce n'est pas forcément parce qu'une condition n'est pas remplie qu'il faut automatiquement considérer la fonction comme n'ayant rien à faire !

Tout en ayant correctement délégué les responsabilités, il n'est pas rare qu'une condition ne puisse "logiquement" être vérifiée qu'au milieu d'un flux d'exécution et que cette condition n'influe, en réalité, que sur une partie de ce flux d'exécution en prévoyant "simplement" un comportement alternatif en fonction de la condition.

Il n'est pas rare de voir des fonctions proches de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
void foo(/* params */)
{
    /* une partie du traitement */
    if( condition)
    {
        /* que faire si vrai */
    }
    else
    {
        /* que faire si faux */
    }
    /* reste du traitement */
}

sans qu'il ne soit opportun de déléguer l'une ou l'autre partie à une fonction tierce et sans contrevenir au principe de la responsabilité unique

Dis toi bien que le "que faire si la condition n'est pas respectée" a toujours existé, et que ce n'est pas un hasard : une condition non remplie n'est pas forcément une erreur ni un cas nécessitant de mettre fin prématurément à l'exécution d'une fonction.

C'est, très souvent, simplement, l'expression du besoin de faire réagir la fonction, pour une partie bien précise de son exécution, de manière différente en fonction du test effectué

[Invité]

Mais il s'agit de dire que, s'il advient qu'il y ait quelque chose de cohérent à faire si une condition n'est pas vérifiée, il y a vraiment tout intérêt à le faire... dans le else de préférence à toute autre possibilité

J'évitais simplement d'exclure un return prématuré qui peut permettre une meilleure lisibilité dans certains cas.

J'avouerais quand même le ptit coté trollesque du soir quand on voit l'encre versé sur cette question.