Un opérateur == dont les paramètres sont des références non-const

Question

Je this post, je l'ai vu:

class MonitorObjectString: public MonitorObject { 
    // some other declarations 
    friend inline bool operator==(/*const*/ MonitorObjectString& lhs, 
            /*const*/ MonitorObjectString& rhs) 
    { return lhs.fVal==rhs.fVal; } 
} 

---

Avant de pouvoir continuer, CECI EST TRÈS IMPORTANT:

• Je suis ne remettant pas en question la capacité de tout le monde à coder.
• Je suis juste en me demandant pourquoi quelqu'un aurait besoin de références non const dans une comparaison.
• L'affiche de that questionn'a pas écrire ce code.

C'était juste au cas où. Ceci est également important:

• J'ai ajouté à la fois /*const*/ s et reformaté le code.

---

Maintenant, nous revenons au sujet:

Je ne peux pas penser à une utilisation saine de l'opérateur d'égalité qui vous permet de modifier ses arguments par-ref. Le faites vous?

Answer 1

Peut-être que les classes utilisent une forme d'initialisation paresseuse. Lorsque les données sont accédées, une initialisation correcte doit avoir lieu et les données doivent être récupérées. Cela peut changer les membres de la classe.

Cependant, l'initialisation paresseuse peut être formée de telle sorte que la modification de la classe n'est pas nécessaire. Cela peut être accompli en utilisant le Pimpl idiom (par un pointeur vers une classe privée) ou en utilisant le mutable keyword (non recommandé!).

Answer 2

Très probablement, ils ont oublié le const. opérateur surchargeant doit se comporter de manière cohérente et pas effectuer « de caractère » actions.

En règle générale, un opérateur d'égalité ne doit modifier aucun des objets qu'il compare. La déclaration const applique ceci au niveau du compilateur. Cependant, il est souvent oublié. "Const correcte" est très souvent négligé en C++.

Answer 3

Il n'y a clairement aucune exigence pour les arguments non const dans ce cas et, comme vous, je ne pense pas qu'il y ait de cas général pour cela non plus. Cependant, il est certain que les problèmes de const-correction peuvent se propager à partir des niveaux inférieurs du code, et si vous ne pouvez pas les corriger de bas en haut, vous devrez peut-être les contourner plus haut. Peut-être que c'est ce qui s'est passé ici à un moment donné?

Answer 4

Il y a un problème plus déconcertante avec la question que vous mettre en place.

Si j'ai deux MonitorObjectString s qui sont déjà const, je ne peux pas utiliser cette fonction d'égalité.

Answer 5

Si vous ne pouvez pas utiliser const car vous modifiez des opérandes, vous utilisez abusivement la surcharge de l'opérateur.

Si vous ne pouvez pas utiliser const car l'implémentation appelle des fonctions non const, vous devriez vraiment les nettoyer, ou au moins fournir des alternatives const. Si vous appelez du code, vous ne pouvez pas changer ce qui n'utilise pas const, j'utiliserais const quand même, j'utiliserais const_cast au point le plus profond disponible, et je le commenterais. Comme Shmoopty l'a fait remarquer, l'opérateur est beaucoup moins utile qu'il ne devrait l'être puisqu'il ne peut pas être utilisé sur les objets const, même si un seul d'entre eux est const. Un opérateur d'égalité numérique qui ne prendrait pas en charge «a == 5» enfreindrait la loi de la plus grande étonnement.