Erreurs, bugs, questions - page 2357
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
4) Et pourquoi le compilateur autorise-t-il un "simple" appel de méthode virtuelle ? Je ne pense pas que la virtualité doive dépendre de la présence ou de l'absence de données dans l'objet.
Vous confondez les deux.
La dévirtualisation des appels est une méthode d'optimisation distincte qui n'a rien à voir avec la présence ou l'absence de champs dans un objet.
2) le constructeur de copie est généré par le compilateur, sauf s'il est déclaré par l'utilisateur.
Il y a un objet B à gauche, pourquoi le constructeur A::A() est-il appelé pour lui ?
Car en µl, c'est ainsi que les opérateurs =, ==, !=, !&, &| et || se comportent toujours lorsqu'il y a un pointeur à gauche et un "objet" à droite. Et en même temps, ces opérateurs ne peuvent pas être surchargés sur les pointeurs.
Alors s'il vous plaît, lorsque vous corrigerez ce bug, rendez les opérateurs ci-dessus surchargeables pour les objets dynamiques.
Des suggestions sur la façon de le réparer ?
Merci d'avance pour votre aide.
Car c'est ainsi que les opérateurs =, ==, !=, !& et || se comportent toujours dans µl lorsqu'il y a un pointeur à gauche et un "objet" à droite.
Il y a un objet B sur la gauche, pourquoi le constructeur A::A(A&) est-il appelé (ou généré) pour lui ? Cela contredit les principes de la POO.
Je suis entièrement d'accord avec vous et j'ai déjà écrit qu'il s'agit d'une erreur qui sera corrigée.
Dans ce cas, le compilateur a détecté une surcharge appropriée sur l'héritage, ce qui n'aurait pas dû être fait lors de la construction de l'objet.
On peut discuter longtemps de la nécessité ou non de "déréférencer" un pointeur s'il n'y a pas d'accès à celui-ci.
L'opération de déréférencement (obtention d'un pointeur réel à partir d'un handle) est un code "interne" (non personnalisé) et coûteux (par rapport à son absence).
Pourquoi effectuer un déréférencement s'il n'y a pas d'accès au pointeur ?
Parce qu'une liste de méthodes virtuelles fait partie de l'information d'un objet, pas moins importante que les données elles-mêmes, et que l'accès aux méthodes virtuelles est un accès par pointeur. Par exemple, si j'écris dans mon exemple
J'obtiendrai à nouveau B::f(), bien que ce code fasse explicitement référence à l'affectation de l'objet A*, qui a été "copié" de A et a été référencé par A*. Cette situation est plus grave que le fait d'appeler le "mauvais" constructeur de copie. Mais même si l'objet n'avait pas eu de méthodes virtuelles, nous aurions dû vérifier la validité du pointeur lors de son accès.
Il y a un objet B sur la gauche, pourquoi le constructeur A::A(A&) est-il appelé (ou généré) pour lui ? Cela contredit les principes de la POO.
Êtes-vous sûr qu'il y a un nom là-dedans ? J'ai vérifié en x32 :
Résultat : A::A()
et rien d'autre !
Êtes-vous sûr qu'il y a un nom là-dedans ? J'ai vérifié en x32 :
Résultat : A::A()
et rien d'autre !
Donc, je vais vérifier les vidages des générateurs/optimiseurs pour mettre les points sur les i.
Même si l'objet n'a pas de méthodes virtuelles, vous devez quand même vérifier la validité du pointeur lorsque vous y accédez.
En fait, il s'agit d'une question ambiguë. Par exemple, cette vérification est toujours présente en C# et seulement si nécessaire en C++, ce qui donne un avantage en termes de vitesse.
Après tout, si vous appelez une méthode qui n'accède pas aux champs d'un objet, il est inutile de vérifier le pointeur. En fait, une telle méthode est équivalente à une méthode statique.