Versão Beta do MetaTrader 4 IDE incluindo o novo compilador e editor MQL4 - página 5
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
É provavelmente difícil encontrar uma sugestão mais mesquinha para otimização, mas talvez seja hora de organizar a saída da lista Visão Geral do Mercado em ordem alfabética, afinal de contas? Ou será o engenheiro em mim a dizer que tudo deve ser paralelo/perpendicular... Não é um pouco estressante, mas também não é feliz. Talvez você pudesse acrescentar mais algumas linhas a essas funções 90% prontas, eh?
Pergunta : Quando é o novo mt ??? Mal posso esperar .....
De que exatamente você está esperando? Novos bugs? (o que é inevitável com mudanças tão importantes). Você está com vontade de reescrever e depurar todos os seus códigos que não funcionarão em um momento? Você não tem tempo livre para perder?
Pessoalmente, toda essa confusão com construções recentes me fez pensar globalmente sobre as perspectivas de tal programação MQL. E não importa se é no 4 ou 5. A essência é a mesma. Você escreve seus programas em uma certa linguagem sintética que está ligada a uma plataforma comercial, e eventualmente você se torna refém de todos os caprichos e erros desta plataforma / desenvolvedores de linguagem. Hoje eles querem cruzar a MQL4 com a MQL5, amanhã com a MQL6, etc. E você não tem escolha, você é obrigado a redesenhar seus desenvolvimentos de acordo com as novas regras. Caso contrário, tudo deixará de funcionar. E assim continua e assim por diante. Tudo isso não é sério.
Em geral, este foi o empurrão final para eu transferir todos os meus programas MQL para um ambiente de programação independente, sem vinculação a uma plataforma comercial específica. E usarei a MQL apenas como um elo de ligação entre a MT e meu programa. E esta é provavelmente a única maneira correta. A menos que você vá vender seus empreendimentos no mercado, é claro).
Bem, se você só gosta de programar em MQL e quer algumas novidades (isto é, interesse esportivo), então o que o impede de codificar em P5, onde tudo isso já está implementado?
De que exatamente você está esperando? Mais bugs? (o que é inevitável com mudanças tão importantes). Você está com vontade de reescrever e depurar todos os seus códigos que não funcionam em um piscar de olhos? Você não tem tempo livre para perder?
Pessoalmente, toda essa confusão com construções recentes me fez pensar globalmente sobre as perspectivas de tal programação MQL. E não importa se é no 4 ou 5. A essência é a mesma. Você escreve seus programas em uma certa linguagem sintética que está ligada a uma plataforma comercial, e eventualmente você se torna refém de todos os caprichos e erros da plataforma / desenvolvedores de linguagem. Hoje eles querem cruzar a MQL4 com a MQL5, amanhã com a MQL6, etc. E você não tem escolha, você é obrigado a redesenhar seus desenvolvimentos de acordo com as novas regras. Caso contrário, tudo deixará de funcionar. E assim continua e assim por diante. Tudo isso não é sério.
Em geral, este foi o empurrão final para eu transferir todos os meus programas MQL para um ambiente de programação independente, sem vinculação a uma plataforma comercial específica. E usarei a MQL apenas como um elo de ligação entre a MT e meu programa. E esta é provavelmente a única maneira correta. A menos que você vá vender seus empreendimentos no mercado, é claro).
E se você apenas gosta de programar em MQL e quer algumas novidades (isto é, interesse esportivo), então o que o impede de codificar em P5, onde tudo isso já está implementado?
Concordo, se o desenvolvedor deixasse o suporte para construções antigas, pelo menos 500 e removesse a atualização obrigatória para uma nova construção, que eu suspeito que será implementada, não haveria problema, mas é outra mudança incompreensível para os desenvolvedores. É claro que apoio a inclusão do OOP, mas ele é facilmente implementado em uma dll e não há necessidade de iniciar um incêndio com uma nova versão do idioma como o novo padrão. Por exemplo, o mesmo C++, eles têm vários padrões existentes, mas em geral há uma base comum que funcionará para qualquer implementação de código.
Tenho uma suspeita de que você está engomando com ferros de ferro fundido e aquecendo o fogão com carvão ... As inovações são boas, não apenas o mercado de moedas é muito dinâmico e você deve estar sempre na tendência se você quiser alcançar algo ... novas mudanças para melhor, esperemos ....
As inovações são boas, não apenas o mercado de moedas é muito dinâmico e você deve estar sempre na tendência se você quiser alcançar algo ... novas mudanças para melhor, esperemos ....
Uma coisa é estar "em tendência", mas outra coisa é ter seus projetos passados "em tendência". Se você não tiver muitos deles ou se eles não tiverem valor, então não há problema. Mas muitas pessoas aqui acumularam uma enorme base de códigos, escritos e depurados ao longo dos anos. E agora todos estão sendo colocados diante do fato de que uma parte considerável deste código logo deixará de funcionar. Isto é um absurdo. Nesses casos, a compatibilidade retroativa, ou seja, o suporte de versões mais antigas do idioma é sempre prevista, mas as metacotas não fazem isso.
Uma coisa é estar "em tendência", mas outra coisa é ter seus projetos passados "em tendência". Se você não tiver muitos deles ou se eles não tiverem valor, então não há problema. Mas muitas pessoas aqui acumularam uma enorme base de códigos, escritos e depurados ao longo dos anos. E agora todos estão sendo colocados diante do fato de que em breve uma parte considerável deste código vai parar de funcionar. Isto é um absurdo. Em casos como este, a compatibilidade retroativa é sempre prevista, ou seja, suporte para versões mais antigas do idioma, mas as meta-cotações não fazem isso.
Você tem certeza disso? Isto é uma informação privilegiada?
Uma coisa é estar "em tendência", mas outra coisa é ter seus projetos passados "em tendência". Se você não tiver muitos deles ou se eles não tiverem valor, então não há problema. Mas muitas pessoas aqui acumularam uma enorme base de códigos, escritos e depurados ao longo dos anos. E agora todos estão sendo colocados diante do fato de que uma parte considerável deste código logo deixará de funcionar. Isto é um absurdo. Em casos como este, a compatibilidade retroativa é sempre prevista, ou seja, suporte para versões mais antigas do idioma, mas as metacotas não fazem isso.
Você tem certeza disso? Isto é uma informação privilegiada?
As palavras de um alarmista. As metaquotas já disseram muitas vezes e provavelmente não se cansarão de repetir que haverá compatibilidade total. Você já vai parar com a infantilidade?
Aqui eu o ressaltei, para que ninguém dissesse que é totalmente compatível:
Quais são as diferenças em relação à antiga versão da MQL4?
A prioridade das operações booleanas E/OU mudou. Agora tudo é como no clássico C/C++
Foi introduzida uma avaliação resumida das expressões lógicas. Agora, ao avaliar uma expressão lógica, as demais subexpressões não são avaliadas. Como em C/C++.
O operador do interruptor agora usa apenas valores inteiros. Anteriormente, você poderia usar os verdadeiros.
Agora, você não pode usar uma parada completa em nomes variáveis. Além disso, não se pode usar os caracteres '@', '$', '?' em nomes variáveis.
Os requisitos para a função inicial foram reforçados. Anteriormente, era possível especificar parâmetros na função de início. Agora todos os pontos de entrada init, start, deinit, OnInit, OnStart, OnTick, OnTimer, etc. devem coincidir exatamente com suas assinaturas
Devido à expansão do conjunto de palavras-chave, nomes como short, long, float, const, virtual, input, delete, new, do, do, char não podem mais ser usados.
As funções dll importadas não podem mais aceitar matrizes de cordas como parâmetro. Como na MQL5
As diferenças não são fatais, e podem ser facilmente corrigidas no código. Em vez disso, muitas características da MQL5, uma velocidade de execução mais rápida e um controle de qualidade muito mais rigoroso estão disponíveis.
Eu, é claro, apoio a inclusão do OOP, mas ele é implementado em dll e não há necessidade de começar uma farsa em uma nova edição do idioma como um novo padrão.
Não acho que nada deveria ter mudado em Mql4. Ela existiu inalterada por muitos anos, todos os males foram curados e os usuários se acostumaram a ela. O principal é que era uma linguagem muito simples e única com suas próprias características, por exemplo, permitia algum livre arbítrio, o que poderia salvar muitas linhas de código. A única coisa que realmente lhe faltava eram estruturas. Você poderia ter se limitado a adicioná-los, e isso é tudo. E a MQL5, com sua severidade e limitações chatas, não é mais tão interessante, porque, como o bárbaro corretamente apontou, é muito mais fácil codificar em C++ real com possibilidades muito mais amplas.
Em resumo, a melhor solução seria deixar a MQL4 como está e adicionar a MQL5 como uma linguagem separada na MT4 (apenas o conjunto de características será diferente da MT5). O usuário decidiria por si mesmo em que idioma escrever.