Erros, bugs, perguntas - página 2754

[A100]

fxsaber:

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.

void f()
{
        MqlTick tick;
        SymbolInfoTick( NULL, tick );
        g( tick );
}

inline void SymbolInfoTick( string symbol, MqlTick& tick )
{
      tick = _LastTick; //л енивое программирование: а не будем ничего копировать,
                        //пока _LastTick не изменится
}

E será uma solução não para uma estruturaMqlTick em particular, mas para todas as ocasiões

[Ilyas]

A100:

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

[Igor Makanu]

Ilyas:

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

[Alexey Navoykov]

Igor Makanu:

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 este tick uma vez no manipulador OnTick, e depois de trabalhar com os dados obtidos? Praticamente não custa nada. Porque devo solicitá-lo 100 vezes (como nos testes acima referidos), criando artificialmente travões num lugar uniforme? Então, sugere-se que o problema de um código de EA torto seja resolvido complicando o trabalho interno da MT. Ou tem algumas medidas normais?

[fxsaber]

Alexey Navoykov:
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.

[Maxim Kuznetsov]

Alexey Navoykov:
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.

[Igor Makanu]

Alexey Navoykov:
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

Alexey Navoykov:
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 ))))

[A100]

De acordo com os materiais de .... surgiram as seguintes considerações:

Dado que UninitializeReason() pode ser chamada em qualquer parte de um programa, particularmente no OnInit() (e se tal chamada não fosse intencional, o âmbito poderia ser alargado)

Sugere-se a sua utilização:

Se o valor da variável _UninitReason for gerado antes de OnDeinit() ser chamado,

e se não for possível definir a razão para a des-inicialização prévia da EA (REASON_PROGRAM, REASON_REMOVE, etc.)

deve ser indefinido (-1) antes desta chamada. Isto é agora 0, ou seja, efectivamente RAZÃO_PROGRAMA

Se a EA for completamente reiniciada(REASON_RECOMPILE, REASON_ACCOUNT, REASON_CLOSE, etc.), então

parece possível definir a variável _UninitReason para um valor apropriado (REASON_RECOMPILE, REASON_ACCOUNT, REASON_CLOSE, etc.) ao iniciar uma nova instância de um programa,

e não 0 como actualmente, ou seja, efectivamente RAZÃO_PROGRAMA

Se um Expert Advisor for reiniciado parcialmente (REASON_CHARTCHANGE, etc.), a variável _UninitReason no OnInit() ainda é igual ao valor correspondente (REASON_CHARTCHANGE, etc.),

e nenhuma mudança é necessária

[Sergey Dzyublik]

erro de compilação do bug MT5 (build 2450) para declaração prévia do método de classe modelo

template<typename T>
class A{};


class B{
public:
   template<typename T>
   void test(A<T> &a);
};

template<typename T>
void B::test(A<T> &a){}   // 'test' - member function already defined with different parameters 


void OnStart(){ 
   B b;
} 

[Artyom Trishkin]

Ao reiniciar o terminal, ele escreve continuamente e sem parar no registo de registo

2020.05.24 03:36:03.342 HistoryBase     'GBPUSD' 1 invalid bars removed

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.