Personalmente, utilizo la función Init() en los objetos en estos casos.
Primero se crea un array y luego se llama a la función Init() para todos los objetos del array, donde se pueden establecer todos los parámetros.
La inicialización con función separada permite reinicializar los objetos, y si se inicializa en el constructor, no se puede reinicializar el objeto.
Personalmente, utilizo la función Init() en los objetos en estos casos.
Primero se crea un array y luego se llama a la función Init() para todos los objetos del array, donde se pueden establecer todos los parámetros.
La inicialización con una función separada permite reinicializar los objetos, y si se inicializa en el constructor, es imposible reinicializar el objeto.
Bueno, así es como me lo imaginaba. Gracias.
Un punto más. Es mejor crear matrices de objetos mediante un puntero. De lo contrario, obtendrá una matriz en la memoria de la pila, que es muy pequeña:
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; } }
No es un problema, y ciertamente no es un problema potencial. Son las peculiaridades del manejo de la memoria en MT. Aquí hay una matriz estática:
#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() { }
Y aquí hay una matriz dinámica:
#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]; }
En este caso, todo se compila y funciona.
No es un problema, y mucho menos un problema potencial. Son las peculiaridades del manejo de la memoria en MT. Aquí hay una matriz estática:
Y aquí hay una matriz dinámica:
En este caso todo se compila y funciona.
¿Qué tiene que ver la pila con esto? En el primer caso, has intentado asignar estáticamente (en la fase de compilación) un gran bloque de memoria en un heap y el compilador te ha dado una justa patada en la frente porque no está muy claro en realidad si puedes asignar tanta memoria o no.
En el segundo caso, estás asignando un gran trozo de memoria ya en tiempo de ejecución. Y enseguida queda claro si se puede asignar o no, porque el programa ya está trabajando con un recurso específico de la máquina (la memoria).
¿Y qué tienen que ver los punteros con esto? Las matrices en mql son de dos tipos, predefinidas en tiempo de compilación y dinámicas. No sólo los punteros *, pero los campos de clase habituales pueden apuntar a matrices dinámicas también. Así que el uso de punteros aquí no está en absoluto justificado.
s.e. Impresión extraña del código, como punteros, clases, macros - con una completa falta de comprensión de lo que está pasando.
No es un problema, y mucho menos un problema potencial. Son las peculiaridades del manejo de la memoria en MT. Aquí hay una matriz estática:
Y aquí hay una matriz dinámica:
En este caso, todo se compila y funciona.
Ejemplo erróneo, es sólo una limitación del compilador que no dice nada y los desarrolladores simplemente lo decidieron.
Si hubiera dos versiones, una de ellas con un array estático grande y la otra con uno pequeño y, he aquí que cuando el programa funciona, en un caso se producen problemas, por ejemplo, al llamar recursivamente a una función, mientras que en el otro caso, en las mismas condiciones, no. Es entonces cuando se podría sacar una conclusión... sobre el daño del zumo recién exprimido))
¿Qué tiene que ver la pila con esto? En el primer caso, intentaste asignar estáticamente (en la fase de compilación) un gran bloque de memoria en el heap y el compilador te dio una merecida patada en la cabeza porque no está nada claro en el mundo real si puedes asignar tanta memoria o no.
En el segundo caso, estás asignando un gran trozo de memoria ya en tiempo de ejecución. Y enseguida queda claro si se puede asignar o no, porque el programa ya está trabajando con un recurso específico de la máquina (la memoria).
¿Y qué tienen que ver los punteros con esto? Las matrices en mql son de dos tipos, predefinidas en tiempo de compilación y dinámicas. No sólo los punteros *, sino también los campos normales de la clase pueden apuntar a matrices dinámicas. Así que el uso de punteros aquí no está en absoluto justificado.
s.e. Impresión extraña del código, como punteros, clases, macros - con una completa falta de comprensión de lo que está pasando.
Si alteramos un poco el ejemplo, lo declaramos localmente y ponemos un número no tan terrible, el compilador nos dice directamente cuál es el problema:
#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 alguna vez quieres discutir con Renate, eres bienvenido a hacerlo.
- 2014.02.08
- www.mql5.com
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Usted acepta la política del sitio web y las condiciones de uso
Estoy haciendo una clase como esta.
Ahora quiero llamar a un array de objetos:
¿Cómo entonces crear rápidamente un array de objetos si el constructor tiene parámetros a nivel global?
Por ejemplo? crear objetos primero cambiando el constructor y luego como reemplazar los objetos en OnInit con símbolos?
¿Quizás haya una solución más fácil?