Ajuda com o OOP - página 3

Novo comentário
 
Vasiliy Sokolov #:

OK. Eu não entendo. Você entendeu? Você está certo de que entendeu? Exatamente?

O argumento se resume à seguinte declaração:

...

Não se tratava de uma discussão geral, mas de uma situação relativa a um único posto, e eu expliquei qual era o problema. Ok, não houve nenhuma catástrofe.

 

Matriz declarada duplo x[268435448];

A mesma matriz na função OnStart().

Também fez uma chamada recursiva com profundidade LONG_MAX.

Sem problemas.

 
fxsaber #:

Não usa matrizes estáticas?

se o tamanho da matriz for pequeno, constante e conhecido antecipadamente, a estática é melhor e provavelmente mais rápida.

 
Andrei Trukhanovich #:

se o tamanho da matriz for pequeno, constante e conhecido antecipadamente, a estática é melhor e provavelmente mais rápida.

Gostaria de ter uma maneira de obter uma lista de variáveis/arrays estáticas e seus tamanhos. Provavelmente, é necessário um analisador de código como o que é feito aqui.

Acho que uma matriz de fios estática e uma matriz dupla são coisas bem diferentes.

MQL5 Program Packer
MQL5 Program Packer
  • www.mql5.com
This is MQL5 project packer: assemble all source and resource files from dependencies into a single ZIP.
 
fxsaber #:

Acho que a tensão estática e a dupla tensão são coisas bem diferentes.

O cordel é essencialmente uma classe interna que consiste em um ponteiro e tamanho int, ou seja, para a matriz dupla ocupará condicionalmente 1,5 vezes menos espaço

Não creio que haja muito sentido em se preocupar com isso, a menos que você tenha matrizes estáticas com milhões de elementos.

 
fxsaber #:

Não usar arrays estáticos?

Portanto, existem essencialmente quatro tipos de dados na MQL:

  • Dados estáticos, pré-definidos. Cosido no programa em tempo de compilação e não é mais modificado. Eles estão localizados em um espaço privado de memória. Por exemplo, são matrizes estáticas do tipo char[1024].
  • Dados gerenciados manualmente através dos indicadores. Estas são instâncias de classes, mas definidas por ponteiro, por exemplo, CFoo* barra em que a barra é uma instância de CFoo. Estas instâncias são do tipo POINTER_DYNAMIC. Este tipo de armazenamento é o mais problemático, embora não seja necessário na maioria dos casos.
  • Dados gerenciados pelo coletor de lixo da máquina virtual mql na qual o programa está sendo executado. Isto inclui exemplos de aulas. O ponteiro para um objeto deste tipo será POINTER_AUTOMÁTICO. Tais objetos em si estão ou no amontoado desta máquina virtual ou na seção privada. Exatamente como depende dos dados e de seu tamanho, aparentemente, e do que quer que os desenvolvedores tenham. Esta informação não está disponível. Tais dados incluem classes de usuários, por exemplo. Qualquer definição de uma instância de classe sem um ponteiro define este tipo de armazenamento. Por exemplo, a barra CFoo define uma instância da classe de barras CFoo, cujo ponteiro não precisa ser liberado. A máquina virtual realiza todas as operações de soltura. Você não precisa usar o operador de eliminação e, portanto, enfrentar o problema de objetos vazados.
  • Dados localizados na pilha. Estas são, antes de tudo, variáveis locais de funções. Ou seja, quando escrevemos int a = 5 dentro de qualquer função, o topo da pilha é movido 4 bytes para cima, alocando assim o tamanho de memória necessário. Talvez, na MQL, os tipos armazenados na pilha também incluam estruturas (para ser honesto, eu nunca chequei). Tais dados não têm muito lugar, e mesmo levando em conta uma cadeia de chamadas de funções aninhadas, a pilha como um todo requer muito menos memória do que uma pilha. Este tipo de armazenamento é usado automaticamente, não é preciso pensar sobre isso.

Se deixarmos a pilha para as funções e suas variáveis locais, ficamos com três tipos para trabalhar. Eu pessoalmente acredito (e esta é apenas minha opinião) que os dados definidos com a vida útil automática combinam bem as vantagens dos dois tipos anteriores, sem suas desvantagens. Os dados definidos com apontador automático são tão previsíveis e seguros quanto estáticos, mas tão flexíveis quanto os dados dinâmicos, controlados manualmente. Por previsibilidade quero dizer em cenários onde não há necessidade de fazer verificações adicionais de bit de ponteiro e me pergunto se outra pessoa já apagou os dados antes. Por flexibilidade quero dizer cenários onde se pode trabalhar com dados referenciados por um apontador automático como com um apontador regular, passando o apontador para uma função, ou, para arrays, reciclando-o.

Para ilustrar o que acabo de dizer, você pode comparar o código inicial fornecido por Ihor Herasko e o mesmo código que escrevi para POINTER_AUTOMATIC. Não há verificações e inicializações extras, nenhum operador apaga 60 000 000 vezes. Tudo isso poupa tempo, esforço e, o que também é importante, recursos. Se você o entende, quase nunca precisa trabalhar com apontadores. Você pode sempre escrever tal algoritmo que minimizaria este trabalho ou que permaneceria de forma alguma. Por exemplo, eu nunca manusejo objetos manualmente em meu código - não há necessidade disso de alguma forma. Quanto às matrizes estáticas, às vezes tenho que usar, por exemplo, para costurar no programa os dados que ele precisa, mas são coisas tão especiais, que os usuários comuns, presumo, não precisam deles. É melhor usar coleções prontas como CArrayObj, ou as suas próprias coleções. Agora os modelos e capacidades MQL permitem criar coisas bastante flexíveis que são muito melhores do que matrizes estáticas.

 
Não há um coletor de lixo no emcool.
 

Vasiliy Sokolov #:

Dados estáticos, pré-definidos. Cosido no programa em tempo de compilação e não mais modificado. Eles são armazenados em alguma área de memória privada. Por exemplo, estas são matrizes estáticas do tipo char[1024].

Se a matriz não for inicializada,

int A[] = {1, 2}; // Инициализация
int B[2];         // Без инициализации

por que deve ser escrito no EX5?

 
fxsaber #:

Se a matriz não for rubricada,

por que deve ser costurado no EX5?

Sim, isso mesmo, os não inicializados não são costurados, é claro. Os inicializados sim. Mas os tamanhos de ambos os tipos são definidos no momento da compilação e não mudam mais. Ou seja, as matrizes estáticas podem ser divididas condicionalmente em dois grupos.

 
Dmitry Fedoseev #:
Não há coletor de lixo no emcool.

Oficialmente, sim. Extra-oficialmente, muitas coisas indicam que ela existe:

  • Não há indicadores na MQL. Em vez disso, eles são substituídos por algo que se parece muito com eles.
  • Não há alocação direta de memória na MQL, como na C, por exemplo;
  • Os programas em MQL são executados por uma certa máquina virtual. Renat escreveu sobre isso brevemente e não uma única vez;
  • A instância de classe pode ser definida que será liberada automaticamente. Portanto, há algum mecanismo que monitora estas instâncias e as libera quando necessário. O que é isso se não é um coletor de lixo?
  • Quaisquer instâncias inicializadas através de um ponteiro e não devidamente liberadas serão marcadas como objetos vazados na saída. Seu número e tamanho total de memória perdida serão impressos. Um programa com memória vazada não será sequer validado no Mercado. Assim, todos os objetos, mesmo os alocados manualmente, são contabilizados, conhecidos e conhecidos pelo sistema. Esta é uma das tarefas clássicas que o coletor de lixo resolve.
123456789
Novo comentário