Pessoalmente, eu uso a função Init() em objetos em tais casos.
Primeiro, é criada uma matriz, e então a função Init() é chamada para todos os objetos da matriz, onde todos os parâmetros podem ser definidos.
A inicialização com função separada permite reinicializar objetos, e se você inicializar no construtor, não poderá reinicializar o objeto.
Pessoalmente, eu uso a função Init() em objetos em tais casos.
Primeiro, é criada uma matriz, e então a função Init() é chamada para todos os objetos da matriz, onde todos os parâmetros podem ser definidos.
A inicialização com uma função separada permite reinicializar objetos, e se você a inicializa no construtor, é impossível reinicializar o objeto.
Bem, foi assim que eu imaginei. Obrigado!
Mais um ponto. É melhor criar matrizes de objetos por meio de um ponteiro. Caso contrário, você obterá uma matriz na memória de empilhamento, que é muito pequena:
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; } }
Não é um problema, e certamente não é um problema potencial. São apenas as peculiaridades do manejo da memória na MT. Aqui está uma 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() { }
E aqui está uma 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]; }
Neste caso, tudo se compila e funciona.
Não é um problema, muito menos um problema potencial. São apenas as peculiaridades do manejo da memória na MT. Aqui está uma matriz estática:
E aqui está uma matriz dinâmica:
Neste caso, tudo se compila e funciona.
O que a pilha tem a ver com isso? No primeiro caso, você tentou estaticamente (na fase de compilação) alocar um grande bloco de memória em uma pilha, e o compilador deu um justo pontapé na testa porque não está bem claro na realidade se você pode ou não alocar essa quantidade de memória.
No segundo caso, você está alocando um grande pedaço de memória já em tempo de execução. E fica imediatamente claro se você pode alocá-lo ou não, porque o programa já está trabalhando com um recurso específico da máquina (memória).
E o que os ponteiros têm a ver com isso? As matrizes em mql são de dois tipos, pré-definidas em tempo de compilação e dinâmicas. Não apenas apontadores *, mas campos de classe usuais também podem apontar para matrizes dinâmicas. Portanto, o uso de indicadores aqui não se justifica de forma alguma.
s.e. Impressão estranha do código, como ponteiros, aulas, macros - com completa falta de compreensão do que está acontecendo.
Não é um problema, muito menos um problema potencial. São apenas as peculiaridades do manuseio da memória na MT. Aqui está uma matriz estática:
E aqui está uma matriz dinâmica:
Neste caso, tudo se compila e funciona.
Exemplo errado, é apenas uma limitação do compilador que não diz nada, os desenvolvedores simplesmente decidiram assim.
Se houvesse duas versões - uma delas tem uma grande matriz estática e a outra tem uma pequena e, eis que, quando o programa funciona, ocorrem problemas em um caso, por exemplo, quando se chama recursivamente uma função, enquanto no outro caso, sob as mesmas condições, não acontecem. É quando você poderia tirar uma conclusão ... sobre os danos do suco recém espremido)))
O que a pilha tem a ver com isso? No primeiro caso, você tentou estaticamente (na fase de compilação) alocar um grande bloco de memória na pilha e o compilador lhe deu um merecido chute na cabeça porque não está nada claro no mundo real se você pode ou não alocar essa quantidade de memória.
No segundo caso, você está alocando um grande pedaço de memória já em tempo de execução. E fica imediatamente claro se você pode alocá-lo ou não, porque o programa já está trabalhando com um recurso específico da máquina (memória).
E o que os ponteiros têm a ver com isso? As matrizes em mql são de dois tipos, pré-definidas em tempo de compilação e dinâmicas. Não apenas apontadores *, mas também campos normais de classe podem apontar para matrizes dinâmicas. Portanto, o uso de indicadores aqui não se justifica de forma alguma.
s.e. Impressão estranha do código, como ponteiros, aulas, macros - com completa falta de compreensão do que está acontecendo.
Se alterarmos um pouco o exemplo, o declararmos localmente e colocarmos um número não tão feio, o compilador nos diz diretamente qual é o 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 }Se você quiser discutir com Renate, você é bem-vindo a fazê-lo.
- 2014.02.08
- www.mql5.com
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Você concorda com a política do site e com os termos de uso
Estou fazendo uma aula como esta.
Agora eu quero chamar uma matriz de objetos:
Como então criar rapidamente um conjunto de objetos se o construtor tem parâmetros a nível global?
Por exemplo? criar objetos primeiro mudando o construtor e depois como substituir os objetos no OnInit por símbolos?
Talvez haja uma solução mais fácil?