Discussion de l'article "Utilisation des pointeurs d'objet dans MQL5"

[MetaQuotes]

Un nouvel article Utilisation des pointeurs d'objet dans MQL5 a été publié :

Par défaut, tous les objets de MQL5 sont transmis par référence, mais il est possible d'utiliser les pointeurs d'objet. Cependant, il est nécessaire d'effectuer la vérification du pointeur, car l'objet peut ne pas être initialisé. Dans ce cas, le programme MQL5 sera terminé avec une erreur critique et déchargé. Les objets, créés automatiquement, ne provoquent pas une telle erreur, donc dans ce sens, ils sont tout à fait sûrs. Dans cet article, nous allons essayer de comprendre la différence entre la référence d'objet et le pointeur d'objet, et d'examiner comment écrire du code sécurisé qui utilise les pointeurs.

Dans MQL5, vous pouvez créer votre propre classe pour une utilisation ultérieure des variables de type classe dans votre code. Comme nous le savons déjà dans l'article L'ordre de création et de destruction des objets dans MQL5, les structures et les classes peuvent être créées de deux manières - automatiquement et dynamiquement.

Pour créer un objet automatiquement, déclarez simplement une variable de type classe - le système la créera et l'initialisera automatiquement. Pour créer un objet dynamiquement, il est nécessaire d'appliquer explicitement l'opérateur new au pointeur d'objet.

Cependant, quelle est la différence entre les objets créés automatiquement et dynamiquement, et quand a-t-on nécessairement besoin de l'utilisation du pointeur d'objet, et quand suffit-il de créer les objets automatiquement ? Ce sujet constitue l'objet de cet article. Tout d'abord, discutons de certains pièges possibles lorsque vous travaillez avec des objets et examinons les moyens de les résoudre.

Auteur : MetaQuotes

[Stanislav Korotky]

Le code source du texte devrait être mis en conformité avec les fichiers joints, en particulier dans le listing GetCriticalError_Unsafe.mq5 il est fait référence à la variable inexistante status au lieu de pstatus (comme dans le fichier).

Et quel est l'intérêt de définir son propre type de variable dans chacune des classes héritières de CShape ?

J'aimerais également avoir des explications à ce sujet. Lors du passage de l'exemple GetCriticalError_OnDemand à GetCriticalError_Unsafe, l'ensemble du changement s'est pratiquement réduit à changer le type de l'argument de la fonction de CHello *pobject à CHello &pobject. Dans le même temps, l'appel de la fonction est resté inchangé - un pointeur (CHello *) a été transmis. Dans ce cas, selon l'auteur,"nous obtenons à nouveau une erreur critique". Le fait est que si un objet est passé par référence, l'erreur critique se produit au stade de l'appel d'une fonction où un objet non initialisé lui est passé". Mais dans ce cas, c'est un pointeur qui est transmis à la fonction, et non une référence. La question se pose de savoir d'où vient cette référence. Pourriez-vous préciser les règles utilisées par MQL5 pour la conversion implicite des pointeurs en références et vice-versa ? Ou indiquer l'endroit de la documentation où cela est décrit. Si le compilateur supportait le typage strict, l'exemple échouerait simplement à la compilation en raison de l'absence d'une fonction avec un argument du type requis.

[Rashid Umarov]

marketeer писал(а) # :

Le code source du texte devrait être mis en conformité avec les fichiers joints, en particulier dans le listing GetCriticalError_Unsafe.mq5 il est fait référence à une variable inexistante status au lieu de pstatus (comme dans le fichier).

Merci, correction dans l'article et dans le fichier.

[Rashid Umarov]

marketeer писал(а) # :

Quel est l'intérêt de définir sa propre variable de type dans chacune des classes successeurs de CShape ?

En principe, ce membre n'est utilisé nulle part, vous pouvez le supprimer. Théoriquement, il peut être utilisé dans les descendants pour implémenter des fonctions qui dépendent du type de l'objet.

[Rashid Umarov]

marketeer писал(а) # :
J'aimerais également obtenir quelques éclaircissements sur cette question. Lors du passage de l'exemple GetCriticalError_OnDemand à GetCriticalError_Unsafe, l'ensemble du changement s'est pratiquement réduit à changer le type de l'argument de la fonction de CHello *pobject à CHello &pobject. Dans le même temps, l'appel de la fonction est resté inchangé - un pointeur (CHello *) a été transmis. Dans ce cas, selon l'auteur,"nous obtenons à nouveau une erreur critique". Lefait est que si un objet est passé par référence, l'erreur critique se produit au stade de l'appel d'une fonction où un objet non initialisé lui est passé". Mais dans ce cas, c'est un pointeur qui est transmis à la fonction, et non une référence. La question se pose de savoir d'où vient cette référence. Pourriez-vous préciser les règles utilisées par MQL5 pour la conversion implicite des pointeurs en références et vice-versa ? Ou indiquer l'endroit de la documentation où cela est décrit. Si le compilateur supportait le typage strict, l'exemple ne se compilerait tout simplement pas car il n'y a pas de fonction avec un argument du type requis.

