Erros, bugs, perguntas - página 2748

[Mihail Matkovskij]

Sergey Dzyublik:

Isso é muito texto, não o li todo.
Mas se tiver algo a funcionar em versão debug e ainda não estiver a funcionar em versão debug, ou vice-versa, então verifique se todas as variáveis e campos, especialmente em classe/estrutura, foram inicializados.

Os dados que precisavam de ser inicializados, eu inicializei. E se alguns dados aleatórios estiverem lá, provocará um erro no próprio programa (por exemplo, Array fora de alcance ou Invalid pointer). Pelo menos, não afectará o funcionamento do depurador. E ajuda a encontrar tais insectos.

[Sergey Dzyublik]

Mihail Matkovskij:

Talvez tenha este defeito:

(não corrigido por ME5(build 2390)) ** (novo) Debuger, StepInto (F11) e breakpoints instalados não funcionam.

[Mihail Matkovskij]

TheXpert:
Talvez a sua estrutura de ficheiros seja tão complexa que o depurador não consiga associar um ponto de ruptura, então o problema é do depurador.

Penso que a estrutura do ficheiro dos elementos padrão da IU que utilizo no meu projecto é ainda mais complexa do que o meu trabalho. Teria de trabalhar muito para fazer algo assim. Mas tal como está, toma-o e utiliza-o, como se costuma dizer. Se juntar tudo, como no meu caso. Depois, de facto, obtém-se algo complicado. Mas para a execução de programas é bastante normal.

[Roman]

fxsaber:

Inicialmente, isto foi trazido à baila.

Numa determinada fase, não só a parte relativa do tempo despendido se torna importante, mas também a parte absoluta.

Habitue-se a atribuir variáveis em C durante algum tempo, e é um bom hábito fazê-lo.

Na primeira função personalizada, a estrutura de entrada MqlTick é passada directamente para a função MQL, sem qualquer alocação de memória.
A esta entrada chama-se má codificação.

bool GetCurrentTick1( MqlTick &Tick )
{
  return(SymbolInfoTick(_Symbol, Tick));
}

No segundo exemplo, a variável CurrentTick é criada; a memória é atribuída para ela.
E esta entrada é considerada mais correcta.
Uma vez que a memória já está atribuída, os dados de entrada são processados mais rapidamente, sem custos desnecessários.

bool GetCurrentTick2( MqlTick &Tick, const bool NewTick = false )
{
  static MqlTick CurrentTick;
  
  if (NewTick)
    SymbolInfoTick(_Symbol, CurrentTick);
  
  Tick = CurrentTick;
  
  return(true);
}

[TheXpert]

Roman:

Se obtiver um pouco mais de C, terá o hábito de alocar variáveis.

Siga os seus próprios conselhos e poderá ter pelo menos a mais pequena ideia de atribuição.

[Alexey Navoykov]

Roman:

...

E esse registo é considerado mais correcto.

Contado por quem? Poderia pelo menos dar-nos primeiro as medidas de velocidade.

[Sergey Dzyublik]

Alexey Navoykov:

Quem está a contar? Podia pelo menos dar-me uma medida de velocidade para começar.

Demasiada atenção para um troll.

[Roman]

TheXpert:
Se seguir os seus próprios conselhos, poderá ter pelo menos um vislumbre de atribuição.

Por alocação, referia-me à alocação de memória.
Não nesse sentido literal como uma classe.
Uma função definida pelo utilizador tem o seu próprio alcance.

[Roman]

Alexey Navoykov:

Quem conta? Deve, pelo menos, dar algumas medidas de velocidade para começar.

Na página anterior, fxsaber deu as medidas.
Expliquei porque acontece desta forma.
Alocar sempre memória, de forma estática ou dinâmica.

[Mihail Matkovskij]

Sergey Dzyublik:

Talvez tenha este defeito:

(não corrigido por ME5(build 2390)) ** (novo) Depurador, StepInto (F11) e breakpoints instalados não funcionam.

É possível... Experimentei o método CCheckGroup::itemCheckState(const string item) que descrevi acima. E no início o depurador vai lá. Mas uma vez que sai e pronto, o depurador já não o vê e nenhum ponto de ruptura ou "Passo com entrada" funciona. Bem, teremos de nos contentar com Print() e Alert() temporariamente.