Erreurs, bugs, questions - page 2358

 
Alexey Navoykov:

En général, il s'agit d'une question ambiguë. Par exemple, le C# dispose toujours d'une telle vérification, alors que le C++ n'en dispose que si nécessaire, ce qui lui confère un avantage en termes de rapidité.

Parce que si vous appelez une méthode sans référence aux champs de l'objet, il n'y a pas vraiment d'intérêt à vérifier le pointeur. Une telle méthode est essentiellement la même qu'une méthode statique.

Un objet peut ne pas avoir de données du tout, mais il peut mettre en œuvre un comportement absolument différent et d'une importance capitale, par exemple faire référence à certaines données externes d'une manière spéciale dépendant du type, ou effectuer une action spéciale. Je ne sais pas comment justifier une approche telle que "l'équivalence de la méthode avec une méthode statique (c'est-à-dire 100% non virtuelle) en l'absence de données".

C'est-à-dire qu'au moins un objet pointeur a toujours un champ - c'est son type. Ce qui permet de déterminer les adresses des méthodes appelées. Sinon, pourquoi avez-vous besoin de la POO ?

P.S. Bien que pour les objets automatiques je n'ai personnellement rien contre au moins une certaine logique de comportement (car je ne les utilise presque pas), mais alors vous ne devriez pas les laisser être affectés à des pointeurs
 

Malheureusement, j'ai trompé tout le monde, car les constructions

B *b=a;
B b=a;

l'opérateur de copie est appelé à la place du constructeur de copie.
Dans le second cas, après que le constructeur B() soit appelé

Dans tous les cas, nous allons d'abord analyser, puis corriger.

 

Oh, il s'avère que µl a un constructeur de copie autogénéré (je pensais qu'il n'existait pas du tout, puisque vous ne pouvez pas classer obj(other_obj), seulement avec =). Mais pourquoi n'est-il pas généré si :

class Q
{
public:
   Q(Q&)=default;  // нельзя
   Q(int) {}       // из-за него копирующий конструктор исчез
};
 
pavlick_:

Oh, il s'avère que µl a un constructeur de copie autogénéré (je pensais qu'il n'existait pas du tout, puisque vous ne pouvez pas classer obj(other_obj), seulement avec =). Mais pourquoi n'est-il pas généré si :

default et delete ne sont pas supportés.

Il s'avère que le constructeur de copie par défaut a été fait jusqu'à présent.

Opérateur de copie uniquement, c'est-à-dire pour les constructions :

CFoo foo=another_foo;

Le constructeur CFoo par défaut est appelé en premier, puis l'opérateur de copie

 
Ilyas:

l'opérateur de copie est appelé, pas le constructeur de copie.

Mais c'est encore une erreur, car l'opérateur de copie implicite ne devrait être créé que pour la classe B, et non pour toutes les classes parentes. Autrement dit, l'objet ne devrait pas être autorisé à remplacer partiellement ses internes.
 
Ilyas:

default et delete ne sont pas supportés

C'est vrai, mais vous n'avez besoin de remplacer la génération du constructeur de copie que lorsqu'il existe un constructeur de copie personnalisé, n'est-ce pas ? Pas n'importe lequel.

 
Alexey Navoykov:
C'est-à-dire que l'objet ne doit pas être autorisé à remplacer partiellement son intérieur.

C'est une sorte d'autolimitation artificielle... Je dirais même de l'étroitesse d'esprit.

class A {};
class B : public A {
public:
        void operator =( const A& ) {}
};

Quel est le problème ?

J'ai trouvé un tel modèle en moi... et ça marche... bien. Je suggère donc aux développeurs de laisser les choses en l'état... au moins si les opérateurs/constructeurs correspondants sont explicitement définis

 
A100:

C'est une sorte d'autolimitation artificielle... Je dirais même de l'étroitesse d'esprit.

Quel est le problème ?

J'ai trouvé une telle construction chez moi... et tout fonctionne... bien. Je suggère donc aux développeurs de laisser les choses en l'état... du moins si les opérateurs pertinents sont explicitement définis

Vérifiez pour commencer comment les choses fonctionnent en C++. Apparemment, ses règles ont été inventées par des personnes "étroites d'esprit".

Et de créer des bouchons pour se protéger à chaque fois d'une architecture linguistique incorrecte... Non, tu dois le faire dès le début. Je veux dire que la langue

 
Alexey Navoykov:

Vérifiez d'abord comment les choses fonctionnent en C++. Apparemment, ses règles ont été inventées par des personnes "étroites d'esprit".

Mais faire des bouchons à chaque fois pour se protéger d'une mauvaise architecture linguistique.... Non, il faut le faire dès le début. Je parle de la langue.

Je l'ai revérifié spécialement pour vous, en tenant compte de https://www.mql5.com/ru/forum/1111/page2358#comment_10003995.

#ifdef __cplusplus
#include "https://www.mql5.com/ru/forum/1111/page2358#comment_10003995"
void OnStart()
{
        A a;
        B b;
        b = a;
}
#endif

C'est bon DJ

Ошибки, баги, вопросы
Ошибки, баги, вопросы
  • 2018.12.24
  • www.mql5.com
Общее обсуждение: Ошибки, баги, вопросы
 
A100:

Je l'ai revérifié spécialement pour vous, en prenant en compte

C'est bon DJ.

Quel compilateur utilisez-vous ?

Je suis sur VS 2010 :

binaire '=' : aucun opérateur trouvé qui prend un opérande droit de type 'A' (ou il n'y a pas de conversion acceptable)

p.s. Je ne comprends pas vraiment ce que signifie "avec considération" ? Il s'agissait de l'acceptabilité de la copie implicite d'une classe de base dans une classe dérivée.

Raison: