Erros, bugs, perguntas - página 2746

Novo comentário
 
Koldun Zloy:

Não. Ainda não é conhecido no momento da compilação.

Então como é que ajuda a evitar um grande número de verificações quando o SymbolInfoTick é chamado dezenas de milhares de milhões de vezes?

 
fxsaber:

Então como é que ajuda a evitar um grande número de verificações quando o SymbolInfoTick é chamado dezenas de milhares de milhões de vezes?

Não tem. Só ajuda a não copiar desnecessariamente o fio em si.

 
Koldun Zloy:

Não. Só ajuda a não copiar desnecessariamente o fio em si.

Então, obviamente, a solução de referência de cordas para as funções SymbolInfo é a solução certa, se se quiser mais eficiência do Optimizer.

 

O meu depurador recusa-se a trabalhar num dos meus projectos. Além disso, o seu comportamento é difícil de prever. Por vezes apenas se recusa a entrar nos pontos de pausa. Recusa-se também a entrar em algumas funções. No início pensei que a razão era a actualização (talvez algo tenha corrido mal com a depuração). Mas em outros programas mais simples tudo parece funcionar. No entanto, não o verifiquei muito, porque estou a trabalhar no meu projecto principal. É bastante complexo e inclui apenas 15 módulos da minha própria concepção (não contei o número de módulos padrão). O módulo principal contém até 2000 linhas. Pensei que talvez seja tudo sobre a complexidade do projecto. Além disso, em alguns lugares, utilizo macros para trechos repetitivos de código. Também utilizo elementos padrão da IU, tais como CAppDialog, CCheckGroup, CComboBox, CButton, etc. que reescrevi para a funcionalidade do meu programa. Talvez a depuração não funcione por causa deles... Por exemplo, o método CCheckGroup::itemCheckState(const string item), que eu escrevi especificamente, não é depurado. O método encontra o item da caixa de verificação e verifica se está seleccionado (o seu Estado):

//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
int CCheckGroup::itemCheckState(const string item) {
  int total = m_strings.Total();
  
  if(total != m_states.Total())
    return -1;
    
  int i = 0;
  for(; i < total; i++) {
    if(m_strings.At(i) == item)
      return m_states.At(i);
  }
  
  return -1;
}

Este foi o tipo de IU com que acabei por ficar:

UI

Alguns dos elementos da IU são classificados temporariamente. E aqui está um ramo onde descrevi como eu superei os métodos Show() e Hide() do elemento CAppDialog:https://www.mql5.com/ru/forum/338301 O compilador queixou-se nesse momento e ocorreu um erro crítico.

No final, o projecto compila normalmente, o compilador não gera quaisquer erros. Mas a depuração falha e simplesmente não mostra a execução de alguns fragmentos de código, funções, métodos e assim por diante.

Tanto quanto sei, pode haver várias razões para isso.

  1. Código complicado do projecto, utilização de macros
  2. Código complicado utilizando elementos padrão da IU, tais como CAppDialog, CCheckGroup, CComboBox, CButton (para o qual também escrevi novos métodos e redefini alguns dos já existentes)
  3. Bugs de depuração relacionados com a nova construção (possível, improvável).

Informação sobre a construção e o sistema:

2020.05.21 09:35:09.325 Terminal MetaTrader 5 x64 build 2433 started for MetaQuotes Software Corp.

2020.05.21 09:35:09.326 Terminal Windows 10 build 14393, Intel Core i5-5200U @ 2.20GHz, 2 / 3 Gb memória, 61 / 380 Gb disco, IE 11, UAC, GMT+2

Quem teve problemas semelhantes com o depurador e qual poderia ser a razão?
 
fxsaber:

É óbvio, então, que uma solução de referência de cordas para as funções SymbolInfo é a solução certa, se se quiser mais eficiência do Optimizer.

Tudo é passado por referência de qualquer maneira. A diferença estava apenas na antiga MQL4. E não há verificações quando se lê um fio.
 
Alexey Navoykov:
Esta ligação não faz sentido, disse o criador. Tudo é passado pela ligação tal como está. A única diferença estava na antiga MQL4. E não há verificações ao ler o cordel.

É apenas cansativo fazer declarações como esta.

int f1( string Str )
{
  return((Str += Str) == Str);
}

int f2( string &Str )
{
  return((Str += Str) == Str);
}

int Bench1( const int Amount = 1 e8 )
{
  int Res = 0;
  string Str = NULL;
  
  for (int i = 0; i < Amount; i++)
    Res += f1(Str);
    
  Print(Res);
    
  return(Res);    
}

int Bench2( const int Amount = 1 e8 )
{
  int Res = 0;
  string Str = NULL;
  
  for (int i = 0; i < Amount; i++)
    Res += f2(Str);

  Print(Res);
    
  return(Res);    
}

void OnStart()
{
  BENCH(Bench1())
  BENCH(Bench2())

  BENCH(Bench1())
  BENCH(Bench2())
}


        100000000
        Time[Bench1()] = 727585
        100000000
        Time[Bench2()] = 657464
        100000000
        Time[Bench1()] = 794205
        100000000
        Time[Bench2()] = 670440
 
fxsaber:

É apenas cansativo fazer declarações como essa.


Talvez seja mais fácil de escrever:

int f1( string Str )
{
  return(Str == NULL || Str == "");
}

?...

Porquê beber algo do género?

int f1( string Str )
{
  return((Str += Str) == Str);
}
 
Mihail Matkovskij:

Pode ser mais fácil de escrever:

Há um tipo diferente de discussão.

 
fxsaber:

É apenas cansativo fazer declarações como esta.

Para evitar ser infundado, dê-me uma referência para testes em que a corda não muda.
 
TheXpert:
Para evitar ser infundado, dê-me uma referência para os testes em que a corda não muda.
int f1( const string Str )
{
  return(Str + "1" != Str);
}

int f2( const string &Str )
{
  return(Str + "1" != Str);
}
        10000000
        Time[Bench1()] = 334596
        10000000
        Time[Bench2()] = 338559
        10000000
        Time[Bench1()] = 384711
        10000000
        Time[Bench2()] = 344346
1...273927402741274227432744274527462747274827492750275127522753...3184
Novo comentário