question sur les "if"

[fiatlux]

Bonjour,

J'ai une petite question:
Je code en Java mais j'imagine que c'est à peu près pareil pour tout langage de programmation: admettons que j'ai 2 conditions que je veux tester (typiquement variables booléennes qui sont soit true soit false), on est bien d'accord que ça revient au même d'écrire:

if(condition1 && condition2) {
//bla bla
}

ou

if(condition1) {
if(condition2) {
//bla bla
}
}

Mais ma question est la suivante: dans le 1er cas, si condition1==false, est-ce que le if est tout de suite abandonné ou bien est-ce qu'il évalue quand même condition2 et ensuite il se dit "false && true = false" (ou "false && false = false") ?

Merci d'avance
-----

[invite7863222222222]

L'opérateur && permet d'optimiser un peu les blocs d'instructions de test, car les seconds tests ne sont pas évalués si le premier est faux.

Même chose avec l'opérateur || (ou) :les seconds tests ne sont pas évalués si le premier est vrai.

Les opérateurs "simples" équivalents qui ne réalisent pas cette optimisation sont "&" et "|". En pratique on utilise presque tout le temps "&&" et "||" pour le "et" et le "ou" logique.

[invite7863222222222]

Annulé : commentaire erroné...

[bzh_nicolas]

L'opérateur && permet d'optimiser un peu les blocs d'instructions de test, car les seconds tests ne sont pas évalués si le premier est faux.

Attention, ça dépend du compilateur et ça n'a rien d'une règle absolue. Ca devrait être le cas mais ça ne l'est pas toujours.
En pratique, il vaut mieux éviter de compter la dessus dans un programme surtout si ça peut générer un plantage. De manière générale en testant la valeur ou en essayant d'accéder à une variable (ou à un membre d'une classe, etc...) qui n'est pas forcément initialisée (initialisation qui dépend d'une autre condition ou sujette à un échec possible).
Comme dans une conditionnelle du genre :
en C par exemple

int *nombre=NULL;

... //affectation possible du pointeur mais pas certaine
if ((nombre != NULL) && (*nombre < autre_nombre))
{
...
}

Si le compilateur est correctement programmé, ça doit s'arrêter au premier contrôle et ça passe. Mais il vaut mieux sécuriser en faisant :

int *nombre=NULL;

... //affectation possible du pointeur mais pas certaine
if (nombre != NULL)
{
  if (*nombre < autre_nombre)
  {
    ...
  }
}

[A voir en vidéo sur Futura]

[invite7863222222222]

Attention, ça dépend du compilateur et ça n'a rien d'une règle absolue.

Je parlais pour le langage JAVA, pour lequel il s'agit d'une règle absolue qui est définie au niveau des spécifications, et donc qui est respectée par tous les compilateurs dignes de ce nom. En JAVA donc, aucun souci, on utilise presqu'exclusiement && et ||, pour les autres langages : aucune idée.

[invite7863222222222]

bzh_nicolas, de plus j'ai pas compris ton exemple. Ce que j'en sais au niveau de JAVA, c'est que si toutes les conditions "et logique" du test "if" sont indépendantes, utiliser le "&&" permet des optimisations, mais ca ne change pas la logique et donc pas le résultat final. Il n'y a que lorsque des évaluations de conditions peuvent modifier l'évaluation d'autres conditions que ca peut poser problème.

Et je ne connaissais pas ce concept de "affectation possible du pointeur mais pas certaine".
Tu pourrais préciser ?

[fiatlux]

Merci à tous les deux pour votre réponse.
Donc si je résume, en Java, pas de souci. En C, ca dépend de la configuration du compilateur.

[invite765732342432]

En C, ca dépend de la configuration du compilateur.

A moins d'utiliser des options de compilation (ou des compilateurs) vraiment TRES exotiques, aucun risque non plus en C.

[bzh_nicolas]

bzh_nicolas, de plus j'ai pas compris ton exemple. Ce que j'en sais au niveau de JAVA, c'est que si toutes les conditions "et logique" du test "if" sont indépendantes, utiliser le "&&" permet des optimisations, mais ca ne change pas la logique et donc pas le résultat final. Il n'y a que lorsque des évaluations de conditions peuvent modifier l'évaluation d'autres conditions que ca peut poser problème.

Oui, je suis d'accord sur ça. D'ailleurs sur des conditions "simples" comme le cas de fiatlux (comparaison de booleen, etc...), ça ne pose aucun soucis.
En imaginant des objets plus complexes que des booleens, si tu fais quelque chose du genre :

