Perguntas sobre OOP em MQL5 - página 11

Novo comentário
 
Dmitry Fedoseev:

E por falar em aves... os descritores também são indicadores. E você sabe, nada muda em relação à própria palavra, seja ela um descritor, um ponteiro, um identificador.

a implementação física destas palavras há muito tempo tem sido escondida dos usuários

imho é mais ou menos assim

- descritor - está vinculado ao método que implementa esta funcionalidade no sistema

- um cabo - tudo é o mesmo que um descritor, mas o sistema operacional o implementa

- um ponteiro e um identificador são destinados a trabalhar com a memória física

 
Dmitry Fedoseev:

E se você tem que passar um ponteiro para uma função para criar um objeto na função, é assim que ela funciona:

class CObj{
   public:
   int f(){
      return(33);
   }
};

CObj * obj;

void OnStart(){
  z(obj);
  delete(obj);
}

void z(CObj & o){
   o = new CObj();
}
Isso é tudo o que você queria saber sobre o OOP, mas estava com medo de perguntar))))

Uh-huh, gênio.

Estas 17 linhas são na verdade tudo o que você precisa saber sobre a qualificação do Fedoseev como programador.

2019.07.05 15:19:56.309 acesso ponteiro inválido em 'test13.mq5' (11,5)

 
Vasiliy Sokolov:

Boa tarde. A memória do computador tem o mesmo desempenho, independentemente de ser usada em um contexto de pilha ou pilha. A própria gestão dinâmica da memória depende da implementação de coletores de lixo: por exemplo, pode ser contagem de referência como em Python (variante mais lenta) ou análise de épocas de geração de objetos com a travessia gráfica de execução em processo de fundo (Net CLR). Qual variante é utilizada na MQL é desconhecida, mas podemos assumir que é extremamente eficiente, pois o usuário da MQL5 tem acesso direto ao operador de eliminação, o que simplifica muito o trabalho da própria GC. Portanto, suas preocupações com a sobrecarga ao usar novas são infundadas - sinta-se à vontade para usar memória dinâmica.

Quanto ao "estouro de pilha", a única maneira de encontrar este caso em sistemas modernos é quando se usa recursividade complexa ou se comete um erro no algoritmo recursivo. Um programa moderno sempre funciona em modo protegido OC no espaço de endereços virtual, com carregamento dinâmico de páginas de memória, portanto não se preocupe: a pilha não irá transbordar:)

Obrigado por uma explicação inteligente.
Por alguma razão, pensei que em mql a chamada na pilha é mais rápida do que na pilha, especialmente porque não conhecemos a implementação do coletor de lixo.
É por isso que tenho tais perguntas, o que é melhor usar para acelerar a criação de objetos, automáticos ou dinâmicos.
Sim, eu entendo que tudo depende da tarefa específica, mas, por exemplo, vamos aceitar o envio de ordens de negociação.
E nossa tarefa é criar os objetos mais corretos para um rápido desempenho no processamento.
Temos uma classe de usuários com métodos descritos de pedidos comerciais.
Conhecemos o número de instâncias de classe e seus métodos.
E como você sugere, "a pilha não vai acabar".

Daí minha pergunta é: qual método é melhor para criar e apagar objetos? Automática ou dinamicamente?
Tive uma idéia para fazer o gerenciamento sintético de objetos automáticos em geral.
Ou seja, declarar objetos automáticos no corpo da função do usuário.
Desta forma, o objeto é criado na pilha (em teoria, é mais rápido que a pilha). Não temos que nos preocupar com a eliminação automática do objeto porque a variável objeto é declarada na função definida pelo usuário
e o objeto automático será verificado adicionalmente para destruição pela própria função do usuário, de acordo com a regra das variáveis dinâmicas nas funções.
É por isso que eu gostaria de ouvir as opiniões adequadas dos participantes deste ramo, que pensam a este respeito.

 
TheXpert:

Mm-hmm, gênio.

Essas 17 linhas são realmente tudo o que você precisa saber sobre as qualificações do Fedoseev como programador.

2019.07.05 15:19:56.309 acesso ponteiro inválido em 'test13.mq5' (11,5)

Incrível. E ambos compenso sem erros (neste momento) e funciona corretamente.

Da próxima vez, desenhe em photoshop.

 
Roman:

