Questions sur la POO dans MQL5 - page 85

Nouveau commentaire
 
Ce n'est pas la première fois que je me surprends à penser qu'en MQL, il est préférable d'utiliser la POO uniquement lorsque c'est absolument nécessaire et seulement dans une certaine partie du code.
 
Pavel Verveyko:
Ce n'est pas la première fois que je me surprends à penser qu'en MQL, il est préférable d'utiliser la POO uniquement en cas de besoin urgent et seulement dans une certaine section du code.
Qui diable t'a donné une idée aussi stupide ? Si vous n'aimez pas les chats, vous ne pouvez pas les cuisiner. ))))
 

J'ai lu quelque part et un exemple est apparu sur le forum avec une telle construction.

delete &this;

Quelqu'un peut-il faire un exemple simple avec ceci ?

Je suis intéressé par ce que cette suppression & cette suppression suppriment ;

 
Igor Makanu:

J'ai lu quelque part et un exemple est apparu sur le forum avec une telle construction.

Quelqu'un peut-il faire un exemple simple avec ceci ?

Je suis intéressé par ce que cette suppression et cette suppression suppriment ;

Il se supprime lui-même)))

 
Vladimir Simakov:

Il s'enlève tout seul)))

qui a du sens

mais je soupçonne que le but est de l'utiliser avec des méthodes statiques.

besoin de le tester, je ne sais vraiment pas comment, c'est pourquoi j'ai demandé


UPD : j'ai cherché ce sujet sur Google hier, et j'ai trouvé beaucoup de mentions du destructeur privé.

 
Igor Makanu:

1) mais je soupçonne que l'intérêt de "supprimer &this ;" - utilisation avec les méthodes statiques
 2) hier, j'ai fait une recherche sur ce sujet et j'ai trouvé de nombreuses références au destructeur privé, mais je dois aussi réfléchir à ce qu'il peut apporter

1) Depuis les méthodes statiques, l'accès est interdit.
Où est "delete &this ;" ? - https://stackoverflow.com/questions/447379/what-is-the-use-of-delete-this

2) Le destructeur privé interdit la création d'un objet sur la pile, mais un objet peut toujours être créé par l'opérateur new, cette fois dans le tas :

class A{
   ~A(){printf(__FUNCSIG__);}
public:
    void Delete(){
        delete &this;
    }
};

void OnStart() {
   A* a_ptr = new A();
   a_ptr.Delete();
}

Voici une autre utilisation de la suppression de &this.

 
Sergey Dzyublik:

1) Depuis les méthodes statiques, l'accès est interdit.
Où faire "supprimer &this ;" - https://stackoverflow.com/questions/447379/what-is-the-use-of-delete-this

2) Un destructeur privé interdit la création d'un objet sur la pile, mais un objet peut toujours être créé par l'opérateur new, cette fois dans le tas :

Voici une autre utilisation de la suppression de &this.

On peut toujours faire quelque chose avec quelque chose. Mais quel est l'intérêt ?

Vous devriez inventer un nom, le déclarer comme un modèle de conception... et c'est tout. C'est tellement cool d'écrire un tas de code au lieu de simplement "supprimer quelque chose".

 
Un destructeur privé protège vos développements des dilettantes. Après tout, vous ne pouvez utiliser la POO avec eux que de manière mature - avec new et delete. Au fait, avez-vous déjà pensé à un nom pour le "modèle" ?
 
Dmitry Fedoseev:
Vous avez vraiment un surnom très approprié ;))
 
Igor Makanu:

J'ai lu quelque part et un exemple est apparu sur le forum avec une telle construction.

Quelqu'un peut-il faire un exemple simple avec ceci ?

Je suis intéressé par ce que cette suppression et cette suppression suppriment ;

c'est un pointeur sur l'objet courant.

Habituellement, la construction delete this est utilisée lorsqu'un objet est créé par new, mais la responsabilité de la suppression est sur l'objet lui-même. Dans ce cas, lorsque l'objet décide qu'il n'est plus nécessaire, il appelle une fonction de désinitialisation, dans laquelle il se supprime comme ceci.

À mon avis, il s'agit d'une pratique extrêmement dangereuse, acceptable uniquement dans le cas des smartpoints qui comptent eux-mêmes les références à l'objet et qui, lorsque le nombre de références devient nul, peuvent se supprimer. Mais même dans ce cas, il me semble qu'il y a de la place pour des erreurs de fuite de mémoire difficiles à détecter.

À mon avis, la responsabilité de la suppression devrait incomber au même objet qui l'a créé. Il peut utiliser le modèle de la fabrique d'objets lors de sa création, mais la suppression doit toujours relever de la responsabilité de l'objet qui a créé le nouvel objet.

1...787980818283848586878889909192...96
Nouveau commentaire