Programação OOP vs procedimento - página 24
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
1. Há um critério. O critério principal é a velocidade de operação.
A visibilidade do código é o critério errado.
Todos mudam urgentemente para asambler..... mas fast.... é verdade que o que é rápido é a organização adequada de todo o projeto ou a velocidade das funções individuais
Todos se mudam urgentemente para asambler..... mas fast.... a verdade é rápida é a velocidade de todo o projeto ou a velocidade das funções individuais
Todos se mudam urgentemente para asambler..... mas fast.... o que é realmente rápido é a organização adequada de todo o projeto ou a velocidade das funções individuais
Não, continue codificando através do ***.
Bem, eu discordo.
A clareza do código é uma coisa muito importante, porque código claro é muito mais fácil de manter e modificar.
Isso mesmo - eu escrevi uma função nua, e então realmente a "ofusquei", tornando-a invisível e incompreensível. Esta foi uma decisão forçada. Neste caso, foi mais importante para mim tornar a classe inteira transparente. Eu sacrifiquei a clareza de uma função bastante trivial. É claro que eu poderia ter colocado o corpo desta função no arquivo .mq5, mas acredito que as interfaces não devem ser divididas em dois arquivos e devem ser completamente descritas no arquivo de cabeçalho .mqh.
Velocidade também é algo a se ter em mente, mas não acho que devemos nos esforçar por "velocidade a qualquer custo". Tem que haver uma suficiência razoável.
Provavelmente o mesmo ponto 3 para você também
Estou programando há muito tempo. Desde o lançamento do MT3.
Desde então, sinto-me mais confortável escrevendo em estilo processual no mql4. Eu não tenho EAs em 1001 linhas. Além disso, eu tenho apenas algumas funções armazenadas em bibliotecas.
E na MQL5 eu utilizo a biblioteca padrão. É uma coisa conveniente.
Mas a otimização do desempenho deve ser feita para evitar chamar mais e mais funções pesadas. Recentemente, tenho modificado uma EA de Mql4 para MQL5. Usei a biblioteca aqui apresentada. Demorei meio dia para descobrir todas as funções e funcionou, mas a otimização foi muito lenta. Eu tenho indicador de corte para 2 barras e tudo começou a voar.
A conclusão é simples. Todos podem escrever em qualquer estilo. MQL não é realmente uma linguagem que requer otimização de código para ganhar um par de milissegundos através da programação de procedimentos. As tarefas lógicas são mais importantes. A forma como são implementadas praticamente não tem efeito sobre a velocidade.
...
A conclusão é simples. Todos podem escrever em qualquer estilo. MQL não é realmente uma linguagem, que requer otimização de código, de modo que pode ganhar alguns milissegundos usando programação procedural. As tarefas lógicas são mais importantes. A forma como são implementadas praticamente não tem efeito sobre a velocidade.
Tão discretamente desiludido que é a programação de procedimentos que proporciona alto desempenho. Há três dias venho lhes mostrando um problema que só pode ser resolvido pelo OOP sem freios desnecessários.
O OOP nos permite selecionar conjuntos de variáveis do restante do código, o que nos permite evitar passar parâmetros para métodos ao realizar cálculos dentro de uma classe, e este é um fator significativo para a velocidade. Mesmo se você o fizer em estilo processual, terá que criar um grande número de variáveis globais e, como resultado, a legibilidade do código é impossivelmente baixa.
Foi tão gentilmente decepcionado que é a programação de procedimentos que proporciona alto desempenho. Há três dias eu venho mostrando aqui um problema que só pode ser resolvido pelo OOP sem freios desnecessários.
O OOP nos permite selecionar conjuntos de variáveis do restante do código, o que nos permite evitar passar parâmetros para métodos ao realizar cálculos dentro de uma classe, e este é um fator significativo para a velocidade. Mesmo se você fizer isso em um estilo de procedimento, você terá que criar um grande número de variáveis globais, e como resultado, a legibilidade do código é impossivelmente baixa.
O ganho de estilo de procedimento é insignificante, porque o código é iniciado com cada tick em Expert Advisors. E pode haver centenas ou mesmo dezenas de milissegundos entre carrapatos. Eu nunca me preocupei com indicadores. Eu não encontrei nenhum lucro real de indicadores.
Entretanto, é provavelmente mais conveniente usar o OOP para grandes projetos. Eu mesmo prefiro usar estruturas, se eu tiver que salvar alguma coisa.
O acesso aos dados é então mais claramente organizado e o menu pull-down é muito conveniente de usar. Se você substitui estruturas por arrays, muitas vezes surge confusão e o número de arrays cresce.
No post anterior eu estava colocando a ênfase exatamente em chamar funções pesadas. Por exemplo, algum tipo de loop loop que não precisa ser chamado em cada carrapato. E você também não precisa fazer isso em cada novo bar.
É aí que o ganho real de desempenho pode ser aumentado.
Sim. É um debate engraçado: Escavadeira versus pá.
Se você quiser plantar uma árvore, uma pá é melhor. Mas se você quiser cavar um buraco, a retroescavadeira provavelmente é melhor.
Sim. É um debate engraçado: Escavadeira versus pá.
Se você quiser plantar uma árvore, uma pá é melhor. Mas se você quiser cavar um buraco, a retroescavadeira provavelmente é melhor.
Sim. É um debate engraçado: Escavadeira versus pá.
Se você quiser plantar uma árvore, uma pá é melhor. Mas se você quiser cavar um buraco, a retroescavadeira provavelmente é melhor.