Discussion :

[koala01]

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 :

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

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 :

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

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

[Médinoc]

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 :

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

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

Code :

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

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

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

[ternel]

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.

[koala01]

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"

[ternel]

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

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

[germinolegrand]

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

Code :

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

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

[ternel]

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

Code :

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

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;
};

[koala01]

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

[ternel]

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

[koala01]

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

[germinolegrand]

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.

[ternel]

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

[Bousk]

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

[germinolegrand]

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