Pourquoi une fonction non-membre ne peut-elle pas être utilisée pour surcharger l'opérateur d'affectation?

tout d'abord, il convient de noter que cela n'a rien à voir avec l'exploitant mis en œuvre en tant que ami spécifiquement. Il s'agit en fait de mettre en œuvre la copie-assignation en tant que fonction membre ou en tant que Fonction non-membre (autonome). Que cette fonction autonome soit un ami ou non n'est pas du tout pertinent: elle pourrait l'être, elle pourrait ne pas l'être, selon ce qu'elle veut accéder à l'intérieur de la classe.

Maintenant, la réponse à cette la question est donnée dans le D&E livre ( La Conception et l'Évolution de C++ ). La raison en est que le compilateur déclare/définit toujours un opérateur membre copy-assignment pour la classe (si vous ne déclarez pas votre propre opérateur membre copy-assignment).

si la langue permettait aussi de déclarer l'opérateur copy-assignment comme une fonction autonome( non-membre), vous pourriez vous retrouver avec la suivante

// Class definition
class SomeClass {
  // No copy-assignment operator declared here
  // so the compiler declares its own implicitly
  ...
};

SomeClass a, b;

void foo() {
  a = b;
  // The code here will use the compiler-declared copy-assignment for `SomeClass`
  // because it doesn't know anything about any other copy-assignment operators
}

// Your standalone assignment operator
SomeClass& operator =(SomeClass& lhs, const SomeClass& rhs);

void bar() {
  a = b;
  // The code here will use your standalone copy-assigment for `SomeClass`
  // and not the compiler-declared one 
}

comme vu ci-dessus par exemple, la sémantique de la copie-assignation changerait au milieu de l'Unité de traduction - avant la déclaration de votre opérateur autonome la version du compilateur est utilisée. Après la Déclaration, votre version est utilisée. Le comportement du programme changera en fonction de l'endroit où vous placez la déclaration de votre opérateur autonome copy-assignment.

cela a été considéré comme un danger inacceptable (et c'est le cas), donc C++ ne permet pas à l'opérateur copy-assignment d'être déclaré comme une fonction autonome.

il est vrai que dans votre exemple particulier, qui utilise une fonction ami spécifiquement, l'opérateur est déclaré très tôt, à l'intérieur de la définition de la classe (puisque c'est ainsi que les amis sont déclarés). Donc, dans votre cas, le compilateur va, bien sûr, connaître l'existence de votre opérateur. Cependant, du point de vue du langage C++ le grand problème n'est pas lié à un ami fonctions. Du point de vue du langage C++, il s'agit des fonctions de membre par rapport aux fonctions de non-membre, et la surcharge de copie par un non-membre est tout simplement interdite pour les raisons décrites ci-dessus.

$13.5.3 - "Un opérateur d'affectation doit être mis en œuvre par un non-fonction membre statique avec un seul paramètre. parce qu'un opérateur d'affectation de copie= est implicitement déclaré pour une classe si elle n'est pas déclarée par l'utilisateur (12.8), un opérateur d'affectation de classe de base est toujours caché par l'opérateur d'affectation de copie de la classe dérivée."

parce qu'il y a des opérateurs qui doivent être membres. Ces opérateurs sont:

operator[]

operator=

operator()

operator->

et les opérateurs de conversion de type, comme operator int .

bien que l'on puisse expliquer pourquoi exactement operator = doit être un membre, leur argument ne peut pas s'appliquer à d'autres dans la liste, qui me fait croire que la réponse à "Pourquoi" est "Juste parce que".

HTH

operator= est une fonction de membre spéciale que le compilateur fournira si vous ne la déclarez pas vous-même. En raison de ce statut spécial de operator= il est logique ro exiger d'être une fonction de membre, il n'y a donc aucune possibilité d'être à la fois un membre généré par compilateur operator= et un ami utilisateur déclaré operator= et aucune possibilité de choisir entre les deux.

pourquoi la fonction ami ne peut-elle pas être utilisée pour surcharger l'opérateur d'affectation?

courte réponse: juste parce que .

réponse un peu plus longue: C'est ainsi que la syntaxe a été corrigée. Quelques opérateurs doivent être membres fonctions 151980920". L'opérateur d'affectation est l'un des,