si ((ma_classe.est_initialisée==vrai) && (ma_classe.méthode1 == vrai))

Tu prends quand même de gros risques (car si le compilo n'évalue pas dans le bon ordre et que l'initialisation de ta classe à ratée pour une raison x ou y...) à moins d'être sûr que le compilo respecte à 100% les spécifications du langage. Personnellement, et par expérience, je ne leur fait jamais à 100% confiance.

Et je ne connaissais pas ce concept de "affectation possible du pointeur mais pas certaine".
Tu pourrais préciser ?

Je vais te donner un exemple complet en C (que je maitrise mieux que java) mais le problème peut se poser aussi dans les autres langages.

#include <stdio.h>
int main ()
{
	int* nb; /*pointeur non initialisé (ce qui est une faute de programmation mais qu'on voit quand même régulièrement dans les codes) */
	int nb_saisi = 0;
  
	printf("taper un nombre\n");
	scanf("%d", &nb_saisi);
	if (nb_saisi==2)
	{
                /*si l'utilisateur ne tape pas 2 le pointeur ne subit pas d'affectation*/
		nb=&nb_saisi;
	}
	if((nb!=NULL) && (*nb==2))  /*il y a un problème ici car le pointeur peut n'être égal à rien, donc impossible de faire de comparaison, le programme plante*/
	{

		printf("c'est bon\n");
	}else{
		printf("c'est pas bon\n");
	}
}

En pratique il suffit de déclarer int* nb = NULL;
Le pointeur est alors initialisé ça évite le plantage du programme.

