OLP. Problèmes d'application - page 3

[Yedelkin]

Référence technique. Un exemple de "mécanisme d'enveloppement" lorsque vous travaillez avec des classes (pour ne pas avoir à le chercher) :

https://www.mql5.com/ru/forum/3555/page3#comment_57315

[Yedelkin]

Question. Le nouvel opérateur. Le Manuel de référence indique que new est un opérateur ; cependant, dans les exemples, une vérification est souvent effectuée après l'utilisation de cet opérateur pour s'assurer qu'il est égal à NULL. Par exemple :

//+------------------------------------------------------------------+
//| Создание фигуры                                                  |
//+------------------------------------------------------------------+
void CTetrisField::NewShape()
  {
   m_ypos=HORZ_BORDER;
//--- случайным образом создаём одну из 7 возможных фигур
   int nshape=rand()%7;
   switch(nshape)
     {
      case 0: m_shape=new CTetrisShape1; break;
      case 1: m_shape=new CTetrisShape2; break;
      case 2: m_shape=new CTetrisShape3; break;
      case 3: m_shape=new CTetrisShape4; break;
      case 4: m_shape=new CTetrisShape5; break;
      case 5: m_shape=new CTetrisShape6; break;
      case 6: m_shape=new CTetrisShape7; break;
     }
//--- отрисовываем
   if(m_shape!=NULL)
     {
      //--- начальные установки
      m_shape.SetRightBorder(WIDTH_IN_PIXELS+VERT_BORDER);
      m_shape.SetYPos(m_ypos);
      m_shape.SetXPos(VERT_BORDER+SHAPE_SIZE*8);
      //--- отрисуем
      m_shape.Draw();
     }
//---
  }

Il est également dit que"NULL peut être comparé à des pointeurs vers des objets créés à l'aide de l'opérateur new".

Il s'avère donc que l'opérateur new ne crée pas toujours un nouvel objet ? Ou bien la vérification de l'égalité d'un objet créé à NULL est-elle une particularité du style d'un développeur et n'est-elle pas obligatoire ?

[Mykola Demko]

Yedelkin:

Question. Le nouvel opérateur. Le Manuel de référence indique que new est un opérateur ; cependant, dans les exemples, une vérification est souvent effectuée après l'utilisation de cet opérateur pour s'assurer qu'il est égal à NULL. Par exemple :

Il est également dit que"NULL peut être comparé à des pointeurs vers des objets créés à l'aide de l'opérateur new".

Il s'avère donc que l'opérateur new ne crée pas toujours un nouvel objet ? Ou bien la vérification de l'égalité d'un objet créé à NULL est-elle une particularité du style d'un développeur et n'est-elle pas obligatoire ?

Si vous créez un objet dynamique à un endroit du programme, il est logique qu'à un autre endroit vous le détruisiez, et il n'est pas certain que tout cela se fasse à l'intérieur d'une seule fonction, d'où une règle simple, avant d'utiliser un pointeur pour vérifier s'il existe.

[Yedelkin]

Urain:
Si vous créez un objet dynamique à un endroit du programme, il est logique que vous le détruisiez à un autre endroit, et il n'est pas certain que tout cela se fasse au sein d'une même fonction. Une règle simple consiste donc à vérifier son existence avant d'utiliser un pointeur.

C'est exact. Mais dans les exemples du Manuel de référence, la vérification est effectuée immédiatement après la création de l'objet, c'est-à-dire à un endroit du programme et dans une seule fonction. Et la règle donnée ici n'est pas tout à fait pertinente. Pourquoi le contrôle devrait-il être effectué juste après la création d'un objet ? Il s'avère donc que l'opérateur new ne crée pas toujours un nouvel objet ? =(Je répète)=

Voici un exemple parmi tant d'autres :

//--- example for CArrayString::Add(string)
#include <Arrays\ArrayString.mqh>
//---
void OnStart()
  {
   CArrayString *array=new CArrayString;
   //---
   if(array==NULL)
     {
      printf("Object create error");
      return;
     } 

[Konstantin Gruzdev]

Yedelkin:

C'est exact. Mais dans les exemples du Manuel de référence, la vérification est effectuée immédiatement après la création de l'objet, c'est-à-dire à un seul endroit du programme et dans une seule fonction. Et la règle ci-dessus n'est pas applicable ici. Pourquoi le contrôle devrait-il être effectué juste après la création de l'objet ? Il s'avère donc que l'opérateur new ne crée pas toujours un nouvel objet (je le répète) ?

Voici un exemple parmi tant d'autres :

Il y a cette possibilité. Dans l'aide, le premier paragraphe.

[Yedelkin]

Lizar:
Il y a une telle possibilité. Dans la référence, le premier paragraphe.

OK. Il s'avère que le comportement de l'opérateur est comme celui d'une fonction. Elle peut ou non la créer.

[Rashid Umarov]

Yedelkin:
OK. Il s'avère que le comportement de l'opérateur est celui d'une fonction. Elle peut être créée ou non.

Par exemple, il n'y a pas assez de mémoire pour l'objet.

[Yedelkin]

Rosh:
Par exemple, il n'y avait pas assez de mémoire pour un objet.

Parfois, une simple explication permet d'élargir considérablement vos horizons. Merci !

[Yedelkin]

Question. Une fois qu'une fonction virtuelle avec un ensemble spécifique de paramètres et de types est déclarée dans une classe mère, le nombre et les types de paramètres des fonctions virtuelles correspondantes peuvent-ils être modifiés dans les classes dérivées ?

D'une part, le Manuel de référence indique qu'"une fonction virtuelle peut être substituée dans une classe dérivée . Lechoix de ladéfinition de fonction à appeler pour la fonction virtuelle est fait dynamiquement (au moment de l'exécution). Un cas typique est celui où une classe de base contient et les classes dérivées ont leurs propres versions de cette fonction". D'autre part, les exemples donnés dans le Manuel de référence font référence aux cas où les fonctions virtuelles ont des corps de définition de fonction différents plutôt que des en-têtes de définition de fonction.

[Ilyas]

Yedelkin:

Question. Après avoir déclaré une fonction virtuelle avec un certain ensemble de paramètres et leurs types dans une classe parent, est-il possible de changer le nombre et les types de paramètres des fonctions virtuelles correspondantes dans les classes enfants ?

Seulement une copie exacte de la définition, à l'exception des paramètres par défaut (les paramètres par défaut peuvent varier, mais il est préférable de ne pas l'utiliser)