Erreurs, bugs, questions - page 2357

Nouveau commentaire
 
Ilya Malev:

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.

 
Ilyas:

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 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.
 
Alexey Navoykov:
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.

 
Metatrader 4 a cessé de fonctionner, il fonctionne pendant une seconde environ au démarrage, puis une fenêtre de négociation en un clic apparaît dans le coin supérieur gauche (Achat/Vente), puis l'application se ferme.
Des suggestions sur la façon de le réparer ?
Merci d'avance pour votre aide.
 
Ilya Malev:

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.

Qu'est-ce que le pointeur a à voir avec ça ? Je vous l'ai déjà dit ici. Cela fonctionne de la même manière ici sans pointeur.
 
Alexey Navoykov:
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.

 
Ilyas:

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

  A* aa=a;
  B* b1=a;   
  b1=aa;
  b1.f();

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.

 
Alexey Navoykov:
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 :

class A {
public:
        A()           { Print(__FUNCSIG__); }
        A( const A& ) { Print(__FUNCSIG__); }
} a;
class B : public A {
public:
        B()           { Print(__FUNCSIG__); }
        B( const B& ) { Print(__FUNCSIG__); }
} *b = a;
void OnStart() {}

Résultat : A::A()
et rien d'autre !

 
A100:

Ê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.

 
Ilya Malev:

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.

1...235023512352235323542355235623572358235923602361236223632364...3184
Nouveau commentaire
Raison: