Perguntas sobre OOP em MQL5 - página 9

Novo comentário
 
Igor Makanu:

de que toneladas estamos falando? tudo o que foi negligenciado será relatado pelo terminal, o local onde também é conhecido para apagá-lo - OnDeint() .... Esta discussão se transformou em uma discussão de um cavalo esférico em um vácuo? )))

Não. Deixe o cavalo cavalgar onde ele deve.

Mas estamos discutindo a criação de objetos antes desconhecidos. E não conhecemos apenas suas propriedades, mas também o número de objetos criados em si.

Naturalmente, para um objeto podemos criar um ponteiro e trabalhar com esse objeto através desse ponteiro. Mas se não sabemos de antemão de quantas indicações precisaremos, que tipo de vácuo é este? É apenas uma das mais simples e imediatamente disponível - armazenar apontadores em listas. Eles podem ser retirados da lista. Bem, cada objeto pode ter seu próprio identificador (o método Type()), pelo qual você pode identificar o objeto ponteiro. É possível identificar com precisão um objeto (além de seu tipo, o objeto pode ser dotado de outras propriedades, distinguindo-o dos objetos do mesmo tipo).

Em geral - parece que estou falando de estruturas mais complexas, que exigem classificação de objetos, listas para seu armazenamento e métodos de trabalho com objetos que não só podem armazenar e dar informações mediante solicitação, mas também "viver e crescer" interagindo com o programa, de tempos em tempos mudando e informando sobre suas ações.

Talvez eu tenha ido longe demais e discutido apenas um objeto onde dois campos devem ser mudados durante a inicialização e eles não devem mudar de forma alguma durante a vida útil do objeto. De que adianta ter um objeto se há variáveis de entrada?

 
Ninguém é obrigado a remover um objeto, exceto aquele que o criou. Mesmo que isso ocorra em alguns casos, não é de confiança. Se você o criou, você o apaga.
 
Dmitry Fedoseev:
Ninguém é obrigado a apagar um objeto, exceto aquele que o criou. Mesmo que isto aconteça em alguns casos, não é de confiança. Se você o criou, você o apaga.

Isso é verdade. Mas não é sobre isso que estamos falando. Não é?

Estamos falando de métodos pelos quais os objetos não são definitivamente perdidos, e você pode definitivamente encontrá-los.

Quando você cria um objeto, esteja ciente dele e não o perca, para que possa ser devidamente apagado posteriormente e não haja vazamento de memória devido à perda do ponteiro do objeto (começamos com o vazamento de memória no exemplo em que o ponteiro do objeto passado para a função foi reatribuído ao objeto recém-criado no corpo da função).

E cada um tem suas próprias preferências - algumas como uma coisa, outras como outra. Mas temos que saber sobre cada um de nossos objetos - mesmo que sejam dois ou dois mil e dois - para que possamos apagá-los mais tarde. E se nós mesmos os apagaremos eliminando-os ou deixando lista por Clear() ou em loop por lista e eliminar ou de alguma outra forma - não se trata disso.

 
Artyom Trishkin:

Em geral, sinto que estou falando de estruturas mais complexas, que requerem classificação de objetos, listas para seu armazenamento e métodos de trabalho com objetos, que podem não apenas armazenar e dar informações sob solicitação, mas também "viver e evoluir" interagindo com o programa, de tempos em tempos mudando a si mesmos e relatando suas ações.

Talvez eu tenha ido longe demais e apenas precisamos discutir um objeto onde dois campos devem ser mudados na inicialização e eles não devem mudar de nenhuma forma durante a vida útil? De que adianta ter um objeto se há variáveis de entrada?

Este é um conceito estranho de OOP. Primeiro de tudo, OOP é conveniente - você o escreve uma vez e depois cria novas instâncias do objeto.

Voltando ao início da discussão, aqui está meu exemplo, eu o uso frequentementehttps://www.mql5.com/ru/forum/160683/page861#comment_11840254

Preciso limitar minha negociação a um intervalo de tempo agora e dois da próxima vez. 4...

meu exemplo de 2 cliques é modificado para esta tarefa:

int OnInit()
{
   Work1=new CWorkTime(StartHour1,StartMinute1,StopHour1,StopMinute1);
   Work2=new CWorkTime(StartHour2,StartMinute2,StopHour2,StopMinute2);
   Work3=new CWorkTime(StartHour3,StartMinute3,StopHour3,StopMinute3);
   Work4=new CWorkTime(StartHour4,StartMinute4,StopHour4,StopMinute4);
}


Não sei, mas pensando em categorias que o OOP é apenas para embrulhar tudo em uma classe e aí é um milagre - minha superclasse e pode fazer as duas coisas... E se a classe é de 10 cordas, você não precisa de OOP - por que se limitar e enganar a todos?

Onde me convém, eu uso OOP, a discussão foi claramente para a religião - para proibir ou usar OOP ))))

 
Igor Makanu:

Esta é uma idéia estranha de OOP, OOP é antes de tudo conveniente - escreva uma vez, depois crie novas instâncias do objeto

Voltando ao início da discussão, aqui está meu exemplo, eu o uso frequentementehttps://www.mql5.com/ru/forum/160683/page861#comment_11840254

Preciso limitar minha negociação a um intervalo de tempo agora e dois da próxima vez. 4...

meu exemplo de 2 cliques é modificado para esta tarefa:


Não sei, mas pensando em categorias que o OOP é apenas para embrulhar tudo em uma classe e aí é um milagre - minha superclasse e pode fazer as duas coisas... E se a classe é de 10 cordas, você não precisa de OOP - por que se limitar e enganar a todos?

onde é conveniente para mim, é onde eu uso OOP, claramente a discussão foi para a religião - para proibir ou usar OOP ))))

Definitivamente - não sou eu quem está entrando nesta religião, uma vez que eu mesmo uso ativamente o OOP.

Por exemplo: e se precisarmos de mais alguns intervalos? Devemos criar novas? Para quê? Se você puder fazer com uma lista sem interferir com o código do programa.

Parece que estamos falando de coisas diferentes. Estou falando de usabilidade, e você está... Também estou falando de usabilidade, mas você está mostrando um código que não é utilizável. Talvez apenas exagerado, é claro, e eu não o entendi...

 
Artyom Trishkin:

Por exemplo: e se forem necessários mais intervalos? Novas WorkNNNs devem ser criadas? Qual é o objetivo? Se você puder gerenciar com uma lista sem interferir no código do programa...

Se precisarmos usar listas ou arrays de instâncias de classe, não é um grande problema, mas é mais fácil usar um array para este exemplo e fazer apenas um loop:

bool DisableTrade=false;
   for(int i=0;i<ArraySize(Work);i++)
     {
      if(Work[i].Disable()) {DisableTrade=true; break}
     }
   if(DisableTrade)
     {
      Comment("Не торговое время!!! Сопровождение открытых ордеров");
     }
   else...

Artyom Trishkin:

Parece que estamos falando de coisas diferentes. Estou falando de usabilidade, e você ... Também estou falando de usabilidade, mas o código que você está mostrando não é conveniente. Talvez seja apenas exagerado, é claro, e eu não entendi...

Infelizmente é impossível escrever código universal. Mesmo que você escreva código universal, sua modificação será um processo tedioso e, como conseqüência, o código universal será mais intensivo em recursos - em geral, você pode falar sobre isso para sempre, uma vez que escrevi que um dos programadores famosos disse -"o código deve cumprir sua tarefa! - isso é suficiente". Todo o resto é ... bem, é um desejo de brincar ou... digamos para criar! )))

 
Artyom Trishkin:

///

Por exemplo: e se forem necessários mais intervalos? Novas WorkNNNs devem ser criadas? Qual é o objetivo? Se você puder gerenciar com uma lista sem interferir com o código do programa.

///

Então não haverá parâmetros de intervalos numéricos na janela de propriedades. Você não será capaz de otimizá-los. Não é uma opção.

A criação de um novo objeto para cada intervalo também não é a melhor opção. Mesmo assim, isso levará a um desempenho mais lento. Se tivéssemos que criar uma classe, deveríamos criar uma que acrescentasse os parâmetros de intervalos em uma matriz. Será mais rápido.

 
Dmitry Fedoseev: rmosa. Se você tiver que fazer uma classe, ela deve ser tal, que acrescentaria parâmetros de intervalos em uma matriz. Será mais rápido.

não faz absolutamente nenhuma diferença se você faz uma classe ou uma função na qual você adiciona() vários parâmetros, se você cria várias classes com parâmetros individuais

SZZ: não esqueça que se você escrever uma grande função na forma de uma longa "fita de cavalo" - o cache da CPU nem sempre será efetivamente utilizado, embora possa haver um ganho em tal "fita de cavalo" ao prever as transições.... Somente testes podem mostrar isso, mas em um PC específico e em um compilador específico...

 
Dmitry Fedoseev:

Então, não haverá parâmetros de intervalo numérico na janela de propriedades. Você não será capaz de otimizá-lo. Não é uma opção.

A criação de um novo objeto para cada intervalo também não é a melhor opção. Afinal de contas, isto levará a um desempenho mais lento. Se tivéssemos que criar uma classe, deveríamos criar uma que acrescentasse os parâmetros de intervalos em uma matriz. Seria mais rápido.

De acordo. Mais uma vez, tudo se resume aos métodos para definir os campos de checkout. E como transferi-los dos parâmetros de entrada para o objeto que armazena todos os intervalos é uma questão de técnica. Embora seja possível recriar todos os objetos na lista de intervalos e quando você muda apenas um deles - é uma questão de praticidade e "incomodar/não incomodar" para alterar os dados ao escrever o código.

 
Roman:

Você pode explicar o sentido da criação de um objeto dinâmico usando o novo operador?

Quando um objeto é criado automaticamente, o objeto de classe é criado na pilha e é mais rápido que um objeto dinâmico em termos de tempo de execução.
Ao criar um objeto dinamicamente, um objeto de classe é criado na memória (na pilha) envolvendo o gerenciador de memória do SO, o processo é mais lento.

Aqui estão as perguntas:
Se a criação automática é mais rápida, então por que é melhor usar objetos dinâmicos?
Controlar explicitamente a alocação de memória?
Eliminar um possível transbordo de pilha?
E para não perder um objeto inesperadamente?
Porque se a pilha transbordar, o objeto será automaticamente apagado?

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 do coletor de lixo: por exemplo, pode ser contagem de referência como em Python (versão 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 é usada na MQL é desconhecida, mas podemos assumir que é extremamente eficiente, pois o usuário da MQL5 tem o operador de eliminação diretamente disponível, 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:)

12345678910111213141516...96
Novo comentário
Razão: