78 votes

Pourquoi ne pouvez-vous pas surcharger le '.' opérateur en C++?

Il serait très utile d'être en mesure de la surcharge . opérateur en C++ et renvoyer une référence à un objet.

Vous pouvez surcharger operator-> et operator* mais pas operator.

Est-il une raison technique?

62voto

Anton Gogolev Points 59794

Voir ici:

L'accès des membres (sélection) opérateur (c'est combien de . est appelé) peut en principe être surchargé en utilisant la même technique que celle utilisée pour ->. Cependant, cela peut conduire à des questions quant à savoir si une opération est destinée à l'objet de surcharger . ou un objet visé par l' . Par exemple:

class Y 
{
    public:
        void f();
};

class X 
{
    Y* p;
    Y& operator.() { return *p; }
    void f();
};

void g(X& x)
{
    x.f();  // X::f or Y::f or error?
}

Ce problème peut être résolu de plusieurs façons, mais à l'époque de la normalisation, il n'était pas évident ce qui serait le mieux.

Voir l'Évolution et La Conception de C++ pour plus de détails.

51voto

ddaa Points 19102

Stroustrup a dit C++ doit être souple, mais pas mutable langue.

Le point (attribut d'accès) de l'opérateur a été considéré comme trop proche de la base de la langue pour permettre la surcharge.

Voir l'Évolution et La Conception de C++, page 242, section 11.5.2 Smart Références.

Quand j'ai décidé d'autoriser la surcharge de l'opérateur ->, je me suis naturellement considéré que l'opérateur . pourrait également être surchargé.

À l'époque, j'ai considéré les arguments suivants concluante: Si obj est un objet de classe alors obj.m a un sens pour chaque membre de l' m de la classe de cet objet. Nous essayons de ne pas faire de la langue mutable en redéfinissant intégré dans les opérations de (si cette règle est enfreinte pour = de la misère, et pour unaire &).

Si nous avons permis à des surcharges d' . d'une classe X, nous serions incapables d'accéder aux membres de l' X par des moyens normaux; nous aurions dû utiliser un pointeur et d' ->, mais -> et & pourrait également avoir été ré-défini. Je voulais un langage extensible, pas un mutables.

Ces arguments sont de poids, mais pas concluante. En particulier, en 1990, Jim Adcock a proposé de permettre à la surcharge de l'opérateur . exactement de la façon dont l'opérateur -> .

Le "je" dans cette citation est Bjarne Stroustrup. Vous ne pouvez pas être plus autoritaire que cela.

Si vous voulez vraiment comprendre le C++ (comme dans "pourquoi est-il de cette façon"), vous devez absolument lire ce livre.

28voto

mfazekas Points 3024

Stroustrup a une réponse à cette question:

De l'opérateur . (dot) pourrait en principe être surchargé en utilisant la même technique utilisé pour l' ->. Toutefois, cela peut susciter des questions quant à savoir si une l'opération est destinée à l'objet la surcharge . ou un objet visé à par . Par exemple:

class Y {
public:
    void f();
    // ...
};
class X {   // assume that you can overload .
    Y* p;
    Y& operator.() { return *p; }
    void f();
    // ...
};
void g(X& x)
{
    x.f();  // X::f or Y::f or error?
}

Ce problème peut être résolu en plusieurs façons. À l'époque de la normalisation, il n'était pas évident qui serait mieux. Pour plus de détails, voir D&E.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X