Surcharge des opérateurs: fonction membre vs fonction non membre?

J'ai lu qu'un opérateur surchargé déclaré comme fonction membre est asymétrique car il ne peut avoir qu'un seul paramètre et l'autre paramètre passé automatiquement est le thispointeur. Il n'existe donc aucune norme pour les comparer. D'autre part, l'opérateur surchargé déclaré comme a friendest symétrique car nous passons deux arguments du même type et par conséquent, ils peuvent être comparés.

Ma question est la suivante: lorsque je peux encore comparer la valeur d'un pointeur à une référence, pourquoi les amis sont-ils préférés? (l'utilisation d'une version asymétrique donne les mêmes résultats qu'une version symétrique) Pourquoi les algorithmes STL n'utilisent-ils que des versions symétriques?

Si vous définissez votre fonction surchargée d'opérateur en tant que fonction membre, le compilateur traduit des expressions comme s1 + s2en s1.operator+(s2). Cela signifie que la fonction membre surchargée par l'opérateur est appelée sur le premier opérande. C'est ainsi que fonctionnent les fonctions membres!

Mais que faire si le premier opérande n'est pas une classe? Il y a un problème majeur si nous voulons surcharger un opérateur où le premier opérande n'est pas un type de classe, disons plutôt double. Vous ne pouvez donc pas écrire comme ça 10.0 + s2. Cependant, vous pouvez écrire une fonction membre surchargée d'opérateur pour des expressions telles que s1 + 10.0.

Pour résoudre ce problème d' ordre , nous définissons la fonction surchargée d'opérateur comme friendSI elle a besoin d'accéder aux privatemembres. Faites-le friendUNIQUEMENT lorsqu'il a besoin d'accéder aux membres privés. Sinon, faites simplement en sorte que ce soit une fonction non-membre ami pour améliorer l' encapsulation!

class Sample
{
 public:
    Sample operator + (const Sample& op2); //works with s1 + s2
    Sample operator + (double op2); //works with s1 + 10.0

   //Make it `friend` only when it needs to access private members. 
   //Otherwise simply make it **non-friend non-member** function.
    friend Sample operator + (double op1, const Sample& op2); //works with 10.0 + s2
}

Lisez ceci:
Un léger problème d'ordre dans les opérandes
Comment les fonctions non membres améliorent l'encapsulation

Ce n'est pas nécessairement une distinction entre friendles surcharges d'opérateurs et les surcharges d'opérateurs de fonctions membres, comme c'est le cas entre les surcharges d'opérateurs globaux et les surcharges d'opérateurs de fonctions membres.

Une raison de préférer une surcharge d'opérateur global est si vous souhaitez autoriser les expressions où le type de classe apparaît sur le côté droit d'un opérateur binaire. Par exemple:

Foo f = 100;
int x = 10;
cout << x + f;

Cela ne fonctionne que s'il y a une surcharge d'opérateur global pour

Opérateur Foo + (int x, const Foo & f);

Notez que la surcharge d'opérateur global n'a pas nécessairement besoin d'être une friendfonction. Cela n'est nécessaire que s'il a besoin d'accéder à des membres privés de Foo, mais ce n'est pas toujours le cas.

Quoi qu'il en soit, si Fooseulement il y avait une surcharge d'opérateur de fonction membre, comme:

class Foo
{
  ...
  Foo operator + (int x);
  ...
};

... alors nous ne pourrions avoir d'expressions où une Fooinstance apparaît à gauche de l'opérateur plus.