Duplicaté possible: strong>
Opérateur de surcharge -> P>salut, p>
J'ai vu que
opérateur -> () code> est chaîné (réappliqué) après son évaluation, par exemple: P>
int main() { string s = "Hello world"; auto_ptr<string> ptr1(&s); auto_ptr<auto_ptr<string> > ptr2(&ptr1); cout << ptr1->c_str() << endl; // fine cout << ptr2->c_str() << endl; // breaks compilation }
3 Réponses :
Non, il n'est pas possible de travailler. Si vous pouviez surcharger Et même si vous le pouviez, comment le compilateur pourrait-il savoir quand la récursion devrait se terminer? p> opérateur -> code> pour
chaîne * code> vous pouvez le faire fonctionner. Mais
opérateur -> code> a déjà une définition pour tous les types de pointeur. Donc, comme vous ne pouvez pas surcharger
+ code> pour les types numériques primitifs, vous ne pouvez pas surcharger
opérateur -> code> pour n'importe quel type de pointeur. P>
La raison pour laquelle votre premier exemple fonctionne est que vous avez renvoyé une référence au lieu d'un pointeur. Cet opérateur serait normalement invalide sauf dans le cas où il est surchargé. Par conséquent, le compilateur doit exécuter les fonctions surchargées dans la chaîne. Cependant, dans le cas de S'il vous plaît voir le Opérateur de surcharge -> Question pour plus de détails. P> auto_ptr code>, vous êtes réellement renvoyé un vrai pointeur et l'opérateur
défaut -> code> est invoqué pour des pointeurs réguliers. P>
Merci de votre réponse. Je cherchais une approche pour simplifier le code pour itération de vecteur
C ++ 98 standard §13.5.6 / 1 "Accès membre de la classe": p>
Une expression
x-> m code> est interprétée comme
(x.opérateur -> ()) -> m code> pour un objet de classe
x code> de type
t code> si
t :: opérateur -> code> existe et si l'opérateur est sélectionné à la meilleure fonction de correspondance par le mécanisme de résolution de surcharge (13.3). P> blockQuote>
Qu'est-ce que cela signifie en pratique est que lorsque
x code> est un pointeur, vous n'obtenez pas de chaînage; Vous venez d'obtenir l'opérateur
intégré -> code> (c.-à-d.
x-> m code> avec
x code> un pointeur traduit par
(* x ) .m code>). p>
mais quand
x code> est un objet de type
t code>, vous pouvez obtenir l'effet de chaînage. Parce que l'interprétation comme
(x.opérateur -> ()) -> m code> peut être que
(x.opérateur -> ()) code> est un objet de certaines catégories , Dites Classe
u code>. D'où la seconde
-> code> peut être résolue comme
u :: opérateur -> code>, etc., si le résultat de celui-ci est à nouveau un objet de type de classe ... P>
Comme, dans votre cas,
foo :: opérateur -> code> produit (une référence à) un objet de classe
bar code>, qui définit un opérateur
> code>. p>
mais quand
opérateur -> code> renvoie un pointeur, comme par exemple.
std :: auto_ptr
:: opérateur -> code> fait, alors c'est juste l'opérateur intégré -> code> utilisé. P>
en passant, le chaînage peut em> être utilisé pour empêcher pratiquement une personne d'utiliser
Supprimer code> de manière inappropriée.
std :: auto_ptr code> ne fait pas cela. Et je ne l'ai jamais vu fait. P>
Mais il y avait une fois un fil de discussion longuement dans [Comp.lang.c ++. Modérée] sur la manière d'empêcher tout inadvertance
Supprimer code> du pointeur brut géré par un pointeur intelligent, et c'était une possibilité d'une possibilité. qui a été discuté. p>
acclamations et hth. p>
Duplicata de opérateur de surcharge -> [La réponse de Andreyt explique le comportement de
opérateur -> code> et Comment le "chaînage" se produit.]
@James, je préférerais garder cette ouverture puisque le libellé de la question est différent. Cela peut aider les autres personnes à trouver cette réponse.
@Judge: une question fermée n'est pas automatiquement supprimée et une question bien posée comme celle-ci ne sera pas supprimée; La question va toujours exister et être consultable.
Merci! Et puis, il ne semble pas être possible de remplacer l'opérateur-> pour le pointeur, rien ne peut être fait avec une deuxième question. Droit?
Il convient de noter que l'utilisation de
auto_ptr code> de cette manière entraînera toutes sortes de choses horribles lorsque les variables sont détruites à la fin de la fonction.