Erros, bugs, perguntas - página 2744

[Ilyas]

Aliaksandr Hryshyn:

Erro:

Obrigado pela sua mensagem.
Corrigido.

[fxsaber]

Ilyas:

Pergunta de optimização. No Testador, em cada carrapato preciso de receber um carrapato para continuar o trabalho. Faço-o desta forma.

void OnTick()
{
  static MqlTick Tick;
  
  if (SymbolInfoTick(_Symbol, Tick))
    // ...
}

É evidente que esta variante será mais lenta:

void OnTick()
{
  MqlTick Tick;
  
  if (SymbolInfoTick(Symbol(), Tick))
    // ...
}

Mas o SymbolInfoTick também é mais lento porque o seu parâmetro de cordas não é passado por referência.

É possível ter regularmente SymbolInfo* overloads onde o fio é passado por referência?

É melhor ter

const MqlTick _Tick; // Текущий _Symbol-тик.

No Optimizer, estas funções são chamadas dezenas de milhares de milhões de vezes.

[Sergey Dzyublik]

Ilyas:
Está a sugerir que se acrescente a função GetNextEvent ?

Nem por isso, preferia chamar a esta função como HandleNextEvent, uma possível assinatura:

bool HandleNextEvent (ENUM_EVENT_TYPE);

Quando chamado, semelhante ao GetNextEvent, verifica se o ENUM_EVENT_TYPE especificado está presente na fila,
e se este evento estiver presente, passa automaticamente o controlo para o código de utilizador do manipulador correspondente (OnChartEvent, OnTrade, OnTradeTransaction, ... (graçasao fxsaber pela adição).
Retorna verdadeiro se houvesse um evento na fila, caso contrário, retorna falso.

Caso de uso possível:

//....
for(int i = 0; i < 10^6; ++i){
   // .... Data Calculations

   if((i % 10^3) == 0){
       while(HandleNextEvent(EVENT_TYPE_ALL));
   }
}
//....

[Sergey Dzyublik]

fxsaber:

Pergunta de optimização. No Testador, em cada carrapato preciso de receber um carrapato para continuar o trabalho. Faço-o desta forma.
É evidente que esta variante será mais lenta.

Já verificou esta declaração na prática? Pode parecer exactamente o oposto.

O MqlTick consiste em tipos de dados primitivos que não são inicializados.
De forma correspondente, não se perde tempo na selecção porque é a mesma operação "sub esp", apenas de um tamanho diferente.
Como resultado, o gargalo pode estar do lado do cache do processador para a leitura de um valor da operação de memória.

Em geral, devemos testá-lo )).

[fxsaber]

Sergey Dzyublik:

quando este evento ocorre, transfere automaticamente o controlo para o código do utilizador do manipulador apropriado

Caso de uso possível:

Uma solução muito agradável e útil!

[fxsaber]

Sergey Dzyublik:

Já testou esta declaração na prática? Pode acabar por ser precisamente o contrário.

A teorizar aqui. Ainda não verifiquei. Mas a transferência na ligação da corda parece apropriada.

[TheXpert]

Sergey Dzyublik:

Um possível caso de utilização:

não está a fazer sentido.

De acordo com a assinatura e a sua descrição, o terminal deve chamar uma função para processar o evento seguinte e depois devolver o controlo ao programa no ponto onde o handlenextevent é chamado?

E se o handlenextevent for novamente chamado durante o processamento?

O que acontece aos eventos que não passam o filtro nos parâmetros? são ignorados? mudam a fila?

os guiões não têm fila de eventos, porquê adicioná-los nas muletas quando há Conselheiros Especialistas e indicadores?

[Sergey Dzyublik]

TheXpert:

1) está a sugerir algum tipo de disparate.
2) de acordo com a assinatura e a sua descrição, o terminal deve chamar o próximo processamento de eventos por função e depois devolver o controlo ao programa ao ponto de chamada handlenextevent?
3) e se o handlenextevent for novamente chamado durante o processamento?
4) e o que acontece aos eventos que não caem sob o filtro nos parâmetros? são ignorados? alteram a ordem?

1) O meu trabalho é oferecer, mas quer seja uma loucura ou não - cabe aos criadores, não a si, eles sabem um pouco melhor...
2) Muito bem. Se estou interessado em processar um evento específico, e não todos os eventos no sistema, seria bom poder processar apenas este tipo de evento, deixando o processamento de outros eventos como normal.
3) Se o HandleNextEvent for chamado novamente durante o processamento - chamada e processo. A única coisa que pode acontecer é o transbordo de pilha, mas isto é problema do utilizador e do código, não do programador.
4) Os eventos que não se enquadram no filtro permanecem na mesma sequência e serão chamados quando o utilizador devolver o controlo ao sistema como habitualmente.

[fxsaber]

TheXpert:

os guiões não têm fila de eventos, porquê adicioná-los às muletas quando existem EAs e indicadores?

Aqui está um exemplo de um guião que abre e fecha as suas posições/ordens de forma assíncrona.

// Максимально быстро все закрывает. Возврат, когда действие подтверждено.
bool CloseAll()
{
  uint RequestID[];
  
  for (int i = ArrayResize(RequestID, OrdersTotal()) - 1; i >= 0; i--)
    if (OrderSelect(i, SELECT_BY_POS))
      // Отправили асинхронный приказ
      RequestID[i] = (OrderType() <= OP_SELL) ? OrderCloseAsync(OrderTicket(), OrderLots(), OrderClosePrice(), 100) : OrderDeleteAsync(OrderTicket());
  
  return(Transactions.Waiting(RequestID)); // Дождались ответа от сервера на все асинхронные приказы
}

[TheXpert]

Sergey Dzyublik:

1) O meu trabalho é sugerir, e se é ou não um dilema não é você que decide, mas para os criadores, eles sabem um pouco melhor...

Se sugerir algo que seja mais fácil de implementar, há uma maior probabilidade de implementação. remova a sua opção porque não dá quase nada.