Por que valenok2003 é contra o MT5 - página 2
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
О! Vai para outra vez! Eu amo isso! Você pode passar sem ele. Você sempre pode, mas não é necessário.
Em alguns casos, vai para simplificar o código e acelerá-lo. Eu li um artigo em algum lugar que os motoristas estão escritos com ele para acelerar as transições.
Olá.
O código do montador não conhece outro caminho.
Para simplificar o código é improvável, para torná-lo ilegível para outros é certo, sobre velocidade - depende de quais tarefas, e quem tem o que "caligrafia ao programar", em princípio, eu nem quero discutir, parece que discutimos seriamente sobre os benefícios e danos de ir para http://www.gamedev.ru/flame/forum/?id=69459.
Se você descer ao nível de desmontagem do programa, os loops em todas as JVS serão muito provavelmente organizados como transições condicionadas de jcxz e assim por diante..,
que será essencialmente uma construção se(cx==0) passar para a etiqueta
Para uma saída antecipada dos laços aninhados, para saltar de diferentes condições para um único ponto? Isto simplifica o código. Eu o uso com bastante freqüência. Às vezes o uso para loops.
Olá.
O código do montador não conhece outro caminho.
Se é assim, então é assim :), como diz o ditado: "todas as cores da ponta de feltro são diferentes" ))))))))
O assunto é individual, veja, o desenvolvedor principal é incomodado pelo OOP. Se ele não usasse o OOP, ele estaria cultivando o Grand Theatre MQL5 há muito tempo atrás.
http://khpi-iip.mipk.kharkiv.edu/library/extent/dijkstra/pp/ewd215.html
За многие годы я утвердился во мнении о том, что квалификация программистов - функция, обратно зависящая от частоты появления операторов go to в их программах.
...devemos fazer ... Tudo o que pudermos para preencher a lacuna conceitual entre um programa estático e um processo dinâmico, para tornar a correspondência entre o programa (desdobramento no espaço do texto) e o processo (desdobramento no tempo) o mais óbvia possível.
http://khpi-iip.mipk.kharkiv.edu/library/extent/dijkstra/pp/ewd215.html
Esta é apenas uma das muitas opiniões. Há tantos a favor e contra. É uma questão de gosto e estilo.
O autor está se limitando severamente.
Esta é apenas uma das muitas opiniões. Há tantos a favor quanto contra. É uma questão de gosto e estilo.
O autor está se limitando muito.
As tendências modernas na programação são tais que os programas são freqüentemente escritos e acompanhados por equipes de programadores. Isto impõe exigências sobre a qualidade do código, sua legibilidade.
Minha opinião: o código deve ser claro e bem comentado. Mais uma vez minha opinião pessoal: ir para é um operador prejudicial, ele impede que você leia o código. Imagine um programa de pelo menos 500 linhas, com uma centena de etiquetas e salta para elas.
A questão da aplicação do goto é na área de preferência pessoal. Ele não gosta e inventa uma razão para não gostar.
Há outros que gostam e que inventam uma razão para gostar. Para mim, todas estas razões são as mesmas. Meu código é simplificado quando o goto é aplicado, então eu o uso, se não, eu não o uso.
Não me limito à especulação de outras pessoas.
Imagine um programa de pelo menos 500 linhas, com uma centena de etiquetas e transições para elas.
Os motoristas ainda são escritos dessa forma. Por quê?
Porque a velocidade de execução vem em primeiro, segundo e terceiro lugar nos motoristas.
Por que precisamos até idiomas de alto nível quando podemos escrever tudo em linguagem de montagem?
E por que eles não põem caixas de lança e assentos conversíveis na Fórmula 1?