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