Ordre d'évaluation des conditions dans un if

Citation:

---

Envoyé par bretus

Bonsoir,

Je met mon grain de sel, mais c'est un principe d'évaluation des "AND" assez répandu non? (Short Circuit Evaluation)

Dans ( expression booléenne A ) && ( expression booléenne B ), ( expression booléenne B ) n'est évaluée que si ( expression booléenne A ) est vraie?

C'est pas garanti par la norme ça, car optimisation activée ou non, le code suivant à le même comportement :

---

Si c'est garanti par la norme.

C'est ce qui t'assure de ne pas te manger une erreur de segmentation avec un code proche de

Code:

---

1 2 3 4

while( pointer!=nullptr && pointer->next = nullptr){ pointer = pointer->next; /*... */ }

---

Si ce n'était pas garanti au niveau de la norme, tu devrais écrire un code proche de

Code:

---

1 2 3 4 5 6

while(pointer != nullptr){ if(pointer->next != nullptr-{ pointer = pointer->next; /* ... */ } }

---

pour ne pas risquer de te manger une erreur de segmentation ;)

Citation:

---

Envoyé par Neckara

Je ne suis pas tout à fait d'accord, c'est un raccourcit trop facile.

& n'est pas un "AND non-optimisé", c'est un ET bit à bit alors que AND travaille sur les valeurs des opérandes converties en valeurs booléennes en effet :

0x000101 & 0x100000 = 0x000000 = false
0x000101 && 0x100000 = true && true = true

---

Le & bit-à-bit, appliqué sur des "vrais" Booléens (comme les retours d'opérateurs de comparaison) correspond bel et bien à un AND non-optimisé. Mais ça nécessite une vraie comparaison, donc ces deux codes auront des comportements différents:

Code:

---

1 2	if(ptr & a++ == 42) //Mauvais (résultat du test varie selon valeur de ptr) cout << "blabla" << endl;

---

Code:

---

1 2	if(ptr!=0 & a++ == 42) //Bon cout << "blabla" << endl;

---

Mais dans les deux cas, a++ == 42 sera évalué.

A ma connaissance, les seuls opérateurs concernés par l'évaluation paresseuses sont le ternaire ?: et les opérateurs logiques && et ||.

Je crois me souvenir, mais cela demande confirmation, que ca n'est plus vrai une fois qu'ils ne sont pas redéfinis.

Citation:

---

Envoyé par leternel

Je crois me souvenir, mais cela demande confirmation, que ca n'est plus vrai une fois qu'ils ne sont pas redéfinis.

---

En fait, il est impossible de redéfinir les opérateur logiques && , || et ? : .

On peut redéfinir les opérateurs logiques binaires, &, |, ^, ~ et leur composé d'affectation, mais pas les versions "optimisée" ;)

Pour le ternaire, je savais, mais je croyais que les seuls impossibles était:

• les opérateurs de types: sizeof, typeid, alignof, truc_cast<T>
• les opérateurs de nom: les accesseurs de membres (. et .*) et la portée (::)
• le ternaire (?:)
• l'adressage (& unaire)
• noexcept

Citation:

---

Operator Overloading
Syntax
type operator op ( params ) ;
Explanation
<type> is/are the type(s) of the variables.
<op> is the particular operator (e.g. +, +=, <<, >>, &&, ||, %, etc.).
<params> is/are the name(s) of the required parameters (depends on the operator).

Restrictions
You cannot create new operators such as ** or &|.
Not all operators can be overloaded
Some operators can only be overloaded as non-static class members
Short-circuit evaluation doesn't work with overloaded operators

---

source: cppreference.com

Donc on peut bien les redéfinir, ils perdent simplement leur propriété de court-circuit :).

Code:

---

bool operator&&(<T> const& a, <S> const& b)

---

Effectivement, c'est bien ce que j'ai vérifié.
Ce brave g++ n'a pas rallé pour un code tel que:

Code:

---

1 2 3 4 5 6 7 8 9 10 11

class Boolean { bool value; public: Boolean(bool b):value(b){} Boolean operator&&(Boolean const&) const; Boolean operator||(Boolean const&) const; Boolean& operator|=(Boolean const&); Boolean operator|(Boolean const&) const; Boolean operator!() const; };

---

Citation:

---

Envoyé par leternel

Pour le ternaire, je savais, mais je croyais que les seuls impossibles était:

• les opérateurs de nom: l'accesseur (.) et la portée (:: )

---

La portée, ca semble logique, mais l'accesseur... je ne sais plus vraiment.

Je sais que l'on peut redéfinir l'opérateur de déréférencement, ( * ) et l'accesseur depuis un pointeur ( -> ) car c'est ce que font les itérateurs.

Pour l'accesseur "simple", je suis pris d'un doute ;)

Je suis très sûr pour celui-là.
On ne peut pas, "parce que" tu ne pourrais pas spécifier les arguments de la fonction. l'operateur attendent certes une variables à gauche, mais un identifieur lexical à droite (un nom de membre, pour être précis).

La raison est que le variable->membre est implémenté par récurrence:
si variable est un pointeur, retourner (*variable).membre.
si variable est n'importe-quoi d'autre, retourner (variable.operator->())->membre


En fait, j'en ai omis un autre, le déréférencement de pointeur membre ".*" (je ne suis sur ni du nom, ni de l'usage)

Les cinq que j'ai appris sont ?:, ., .*, sizeof et ::.

Citation:

---

Envoyé par leternel

Je suis très sûr pour celui-là.
On ne peut pas, "parce que" tu ne pourrais pas spécifier les arguments de la fonction. l'operateur attendent certes une variables à gauche, mais un identifieur lexical à droite (un nom de membre, pour être précis).

La raison est que le variable->membre est implémenté par récurrence:
si variable est un pointeur, retourner (*variable).membre.
si variable est n'importe-quoi d'autre, retourner (variable.operator->())->membre


En fait, j'en ai omis un autre, le déréférencement de pointeur membre ".*" (je ne suis sur ni du nom, ni de l'usage)

Les cinq que j'ai appris sont ?:, ., .*, sizeof et ::.

---

en fait, maintenant que tu le dis, c'est logique :D

L'accesseur simple n'est pas redéfinissable.

Les seuls opérateurs non surchargeables sont les suivants :
Adressage : x.y
Adressage d'un pointeur sur membre : x.*y
Ternaire : x ? y : z
Résolution de portée : x::y
Résolution de portée pour les pointeurs sur membre : x::*y
Taille : sizeof(x)
Identification de type : typeid(x)

Tous les autres sont parfaitement candidats à la surcharge.

As-tu essayé de surcharger dynamic_cast<Tau>, où Tau serait une classe de ton goût? ou l'adressage d'une variable quelconque?

Je vous renvoie (comme d'habitude) le lien habituel qui parle des opérateurs, leur précédence et surcharge.

erf, j'avais zappé les cast C++ et les opérateurs C++11...