Perguntas sobre OOP em MQL5 - página 4

Novo comentário
 
Dmitry Fedoseev:
O ponteiro também pode ser passado por não-referência - sem &.
Sim, você pode. Mas se passarmos um ponteiro sem &, um novo ponteiro é criado na pilha para a qual o valor passado é atribuído. Além disso, se alocamos memória por este ponteiro em uma função, é o ponteiro criado na pilha que muda, o que significa que obtemos vazamento de memória ao desenrolar a pilha. É claro que não é bom fazer isso, mas se alguém quiser...
 
Vladimir Simakov:
Se os destruidores forem chamados desta forma, o ponteiro criado na pilha será trocado e, consequentemente, teremos vazamentos de memória quando a pilha for "desenrolada". É claro que não é bom fazer isso, mas se alguém quiser...

o comportamento dos ponteiros para classes em MQL não é previsível, um dos administradores uma vez escreveu que todas as classes são criadas na memória global (alocação de memória), você escreve que ponteiros para classes no escopo local são criados na pilha (imho, deveria ser assim!)

Embora eu possa confundir algo, talvez eu verifique - em teoria não é difícil de verificar, basta registrar Print() no destruidor da classe de teste, os destruidores devem ser chamados automaticamente ao sair do escopo local...

 
Vladimir Simakov:
Sim, eles podem. Somente se passarmos um ponteiro sem &, um novo ponteiro é criado na pilha para a qual o valor passado é atribuído. E se alocamos memória por este ponteiro em uma função, é o ponteiro criado na pilha que muda, então obtemos vazamento de memória ao desenrolar a pilha. É claro que não é bom fazer isso, mas se alguém quiser...

Não haverá vazamento. Porque ninguém está alocando nada a este ponteiro na função.

 
Igor Makanu:

o comportamento dos ponteiros para classes em MQL não é previsível, um dos administradores uma vez escreveu que todas as classes são criadas na memória global (alocação de memória), você escreve que ponteiros para classes no escopo local são criados na pilha (imho, deveria ser assim!)

Embora eu possa estar confuso com alguma coisa, talvez eu verifique - em teoria não é difícil de verificar, basta registrar Print() no destruidor da classe de teste, os destruidores devem ser chamados automaticamente ao sair do escopo local...

Se a memória é alocada dinamicamente (nova), ela é alocada na pilha e se você criar um objeto na pilha (CObj obj;), a memória também é alocada na pilha.

 
Dmitry Fedoseev:

Não haverá vazamento. Porque ninguém aloca nada a este ponteiro na função.

void CreateLabel(CChartObjectLabel *l,string name,int y)
  {
   l=new CChartObjectLabel;
   l.Create(0,name,ChartWindowFind(),0,y);
   l.Color(clrYellow);
   l.FontSize(14);
   l.Description(name);
  }

Este é um vazamento clássico. O ponteiro criado na pilha e inicializado ao ser criado com o valor passado para a função foi atribuído um novo valor e tornou-se o ponteiro para um novo objeto. Depois disso, o ponteiro foi morto com segurança quando a pilha foi desdobrada. Que é exatamente o que precisávamos provar. É exatamente aqui que deve estar:

void CreateLabel(CChartObjectLabel* &l,string name,int y)
 
Vladimir Simakov:

Se a memória é alocada dinamicamente (nova), ela é alocada na pilha, e se você criar um objeto na pilha (CObj obj;), a memória também é alocada para ele na pilha.

Em mql não há tal coisa - (CObj obj;).

 
Vladimir Simakov:

Um vazamento clássico. A um ponteiro criado na pilha e inicializado na criação com o valor passado para a função foi atribuído um novo valor e tornou-se um ponteiro para um novo objeto. Depois disso, o ponteiro foi morto com segurança quando a pilha foi desdobrada. Que é exatamente o que precisávamos provar. É exatamente aqui que deve estar:

Não confunda o dom de Deus com um ovo. Mais uma razão para escrever um código idiota para provar uma afirmação errada...

 
Dmitry Fedoseev:

Não há tal coisa em mql - (CObj obj;)

Vamos lá! Eu a uso o tempo todo.
 
Vladimir Simakov: 
void CreateLabel(CChartObjectLabel *l,string name,int y)
  {
   l=new CChartObjectLabel;
   l.Create(0,name,ChartWindowFind(),0,y);
   l.Color(clrYellow);
   l.FontSize(14);
   l.Description(name);
  }

Um vazamento clássico. A um ponteiro criado na pilha e inicializado na criação com o valor passado para a função foi atribuído um novo valor e tornou-se um ponteiro para um novo objeto. Depois disso, o ponteiro foi morto com segurança quando a pilha foi desdobrada. Que é exatamente o que precisávamos provar. É exatamente aqui que deve estar:

Por que você reatribuiria intencionalmente um ponteiro passado para uma função? É claro, haverá um vazamento. Mas isto não é um "vazamento clássico", mas um erro clássico de manipulação de um ponteiro para um objeto.

Você não precisa criar um novo objeto aqui, mas manipular o objeto externo para o qual o ponteiro foi passado para a função.

 
Vladimir Simakov:
Vamos lá! Eu a uso o tempo todo.

Onde? Onde e como?

1234567891011...96
Novo comentário