Si une fonction acceptant un paramètre comme pointeur est explicitement définie, elle sera utilisée. Si une telle fonction n'existe pas, le pointeur d'objet sera automatiquement converti en référence à l'objet et la fonction acceptant l'objet par référence sera utilisée.

[Stanislav Korotky]

Rosh писал(а) # :
En principe, ce membre n'est utilisé nulle part, vous pouvez le supprimer. Théoriquement, il peut être utilisé dans les descendants pour mettre en œuvre des fonctions qui dépendent du type d'objet.

Je comprends bien que, selon la source actuelle de l'exemple, nous obtenons un "râteau" que dans l'objet d'une forme d'un type particulier il y a deux variables de type, par exemple, CLine::type en plus de CShape::type ? Idéalement, il ne devrait y en avoir qu'une seule - celle de la classe de base.

[Stanislav Korotky]

Rosh писал(а) # :
Si une fonction acceptant un paramètre en tant que pointeur est explicitement définie, elle sera utilisée. Si une telle fonction n'existe pas, le pointeur de l'objet sera automatiquement transformé en référence à l'objet et la fonction acceptant l'objet par référence sera utilisée.

Existe-t-il un endroit où l'on peut trouver des informations sur le sens des conversions implicites concernant les références et les pointeurs ? En particulier, la conversion inverse est-elle également effectuée - d'une référence à un pointeur ?

[Rashid Umarov]

marketeer писал(а) # :
Existe-t-il un endroit où je puisse trouver des informations sur le sens des conversions implicites effectuées sur les références et les pointeurs ? En particulier, la conversion inverse est-elle également effectuée - d'une référence vers un pointeur ?

Non, pour obtenir un pointeur d'un objet, utilisezGetPointer().

[Rashid Umarov]

marketeer писал(а) # :
Est-ce que je comprends bien que, selon la source actuelle de l'exemple, nous obtenons un "râteau" que dans l'objet d'une forme d'un type particulier il y a deux variables de type, par exemple, CLine::type en plus de CShape::type ? Idéalement, il ne devrait y en avoir qu'une seule - de la classe de base.

Oui, vous avez raison. Il y a deux variables de type dans chaque descendant comme vous l'avez écrit. Cela s'est produit parce que le code des descendants a été copié. Pour qu'un membre de la classe de base soit directement accessible aux descendants, il doit être défini avec le spécificateur protected ou des méthodes publiques get- et set pour ce membre doivent être déclarées dans la classe de base.

Par exemple, comme ceci :

//+------------------------------------------------------------------+
//|demo_inheritance.mq5 |
//| Copyright 2010, MetaQuotes Software Corp.
//|http ://www.mql5.com
//+------------------------------------------------------------------+
#property copyright "2010, MetaQuotes Software Corp."
#property link      "http://www.mql5.com"
#property version   "1.00"
//+------------------------------------------------------------------+
//||
//+------------------------------------------------------------------+
class CBase
  {
private:
   int               type;
public:
                     CBase(){type=0;}
   int               GetType(){return(type);}
  };
//+------------------------------------------------------------------+
//||
//+------------------------------------------------------------------+
class CSon: CBase
  {
private:
   int               type;
public:
                     CSon(){type=2;}
   void              PrintType();
  };
//+------------------------------------------------------------------+
//||
//+------------------------------------------------------------------+
void CSon::PrintType()
  {
   Print("CSon.type =",type);
   Print("CBase.type =",CBase::GetType());
  }
//+------------------------------------------------------------------+
//| Fonction de démarrage du programme de script|
//+------------------------------------------------------------------+
void OnStart()
  {
//---
   CSon  son;
   son.PrintType();
   int father_type=son.GetType();
  }
//+------------------------------------------------------------------+

[Denis Kirichenko]

Citation :

"Cet exemple est très simple, il n'est pas difficile d'y trouver une erreur. Mais si votre programme mql5 contient des centaines, voire des milliers de lignes, la détection de telles erreurs peut s'avérer beaucoup plus compliquée. En particulier dans les cas où les conditions de situations anormales dans le comportement du programme dépendent de facteurs imprévisibles - par exemple, sur un certain marché."

Comment ?:-)

[trader0k]

C'est le cas lorsque les spécificités du couple sont différentes d'une manière ou d'une autre.