Concernant la question de fiatlux, je me souviens que le problème pouvait apparaitre dans les versions courantes de gcc de
1998-2000 (période de mes études où j'avais rencontré ce problème).
Il provenait justement d'optimisation du code par le compilo qui réorganisait parfois les conditions pour rendre le programme plus efficace. Mais c'est vrai que sur les machines actuelles avec les quantités de ram et la puissance de processeurs disponible, il n'y a plus forcément ce problème.

[invite7863222222222]

Oui, je suis d'accord sur ça. D'ailleurs sur des conditions "simples" comme le cas de fiatlux (comparaison de booleen, etc...), ça ne pose aucun soucis.

Pire que cela c'est conseillé d'avoir des conditions indépendantes, pour la clarté et la maintenabilité.

En imaginant des objets plus complexes que des booleens

Ce n'est pas du tout une histoire de manipuler des booleans ou pas car c'est toujours ce que tu manipules au final de toute facon.

, si tu fais quelque chose du genre :

si ((ma_classe.est_initialisée==vrai) && (ma_classe.méthode1 == vrai))

Tu prends quand même de gros risques (car si le compilo n'évalue pas dans le bon ordre et que l'initialisation de ta classe à ratée pour une raison x ou y...)

Non le principe de l'initialisation, c'est que si ta classe n'est pas initialisée alors tu ne peux pas accéder à rien dans cette classe même pas la méthode. Pour info l'initialisation d'une classe se fait de manière transparente pour toi, et est une condition préalable et indispensable à toute manipulation que tu pourrais faire sur elle. Donc impossible de la manipuler si l'initialisation a planté.
De plus, mais c'est plus pour ton information mais c'est une mauvaise pratique d'écrire du code d'initialisation de classe, en général ce genre de code doit être ultra simple pour pouvoir être sur qu'il ne plantera jamais.

à moins d'être sûr que le compilo respecte à 100% les spécifications du langage.

C'est sur qu'il respecte les spécifications, c'est le rôle des spécifications d'être respecté, pour un point aussi basique, ca serait absurde d'être paranoiaque.

Personnellement, et par expérience, je ne leur fait jamais à 100% confiance.

C'est une erreur, le point qui est soulevé est assuré à 200% et si il ne l'est pas tu peux être sur que des mecs ont déjà relevé le bug qui n'a pu se produire que dans une version beta du compilo, aux mecs qui ont fait le compilo et que c'est corrigé depuis longtemps dans les versions ultérieures.

Je vais te donner un exemple complet en C (que je maitrise mieux que java) mais le problème peut se poser aussi dans les autres langages.

#include <stdio.h>
int main ()
{
	int* nb; /*pointeur non initialisé (ce qui est une faute de programmation mais qu'on voit quand même régulièrement dans les codes) */
	int nb_saisi = 0;
  
	printf("taper un nombre\n");
	scanf("%d", &nb_saisi);
	if (nb_saisi==2)
	{
                /*si l'utilisateur ne tape pas 2 le pointeur ne subit pas d'affectation*/
		nb=&nb_saisi;
	}
	if((nb!=NULL) && (*nb==2))  /*il y a un problème ici car le pointeur peut n'être égal à rien, donc impossible de faire de comparaison, le programme plante*/
	{

		printf("c'est bon\n");
	}else{
		printf("c'est pas bon\n");
	}
}

En pratique il suffit de déclarer int* nb = NULL;
Le pointeur est alors initialisé ça évite le plantage du programme.

Je sais bien, mais ce point précis n'a pas de rapport direct avec la question de fiatlux.

Concernant la question de fiatlux, je me souviens que le problème pouvait apparaitre dans les versions courantes de gcc de
1998-2000 (période de mes études où j'avais rencontré ce problème).
Il provenait justement d'optimisation du code par le compilo qui réorganisait parfois les conditions pour rendre le programme plus efficace.

Oui parfois le compilateur réalise des optimisations internes c'est à dire qu'il va supprimer des choses évidentes.

Par exemple :

public static final int CONSTANTE = 2;

public void maMethode {

   if(CONSTANTE == 2){
       // System.out.println('.....');
   }
}

va être simplifié par le compilateur en

public static final int CONSTANTE = 2;

public void maMethode {
       // System.out.println('.....');
}

Mais c'est vrai que sur les machines actuelles avec les quantités de ram et la puissance de processeurs disponible, il n'y a plus forcément ce problème.

Ce n'est pas une question de RAM, les compilateurs réalisent toujours ce genre d'optimisations internes mais c'est dans 99% des cas d'utilisations, transparents pour toi, et tu n'as pas à t'en soucier.
Par exemple, en JAVA contrairement à ce que l'on pourrait croire le double null checking ne fonctionne pas justement à cause de réorganisation du compilateur justement si je me souviens bien, mais c'est uniquement lorsque tu essaies de faire des choses "touchy" (qu'il faut éviter) qu'on commence à se plonger dans ce genre de question, pas pour des cas d'utilisation tout simple. Dans l'exemple donné, par exemple, tu n'as pas à faire de double null checking car il y a l'instruction "synchronized" qui est faite pour cela.

Donc en conclusion, pour la question de fiatlux, tu peux juste te baser sur le respect des spécifications du langage, pas plus compliqué que cela.

[bzh_nicolas]

C'est sur qu'il respecte les spécifications, c'est le rôle des spécifications d'être respecté, pour un point aussi basique, ca serait absurde d'être paranoiaque.

C'est une erreur, le point qui est soulevé est assuré à 200% et si il ne l'est pas tu peux être sur que des mecs ont déjà relevé le bug qui n'a pu se produire que dans une version beta du compilo, aux mecs qui ont fait le compilo et que c'est corrigé depuis longtemps dans les versions ultérieures.

Je ne connais pas assez java pour pouvoir être affirmatif mais je sais qu'aucun compilateur C ne respecte à 100% les spécifications ni ANSI ni ISO même pour des trucs aussi basiques que la déclaration de la fonction main.
Normalement tu n'as que 2 déclarations normalisé :

int main(void)
{
  /*code*/
  return;
}

ou

int main(int argc, char *argv[])
{
  /*code*/
  return;
}

De même les fonctions ne prenant aucun paramètre devrait toujours avoir le mot clé void dans la liste des paramètres (dans la norme une fonction doit toujours être écrite sous la forme prototypée).
Pourtant aucun compilo ne te jetteras (en tout cas je ne l'ai jamais trouvé celui-là) si tu tapes :

void main()
{
/*code*/
}

Pourtant pas de forme prototypée ni de retour de int (normalement obligatoire dans la norme).
Mais la question de fiatlux concernait le java et là je suis hors sujet . Mais je ne serais pas étonné de retrouver le même style de "petits détails" sous java (et s'il y en a un, rien ne dit qu'il n'y en aura pas d'autre).

[invite7863222222222]

Je ne connais pas assez java pour pouvoir être affirmatif mais je sais qu'aucun compilateur C ne respecte à 100% les spécifications ni ANSI ni ISO même pour des trucs aussi basiques que la déclaration de la fonction main.

Oui, en java, ce n'est pas autant exotique qu'en C.


En JAVA, le compilateur te soulève une erreur lorsqu'il détecte qu'une variable n'est pas déclarée.
Par exemple

int j;
if(condition){
   j = 2;
}
j++;

ne compile pas, mais en revanche ceci :

int j;
j = 2;
j++;

compile.

Concernant la question présente : en C normalisé (ANSI) non plus, ce n'est pas une question de respect ou pas des spécifications, il s'agit uniquement de "est-ce que les spécifications ont prévu un comportement pour ce genre d'utilisation ?".

De manière générale, je suis persuadé qu'en C normalisé aussi, tu peux et tu dois toujours considérer que les compilateurs respectent les spécifications.

Mais la question de fiatlux concernait le java et là je suis hors sujet . Mais je ne serais pas étonné de retrouver le même style de "petits détails" sous java (et s'il y en a un, rien ne dit qu'il n'y en aura pas d'autre).

Ce n'est pas le problème, le JAVA c'est surtout une autre philosophie, la grande spécificité de JAVA comme le coté ANSI du C, c'est la portabilité, tous les compilateurs doivent donc respecter les spécifications, la durée de vie du compilateur qui ne respecte pas une règle si basique est proche de 0.
Je veux bien comprendre qu'en C (non ANSI) ce ne soit pas le cas, et que des vieux (mauvais ?) réflexes perdurent chez certains.

[Philou67]

Ce qu'il convient surtout de ne pas faire dans une condition de test, c'est une opération comme celle-ci :

if (condition && total++ < 2) {
  ...
}

l'effet de bord sur total étant potentiellement (presque toujours) conditionné par condition.

[jerrol]

La norme C (90 && 99) garantit que si la première opérande (ie la première condition) est fausse, la seconde n'est pas évaluée.

6.3.13 Logical AND operator

Syntax

logical-AND-expression:
...inclusive-OR-expression
...logical-AND-expression && inclusive-OR-expression

Constraints

Each of the operands shall have scalar type.

Semantics

The && operator shall yield 1 if both of its operands compare unequal rb 0 ; otherwise. it
yields 0. The result has type int.
Unlike the bitwise binary & operator, the && operator guarantees left-to-right evaluation ; there
is a sequence point after the evaluation of the first operand. If the first operand compares equal
to 0, the second operand is not evaluated.

	if((nb!=NULL) && (*nb==2))  /*il y a un problème ici car le pointeur peut n'être égal à rien, donc impossible de faire de comparaison, le programme plante*/

Un pointeur (comme n'importe quel objet) ne peut jamais être égal à "rien", il a toujours une valeur. Même si le pointeur n'est pas initialisé, cela n'empêchera donc pas le "if" d'évaluer sa première condition (simplement, il comparera "nb" avec une valeur bidon), et la seconde ensuite si la première est vraie (qui a du coup toutes les chances de provoquer un crash, en effet).
Après, si on mets des options d'optimisation, chaque compilateur fait sa propre sauce en analysant le code comme il le peut (déductions, etc). Je suppose que ça passe ou ça casse, ce qui ne remet pas en cause le fait que le programme en question comporte un bug (qu'il faut corriger quoi qu'il arrive).

[bzh_nicolas]

Un pointeur (comme n'importe quel objet) ne peut jamais être égal à "rien", il a toujours une valeur. Même si le pointeur n'est pas initialisé, cela n'empêchera donc pas le "if" d'évaluer sa première condition (simplement, il comparera "nb" avec une valeur bidon), et la seconde ensuite si la première est vraie (qui a du coup toutes les chances de provoquer un crash, en effet).
Après, si on mets des options d'optimisation, chaque compilateur fait sa propre sauce en analysant le code comme il le peut (déductions, etc). Je suppose que ça passe ou ça casse, ce qui ne remet pas en cause le fait que le programme en question comporte un bug (qu'il faut corriger quoi qu'il arrive).

"égal à rien" est un abus de langage, mais un pointeur en C non-initialisé n'est pas équivalent à un pointeur initialisé à NULL.
NULL n'étant pas rien. Essaye le bout de code que j'ai mis dans un de mes messages précédents en tapant une fois 2 et une fois un autre chiffre ensuite modifie le code et déclare le pointeur ainsi : int* nb = NULL;
recompile et refais les mêmes opérations et tu verras (tester sous VS 2010, j'ai pas eut le courage de tester avec d'autre compilateur).

[invite7863222222222]

"égal à rien" est un abus de langage

qu'il faut éviter car "égal à rien" peut être compris comme être "égal à null" même si on sait que null est une valeur en soit. Surtout qu'il n'y a aucune raison pour dire "non initialisé", ce qui ce traduit par le fait qu'il a une valeur indéterminée qui peut provoquer des erreurs et cette non initialisation constitue un bug.

[jerrol]

"égal à rien" est un abus de langage, mais un pointeur en C non-initialisé n'est pas équivalent à un pointeur initialisé à NULL.
NULL n'étant pas rien. Essaye le bout de code que j'ai mis dans un de mes messages précédents en tapant une fois 2 et une fois un autre chiffre ensuite modifie le code et déclare le pointeur ainsi : int* nb = NULL;
recompile et refais les mêmes opérations et tu verras (tester sous VS 2010, j'ai pas eut le courage de tester avec d'autre compilateur).

Oui, je ne dis pas le contraire.

Simplement, dans le commentaire, tu disais :

/*il y a un problème ici car le pointeur peut n'être égal à rien, donc impossible de faire de comparaison, le programme plante*/

Dans la manière que cette phrase est écrite, j'ai pensé que tu voulais dire que, vu que le pointeur n'est pas initialisé, "nb" n'est égal à "rien" ("rien" dans le sens "n'a aucune valeur") et qu'à cause du fait qu'il n'a "aucune valeur" le if ne peut donc pas faire une comparaison.
Je disais simplement que, quelle que soit la valeur de "nb" (NULL ou autre, pointeur valide ou non), le test sera quand même effectué par le "if". On ne peut donc pas dire que "il est impossible de faire une comparaison". D'autant que l'évaluation des && se fait de gauche à droite et lorsqu'une condition est à 0 le reste n'est pas évalué (cf l'extrait de la norme C90/99), ce qui implique que les conditions doivent toujours être en mesure d'être testées.

Mais je pense qu'on veut dire la même chose mais pas avec les bons termes. J'ai sans doute mal compris ta phrase entre /* et */.

[bzh_nicolas]

Oui, je ne dis pas le contraire.
[...]
Mais je pense qu'on veut dire la même chose mais pas avec les bons termes. J'ai sans doute mal compris ta phrase entre /* et */.

En me relisant, c'est vrai que ma phrase est mal formulée.
Et je pense en effet qu'on veut dire la même chose.
J'aurais plutôt dû tourner ma phrase comme ça :
/*il y a un problème ici car le pointeur peut pointer n'importe où : le programme peut planter lors de l'accès au pointeur dans la comparaison*/

[invite7863222222222]

le pointeur est "pas initialisé", c'est pas compliqué.

[Philou67]

Surtout qu'il n'y a aucune raison pour dire "non initialisé", ce qui ce traduit par le fait qu'il a une valeur indéterminée qui peut provoquer des erreurs et cette non initialisation constitue un bug.

Il existe des langages pour lesquels cette indétermination n'existe pas : il existe une valeur pour cette valeur indéfinie, et cette valeur peut être vérifiée (perl avec la valeur undef par exemple).
Ceci n'empêche pas que de nombreux opérateur provoquent une erreur d'exécution lorsqu'une valeur est undef (et provoque donc un bug).

[invite7863222222222]

Il existe des langages pour lesquels cette indétermination n'existe pas : il existe une valeur pour cette valeur indéfinie, et cette valeur peut être vérifiée (perl avec la valeur undef par exemple).

Il faut de toute facon toujours considéré qu'il y a des spécificités dans chaque langage, ma remarque est donc propre au C.

Ceci n'empêche pas que de nombreux opérateur provoquent une erreur d'exécution lorsqu'une valeur est undef (et provoque donc un bug).

C'est un petit mieux, mais pas bcp. Personnellement, je trouve que la solution de JAVA d'empêcher que ce cas se produise (sans undef et avec des erreurs de compilations lorsqu'il détecte un "risque") est la meilleure.

[Philou67]

En fait, cette méthode utilisant une valeur pour des valeurs non déterminée est parfois utile pour différencier une valeur nulle initialisée et une valeur non initialisée, dans certaines boucles.

my $saisie;
while (defined($saisie) && $saisie =~ /^\d+/) {
  if (!defined($saisie)) {
    print "Entrer un nombre, svp: \n";
  }
  else {
    print "Mauvaise valeur : veuillez entrer un nombre:\n";
  }
  $saisie = <STDIN>;
}

Mais je suis d'accord, l'usage des valeurs indéfinies est risquée, et doit être évitée.