Discussion :

[LittleWhite]

Bonjour,

J'ai implémenté une classe encapsulant un std::vector et un mutex, car je souhaitait pouvoir utiliser cette classe à partir de différent thread.
Ayant besoin d'accéder à mon vector en lecture, j'ai fait les getters adéquat, à l'origine, une méthode constante. Mais à cause du mutex (un pthread_mutex_t), le compilateur me dispute de ne pas respecter mon "const".

La solution est soit :

• d'enlever le const, mais ça peut produire des effets néfastes dans le reste du code, utilisant mon encapsulation
• utiliser le mot clé mutable

Il m'a semblé judicieux d'utiliser mutable dans ce cas là, mais, toutefois ce mot clé me laisse un arrière gout amère. On indique que l'on a une méthode const, mais elle n'est pas totalement const car on utilise une variable que l'on modifie, mais c'est ok car c'est mutable

Je sais aussi que les spécifications const permettent aux compilateurs de faire des optimisations. Du coup, qu'est ce qui se passe du coté du compilateur, si j'utilise le mot clé mutable ? Vais-je perdre toutes les optimisations ? Quel est l'impact de ce mot clé ?

[Luc Hermitte]

L'impact est normalement le même que celui de const -> nul sur les performances (quand il s'agit de tagguer des variables comme immu(t)ables).
Pour les performances, c'est le mutex qui m’inquiéterait plus.

Sinon, c'est un cas classique d'application de mutable : les mutex.

[r0d]

Pour les performances, c'est le mutex qui m’inquiéterait plus.

+1.
Si les performances sont vraiment critiques, il ne faut rien utiliser de bloquant. Une méthode qui a fait ses preuves consiste à utiliser des callbacks (ou équivalent) via un observer (comme le principe de signal/slot de Qt par exemple).

[LittleWhite]

Ok, cela me rassure pour ce petit mot clé dont je ne connaissais pas encore l'utilisation.
Sinon, hors cas du mutex, le mot clé mutable a un effet sur les optimisations ?
De plus, quels sont les autres cas où vous avez eu besoin de mutable ?

[Trademark]

Dans le cas où recréer des variables locales comme std::vector de multiples fois est coûteux, je l'avais mis en membre mutable pour éviter les coûts de construction (gros gain de temps en récompense). Après je n'aime pas trop car, à mon avis, une fonction membre marquée "const" devrait pouvoir être appelée dans plusieurs threads sans risques.

[Iradrille]

Dans le cas où recréer des variables locales comme std::vector de multiples fois est coûteux, je l'avais mis en membre mutable pour éviter les coûts de construction (gros gain de temps en récompense). Après je n'aime pas trop car, à mon avis, une fonction membre marquée "const" devrait pouvoir être appelée dans plusieurs threads sans risques.

Une meilleure solution pourrait être d'utiliser un allocateur qui réserve la mémoire au lancement de l'application pour ce vecteur.

[Bousk]

Dans le cas où recréer des variables locales comme std::vector de multiples fois est coûteux, je l'avais mis en membre mutable pour éviter les coûts de construction (gros gain de temps en récompense). Après je n'aime pas trop car, à mon avis, une fonction membre marquée "const" devrait pouvoir être appelée dans plusieurs threads sans risques.

C'est un autre cas classique : le cache.
La notion de const n'est pas lié à l'accès concurrentiel. (bien qu'il le parraisse à première vue)

Je me trompe peut-être, mais const et mutable sont des notions qui interviennent lors de la compilation, donc l'impact sur les performances doit être quasi (totalement?) nul.

[Emmanuel Deloget]

Ok, cela me rassure pour ce petit mot clé dont je ne connaissais pas encore l'utilisation.
Sinon, hors cas du mutex, le mot clé mutable a un effet sur les optimisations ?

A ma connaissance, le mot-clef mutable n'a pas d'effet sur les optimisations, sauf peut-être dans des cas très, très particuliers.

De plus, quels sont les autres cas où vous avez eu besoin de mutable ?

Le cas du mutex (ou d'une autre primitive de synchronisation) est de très loin le plus courant. Je m'en suis servi de nombreuses fois. Je ne me rappelle pas avoir utilisé mutable dans d'autres cas, même si ma mémoire peut ici me faire défaut. On peut peut-être imaginer le cas d'un pointeur intelligent qui verrait son nombre de références augmenter (pas exemple sur operator=(const smart_ptr& p) : il faut augmenter le nombre de référence, hors celui-ci appartient aussi à p qui est const). En fait, il faut être dans un cas où une fonction qui est sémentiquement const a besoin de modifier une partie de l'état de l'objet. C'est quand même un cas très rare.