Discussion :

[Agoudard]

Bonjour,

Est-il judicieux d'utiliser le mot clé mutable dans les conditions ci-dessous ?

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
 
class Vect2D{
public:
 
...
 
float getLength() const{
        if(!m_length_computed)
        {
            m_length_computed = true;
            return m_length = sqrt(pow(m_x, 2) + pow(m_y, 2));
        }
        else{
            return m_length;
        }
}
 
...
 
private:
    float m_x, m_y;
    mutable T m_length;
 
    mutable bool m_length_computed;
}

Dans ce cas je cherche à éviter le calcul de la longueur lorsque cela est possible. Mais je voudrais aussi garder le caractère constant de la méthode qui calcule la longueur (puisque sémantiquement elle ne modifie rien dans l'objet)

[jblecanard]

Par défaut, j'ai tendance à me méfier de mutable, mais ton exemple me semble pertinent, j'ai envie de dire oui.

La question devient : peux-ton faire cela proprement sans utiliser mutable ?

[Jean-Marc.Bourguet]

Le cache (et c'est ce que tu as ici), c'est l'exemple paradigmatique de l'utilite de mutable. Donc pas de probleme pour moi sur le principe.

Dans le cas particulier, je ne suis pas sur que ce soit un gain de cacher la longueur (tu augmentes la taille de l'objet et donc la pression sur les caches, au final tu peux perdre) et de le faire de facon paresseuse (tu augmentes encore la pression sur les caches et tu vas passer du temps a verifier si le calcul est deja fait). Mais c'est le genre de chose qui sont tres specifique au contexte. Donc mesure.

(Par contre utiliser mx*mx plutot que pow(mx, 2) ne fera jamais de mal).

[screetch]

c'est le cas le plus pertinent de "mutable", un cache qui n'influence pas la const-correctness "logique" de l'objet.
[EDIT] devancé par jean marc... :p

[Agoudard]

Dans le cas particulier, je ne suis pas sur que ce soit un gain de cacher la longueur (tu augmentes la taille de l'objet et donc la pression sur les caches, au final tu peux perdre) et de le faire de facon paresseuse (tu augmentes encore la pression sur les caches et tu vas passer du temps a verifier si le calcul est deja fait). Mais c'est le genre de chose qui sont tres specifique au contexte. Donc mesure.

Pas compris...

[JolyLoic]

Je vais tenter de reformuler ce qu'a dit Jean-Marc : Tu gagnes certes en temps de calcul de précalculer ça, mais ton objet devient plus gros (et de manière non négligeable), ce qui au final peut te faire perdre plus que ce que tu gagnes.

Donc, comme toute optimisation, mais plus encore ici : Mesurer, mesurer, et mesurer.

[Jean-Marc.Bourguet]

Je me demande si la double utilisation de cache:
* la technique générale qui consiste à garder une copie (de quelque chose de long à retrouver, que ce soit par calcul ou à cause des temps d'accès) appliquée dans son cas au calcul de la norme
* le cache du processeur (qui est une autre utilisation de la technique)
n'est pas à la source de la confusion.

(En passant, un technique possible si tu refais le calcul à chaque fois consiste à ne pas faire le calcul de la racine carrée. Ca suffit souvent.)

[Emmanuel Deloget]

Pour le coup, et quitte a cacher le résultat, j'aurais fait le calcul de la longueur sur les changements de xyz - et pas sur la requête elle même. Les changements sont rares, et certains provoquent un changement trivial de la longueur (voire pas de changement du tout pour certaines transformations - rotation, symétrie...). Du coup, le calcul est moins perceptible.

Personnellement, je l'utilise pas mutable de cette manière. Mais c'est une utilisation sensée.

[Agoudard]

Merci, c'est compris

[Médinoc]

Pour un simple calcul flottant, je pense que l'utilisation d'un cache est superflue.
Pour un parcours sur une liste par contre (en clair: N'importe quoi qui ne se fasse pas en temps constant O(1)), ça peut être utile.

Personnellement, j'utilise mutable dans deux cas: Les caches et les comptages de références "intrusifs".