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.
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; } }
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.
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.
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é))).
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.
- 2014.02.08
- www.mql5.com
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Vous acceptez la politique du site Web et les conditions d'utilisation
Je fais un cours comme ça.
Maintenant, je veux appeler un tableau d'objets :
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 ?