Aide sur la POO

Nouveau commentaire
 

Je fais un cours comme ça.

class Strategy1
{
        Strategy1();
 };

class Strategy2
{
        Strategy (string sym);
}

Maintenant, je veux appeler un tableau d'objets :

Strategy1 S[10];  // компилируется 
Strategy2 Z("EURUSD")[10]; // не компилируется

Comment alors créer rapidement un tableau d'objets si le constructeur a des paramètres au niveau global ?

Par exemple ? créer d'abord des objets en modifiant le constructeur et ensuite comment remplacer les objets dans OnInit par des symboles ?

Peut-être existe-t-il une solution plus simple ?

 

Personnellement, j'utilise la fonction Init() sur les objets dans de tels cas.

Tout d'abord, un tableau est créé, puis la fonction Init() est appelée pour tous les objets du tableau, où tous les paramètres peuvent être définis.

L'initialisation avec une fonction séparée permet de réinitialiser les objets, et si vous initialisez dans le constructeur, vous ne pouvez pas réinitialiser l'objet.

 
Georgiy Merts #:

Personnellement, j'utilise la fonction Init() sur les objets dans de tels cas.

Tout d'abord, un tableau est créé, puis la fonction Init() est appelée pour tous les objets du tableau, où tous les paramètres peuvent être définis.

L'initialisation avec une fonction séparée permet de réinitialiser les objets, et si vous l'initialisez dans le constructeur, il est impossible de réinitialiser l'objet.

Eh bien, c'est comme ça que je l'imaginais. Merci !

 

Encore un point. Il est préférable de créer des tableaux d'objets au moyen d'un pointeur. Sinon, vous obtiendrez un tableau dans la mémoire de la pile, qui est très petite :

Strategy2 *pZ[]; 
if (ArrayResize(pZ, 10) != 10)
{
   Alert("Memory allocation error");
   return;
}

for (int i = 0; i < 10; ++i)
{
   pZ[i] = new Strategy2("EURUSD"); 
   if (CheckPointer(pZ) == POINTER_INVALID)
   {
      Alert("Class instantiation error");
      return;
   }
}
 
Ihor Herasko #:

Encore un point. Il est préférable de créer des tableaux d'objets au moyen d'un pointeur. Sinon, vous obtiendrez un tableau dans la mémoire de la pile qui est très faible :

Un exemple d'un problème potentiel serait bienvenu.

 
Ihor Herasko #:

Encore un point. Il est préférable de créer des tableaux d'objets au moyen d'un pointeur. Sinon, vous obtiendrez un tableau dans la mémoire de la pile qui est très petit :

Aïe.

 
Ce n'est pas grave.
 
fxsaber #:

Un exemple d'un problème potentiel serait bien.

Ce n'est pas un problème, et ce n'est certainement pas un problème potentiel. C'est juste les particularités de la gestion de la mémoire dans MT. Voici un tableau statique :

#define               ARRAY_SIZE           int(60000000)
class Test
{
public:
   int               nA;
   double            fB;
   datetime          dtC;

                     Test(void)
                       : nA(0)
                       , fB(1.0)
                       , dtC(__DATETIME__)
                     {
                     };
};

Test classTest[ARRAY_SIZE];                   // 'classTest' - global variables section is too large
 
void OnStart()
{
}

Et voici un tableau dynamique :

#define               ARRAY_SIZE           int(60000000)
class Test
{
public:
   int               nA;
   double            fB;
   datetime          dtC;

                     Test(void)
                       : nA(0)
                       , fB(1.0)
                       , dtC(__DATETIME__)
                     {
                     };
};

Test *pClassTest[];
 
void OnStart()
{
   if (ArrayResize(pClassTest, ARRAY_SIZE) != ARRAY_SIZE)
   {
      Alert("Not enought memory");
      return;
   }
   
   for (int i = 0; i < ARRAY_SIZE; ++i)
   {
      pClassTest[i] = new Test();
      if (CheckPointer(pClassTest[i]) == POINTER_INVALID)
      {
         Alert("Class instantiation error");
         return;
      }
   }

   for (int i = 0; i < ARRAY_SIZE; ++i)
      delete pClassTest[i];
}