Obrigado por uma explicação inteligente.
Por alguma razão, eu pensei que chamar a pilha de mql é mais rápido do que na pilha, especialmente porque não sabemos como o coletor de lixo é implementado.
É por isso que tenho tais perguntas, o que é melhor usar para acelerar a criação de objetos, automáticos ou dinâmicos.
Sim, entendo que tudo depende da tarefa específica, mas, por exemplo, vamos levar em conta o envio de pedidos comerciais.
E nossa tarefa é criar os objetos mais corretos para um rápido desempenho no processamento.
Temos uma classe definida pelo usuário com métodos descritos de pedidos comerciais.
Conhecemos o número de instâncias de classe e seus métodos.
E como você sugere, "a pilha não vai acabar".

Daí minha pergunta é: qual método é melhor para criar e apagar objetos? Automática ou dinamicamente?
Tive a idéia de fazer uma gestão sintética de objetos automáticos em geral.
Ou seja, declarar objetos automáticos no corpo da função do usuário.
Desta forma, o objeto é criado na pilha (em teoria, é mais rápido que a pilha). Não temos que nos preocupar com a eliminação automática do objeto porque a variável objeto é declarada na função definida pelo usuário
e o objeto automático será verificado adicionalmente para destruição pela própria função do usuário, de acordo com a regra das variáveis dinâmicas nas funções.
É por isso que eu gostaria de ouvir as opiniões adequadas dos participantes deste ramo, que pensam a este respeito.

Você pensou bem. O acesso a objetos criados com novos é muito mais lento. E aqui não há coletor de lixo.

 
Igor Makanu:

a implementação física destas palavras há muito tempo tem sido escondida dos usuários

imho assim:

- descritor - vinculado a um método que implementa esta funcionalidade no sistema

- um cabo - tudo é o mesmo que um descritor, mas o sistema operacional o implementa

- um ponteiro e um identificador implicam que se trata de uma operação na memória física.

E não faz nenhuma diferença para nós como funciona.

 

Uma palavra de conselho sobre outro assunto. Se você criar uma classe infantil CMyButton a partir do CButton, você pode criar um botão e depois mudar suas propriedades fora da classe. Abaixo, isto é feito no OnInit().

Mas se eu quiser fazer campos adicionais dentro da classe criança e usar as propriedades embutidas da classe CButton em novas funções, como isso pode ser implementado corretamente?

Na classe CButton, o membro da classe m_button é declarado na seção privada. 

#include <Controls\Button.mqh>

class CMyButton : public CButton
{ 
  private: 

  public: 
              CMyButton(void){}; 
             ~CMyButton(void){}; 
             
        bool    isPrevState;        // состояние кнопки на предыд.тике, true - была нажата     
        void    setButton();        // создаем кнопку
        void    setProp();          // задаем в ходе программы свойства
}; 

void CMyButton::setButton(void)
{
  // как в этой функции создать кнопку? Я не могу вызвать метод Create()
}

//+------------------------------------------------------------------------------------------------------------------+
//| 
//+------------------------------------------------------------------------------------------------------------------+

CButton Btn;
CMyButton MyBtn;

int OnInit()
  {
  
   Btn.Create(0, "Btn", 0, 50, 50, 120, 75);
   Btn.Text("Standart");
   MyBtn.Create(0, "MyBtn", 0, 50, 200, 150, 225);
   MyBtn.Text("MyBtn");
   
   return(INIT_SUCCEEDED);
  }
 
Dmitry Fedoseev:

Sim, ele apaga e escreve uma mensagem sobre vazamentos de memória, apenas para que os programadores que escrevem EAs não se aborreçam com suas vidas.

É interessante como ontem houve um vazamento de memória e hoje não pode haver nem mesmo um.

E por falar em aves... os descritores também são indicadores. E você sabe que a palavra em si não muda nada, seja ela um descritor, um ponteiro, um identificador.

O vazamento vem do espaço de endereçamento do processo. Quando você entra enquanto (verdadeiro) loop, seu programa acabará por travar na próxima alocação de memória do heap, que se esgotou.
 
Dmitry Fedoseev:

E ambos compenso sem erros (neste momento) e funciona corretamente.

Sim, já duas pessoas não relacionadas estão fotografando a queda do seu código )

Seu código não pode funcionar corretamente, é óbvio pelo próprio código ))

 
TheXpert:

Sim, duas pessoas não relacionadas já estão fotografando seu código )

Seu código não pode funcionar corretamente, é óbvio pelo próprio código ))

Há pouco, queria escrever a mesma coisa))))
1...456789101112131415161718...96
Novo comentário