Przeciążenie operatora: funkcja składowa a funkcja niebędąca składową

Czytałem, że przeciążony operator zadeklarowany jako funkcja członkowska jest asymetryczny, ponieważ może mieć tylko jeden parametr, a drugim parametrem przekazywanym automatycznie jest thiswskaźnik. Nie ma więc standardu, aby je porównać. Z drugiej strony przeciążony operator zadeklarowany jako a friendjest symetryczny, ponieważ przekazujemy dwa argumenty tego samego typu, dzięki czemu można je porównać.

Moje pytanie jest takie, że jeśli nadal mogę porównać wartość l wskaźnika z referencją, dlaczego preferowani są przyjaciele? (użycie wersji asymetrycznej daje takie same wyniki, jak wersja symetryczna) Dlaczego algorytmy STL używają tylko wersji symetrycznych?

Jeśli zdefiniujesz funkcję przeciążoną przez operatora jako funkcję składową, kompilator tłumaczy wyrażenia, takie jak s1 + s2na s1.operator+(s2). Oznacza to, że przeciążona przez operatora funkcja członkowska jest wywoływana na pierwszym operandzie. Tak działają funkcje członkowskie!

Ale co, jeśli pierwszy operand nie jest klasą? Istnieje poważny problem, jeśli chcemy przeciążyć operator, którego pierwszy operand nie jest typem klasy double. Więc nie możesz tak pisać 10.0 + s2. Możesz jednak napisać funkcję składową przeciążoną przez operatora dla wyrażeń, takich jak s1 + 10.0.

Aby rozwiązać ten problem z porządkowaniem , definiujemy funkcję przeciążoną przez operatora jako friendJEŚLI potrzebuje dostępu do privateczłonków. Zrób to friendTYLKO wtedy, gdy potrzebuje dostępu do prywatnych członków. W przeciwnym razie po prostu uczyń to nieprzyjazną funkcją niebędącą członkiem, aby poprawić hermetyzację!

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
}

Przeczytaj to:
Niewielki problem z porządkiem w operandach. Jak funkcje niebędące składnikami
poprawiają enkapsulację

Niekoniecznie jest to rozróżnienie między friendprzeciążeniami operatorów i przeciążeniami operatorów funkcji składowych, ponieważ występuje między przeciążeniami operatorów globalnych a przeciążeniami operatorów funkcji składowych.

Jednym z powodów, dla których warto preferować przeciążenie operatora globalnego , jest zezwolenie na wyrażenia, w których typ klasy pojawia się po prawej stronie operatora binarnego. Na przykład:

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

Działa to tylko wtedy, gdy istnieje przeciążenie operatora globalnego dla

Operator Foo + (int x, const Foo & f);

Zauważ, że przeciążenie operatora globalnego niekoniecznie musi być friendfunkcją. Jest to konieczne tylko wtedy, gdy potrzebuje dostępu do prywatnych członków Foo, ale nie zawsze tak jest.

Niezależnie od tego, gdyby Footylko miał przeciążenie operatora funkcji składowej, na przykład:

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

... wtedy moglibyśmy mieć tylko wyrażenia, w których Foowystąpienie pojawia się po lewej stronie operatora plus.