Dans ce cas, tout se compile et fonctionne.

 
Ihor Herasko #:

Ce n'est pas un problème, encore moins un problème potentiel. C'est juste les particularités de la gestion de la mémoire dans MT. Voici un tableau statique :

Et voici un tableau dynamique :

Dans ce cas, tout se compile et fonctionne.

Qu'est-ce que la pile a à voir avec ça ? Dans le premier cas, vous avez essayé d'allouer statiquement (au stade de la compilation) un grand bloc de mémoire dans un tas et le compilateur vous a justement donné un coup de pied au front parce qu'il n'est pas tout à fait clair en réalité si vous pouvez allouer autant de mémoire ou non.

Dans le second cas, vous allouez une grande partie de la mémoire déjà en cours d'exécution. Et il est immédiatement clair si vous pouvez l'allouer ou non, car le programme travaille déjà avec une ressource spécifique de la machine (la mémoire).

Et qu'est-ce que les pointeurs ont à voir avec ça ? Les tableaux dans mql sont de deux types, prédéfinis au moment de la compilation et dynamiques. Non seulement les pointeurs *, mais les champs de classe habituels peuvent également pointer vers des tableaux dynamiques. L'utilisation de pointeurs ici n'est donc absolument pas justifiée.

s.e. Impression étrange du code, comme les pointeurs, les classes, les macros - avec un manque total de compréhension de ce qui se passe.

 
Ihor Herasko #:

Ce n'est pas un problème, encore moins un problème potentiel. C'est juste les particularités de la gestion de la mémoire dans MT. Voici un tableau statique :

Et voici un tableau dynamique :

Dans ce cas, tout se compile et fonctionne.

Mauvais exemple, c'est juste une limitation du compilateur qui ne dit rien et les développeurs l'ont juste décidé.

S'il y avait deux versions - l'une d'elles possède un grand tableau statique et l'autre un petit et, lorsque le programme fonctionne, des problèmes surviennent dans un cas, par exemple, lors de l'appel récursif d'une fonction, alors que dans l'autre cas, dans les mêmes conditions, ils ne surviennent pas. C'est à ce moment-là que l'on peut tirer une conclusion ... sur les méfaits du jus fraîchement pressé))).

 
Vasiliy Sokolov #:

Qu'est-ce que la pile a à voir avec ça ? Dans le premier cas, vous avez essayé d'allouer statiquement (au stade de la compilation) un grand bloc de mémoire dans le tas et le compilateur vous a donné un coup de pied mérité dans la tête parce qu'il n'est pas du tout clair dans le monde réel si vous pouvez allouer autant de mémoire ou non.

Dans le second cas, vous allouez une grande partie de la mémoire déjà en cours d'exécution. Et il est immédiatement clair si vous pouvez l'allouer ou non, car le programme travaille déjà avec une ressource spécifique de la machine (la mémoire).

Et qu'est-ce que les pointeurs ont à voir avec ça ? Les tableaux dans mql sont de deux types, prédéfinis au moment de la compilation et dynamiques. Non seulement les pointeurs *, mais les champs de classe habituels peuvent également pointer vers des tableaux dynamiques. L'utilisation de pointeurs ici n'est donc absolument pas justifiée.

s.e. Impression étrange du code, comme les pointeurs, les classes, les macros - avec un manque total de compréhension de ce qui se passe.

Si on modifie un peu l'exemple, qu'on le déclare localement et qu'on met un nombre pas si laid, le compilateur nous dit directement quel est le problème :

#property strict
#define               ARRAY_SIZE           int(140000)

class Test
{
   
public:
   int               nA;
   double            fB;
   datetime          dtC;

                     Test(void)
                       : nA(0)
                       , fB(1.0)
                       , dtC(__DATETIME__)
                     {
                     };
};
 
void OnStart()
{
   Test classTest[ARRAY_SIZE];    // the size of local variables is too large
}
Si vous voulez vous disputer avec Renate, vous êtes le bienvenu.
the size of local variables is too large (more than 512kb)
the size of local variables is too large (more than 512kb)
  • 2014.02.08
  • www.mql5.com
Здравствуйте! Написал индикатор на mql4. Все работало...
123456789
Nouveau commentaire
Raison: