Ajuda com o OOP

 

Estou fazendo uma aula como esta.

class Strategy1
{
        Strategy1();
 };

class Strategy2
{
        Strategy (string sym);
}

Agora eu quero chamar uma matriz de objetos:

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

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?

 

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.

 
Georgiy Merts #:

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;
   }
}
 
Ihor Herasko #:

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 baixa:

Um exemplo de um problema potencial seria bom.

 
Ihor Herasko #:

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:

Ai.

 
Não é nada de mais.
 
fxsaber #:

Um exemplo de um problema potencial seria bom.

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.

 
Ihor Herasko #:

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.

 
Ihor Herasko #:

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)))

 
Vasiliy Sokolov #:

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.
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. Все работало...