Erros, bugs, perguntas - página 2754
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
O objectivo é poder passar por referência.
Tal como com as cordas, os Desenvolvedores têm a oportunidade (se ainda não o fizeram) de passar tudo por referência sem realmente copiar a variável.
E será uma solução não para uma estruturaMqlTick em particular, mas para todas as ocasiões
O que mais uma vez confirma que não faz sentidoutilizar directamente _Dígitos,_Ponto , _Período, _LastError, etc. (e até _Símbolo pode ser substituído por NULL). De facto, devem ser declarados como constantes e voláteis
E você, pelo contrário, propõe alargar esta gama
Tem razão, mas eles sãoquase voláteis, excepto a bandeira IsStopped - é 100% volátil, ou seja, qualquer leitura de IsStopped é 100% leitura de memória.
Para outros,almostvollatylе significa que o compilador MAIOR cache o valor de uma variável num registo na primeira chamada e utilizar o valor em cache na próxima vez que essa variável for acedida, mas apenas dentro de uma função ou ramo de chamadas, se forem agrupadas numa única função.
Isto é possível (e necessário) porque a alteração de variáveis predefinidas (excepto IsStopped) não pode acontecer dentro de um ponto de entrada MQL (função OnXXX)
Relativamente ao MODIFICADORVARIÁVEL, digamos que é usado por programadores constantes para programadores.
Como sabemos, é possível alterar a constante de uma variável através da conversão, pelo que não se pode confiar no compilador com o modificador constante.
Se o compilador vê que a variável não alterou o seu valor e é inicializada como uma constante, vai transformar essa variável num valor imediato (ImmediateValue) mesmo sem o modificador constante
. Em relação a _LastTick, estamos a discutir mas...
Esta é uma estrutura, não um simples tipo atómico e pode ser alterada de repente, em qualquer ponto do programa MQL, incluindo o tempo de obtenção do valor.
Acontece que, para abordar esta estrutura, é necessário introduzir um sincronizador.
Estamos constantemente a trabalhar no desempenho, em particular, devido a esta elevada taxa de libertação de construções.
Planeamos fazer muito trabalho para acelerar o código MQL
Em relação a _LastTick, estamos a discutir, mas...
Esta é uma estrutura, não um tipo simples-atómico e pode ser alterada subitamente, em qualquer ponto do programa MQL, incluindo o tempo de obtenção do valor.
Acontece que, para abordar esta estrutura, precisamos de introduzir um sincronizador.
mas no testador _LastTick não pode mudar em nenhum ponto do programa MQL ?
se sim, então dê essa solução apenas para o testador, onde a velocidade dos cálculos é mais importante
mas no testador _LastTick não pode mudar em nenhum ponto do programa MQL ?
se sim, então dê essa solução apenas para o testador onde a velocidade de cálculo é mais importante
Então, o que o impede de solicitar uma vez este tick no manipulador OnTick e depois trabalhar com os dados recebidos?
As baixas qualificações dos criadores da EA com que o Mercado e a Nuvem estão carregados são um obstáculo.
Então, o que impede que se solicite uma vez o tick no manipulador OnTick, e que se trabalhe mais com os dados recebidos? Praticamente não custa nada. Porquê pedir novamente 100 vezes (como nos testes anteriormente citados), criando artificialmente travões no lugar? Assim, propõe-se resolver o problema de um código de EA torto, complicando o trabalho interno da MT. Ou tem algumas medidas normais?
Os eventos a serem tratados por "OnTick" são recebidos externamente em alguma fila com prioridades. Noutros manipuladores, é útil certificar-se de que não ocorreram novos eventos, caso contrário os dados do tick anterior são inválidos/ desactualizados.
Então, o que o impede de solicitar este tick uma vez no manipulador OnTick e depois trabalhar com os dados resultantes? É praticamente inútil. Porquê dar-se ao trabalho de o solicitar 100 vezes (como nos testes acima referidos), criando artificialmente um travão no local.
Isto é exactamente o que eu faço no testador
Isto é, o problema de um código EA torto deve ser resolvido através da complicação do funcionamento interno do MT. Ou tem algumas medidas normais?
Bem, o código é determinado por práticas de codificação comuns, ver o QB e a utilização de linhas de segurança nestes exemplos
Eu não uso SB, tenho medido com um profiler e procuro soluções há meses, houve um fio sobre testes de velocidade, lançando em parte soluções alternativas
a normalidade da medição? é um declive escorregadio que terá de ser tratado com seriedade, estou satisfeito com a minha EA para optimização, houve um passe aos 18 meses 6 seg, agora 2,5 seg , imho fiz um bom trabalho em mim ))))
e não 0 como actualmente, ou seja, efectivamente RAZÃO_PROGRAMA
Ao reiniciar o terminal, ele escreve continuamente e sem parar no registo de registo
O tempo da barra histórica no registo está constantemente a aumentar. O gráfico diário GBPUSD está aberto e agitado - zero, primeira e segunda barras são eliminadas/criadas. E assim anda de um lado para o outro.
Aqui estou eu à espera. Irá encher todos os SSD com estes registos ou irá finalmente parar...
O diário de bordo de ontem está no reboque.