Erros, bugs, perguntas - página 1953

[fxsaber]

Alexey Navoykov:

Em geral, admito com pesar que o compilador MQL não é tão inteligente como eu pensava que era). Eu até diria que não é nada inteligente. ) Tentei fazer alguns exemplos simples e descobri que mesmo que eu crie um objecto fictício, que não é usado em lado nenhum e não faz nada, o compilador não se importa com isso. Não está de todo optimizado. Estou a julgar apenas pela velocidade. E por alguma razão funciona mais lentamente em construções novas do que nas antigas.

Os criadores estão cientes disto. Mas tal optimização pelo compilador está longe de ser a prioridade das tarefas a serem resolvidas.

Existem também tais ambiguidades do compilador.

[Alexey Navoykov]

fxsaber:

Os criadores estão cientes disto. Mas tal optimização pelo compilador está longe de ser uma prioridade de tarefas a serem resolvidas.

Sim, mas é simplesmente espantoso: eles vangloriaram-se tanto aqui anteriormente que elevaram a qualidade do optimizador a alturas sem precedentes, mas na verdade não conseguem lidar com coisas tão simples. Quanto mais os mais complexos.

[Alexey Navoykov]

fxsaber:

É por isso que proponho acrescentar ao OnTesterInit a capacidade de alterar a tabela de passes padrão:

int PassesSet( const int Index, const MqlParam& Parameters[] );

Assumo que os próprios conjuntos de parâmetros não são armazenados no sistema, mas são calculados pelo número único da combinação (agora coincide com o número de passe). Portanto, só é possível alterar a ordem das combinações, mas não a sua composição. Assim, neste caso, seria algo como SwapPasses(long index1, long index2).

Mas posso estar enganado.

[fxsaber]

Alexey Navoykov:

Presumo que os próprios conjuntos de parâmetros não são armazenados no sistema, mas são calculados utilizando um número de combinação único (agora coincide com o número de passe). Portanto, só se pode alterar a ordem das combinações, mas não a sua composição. Ou seja, neste caso seria algo como SwapPasses(long index1, long index2).

Este pode ser o caso. Agora a ordem ainda pode ser de alguma forma influenciada por linhas de entrada Swap na fonte EA.

[Stanislav Korotky]

fxsaber:

Este pode ser o caso. Agora a ordem pode ser de alguma forma influenciada por linhas de entrada Swap no código fonte EA.

Mata o algoritmo de optimização - é como optimizar na direcção aleatória.

[fxsaber]

Stanislav Korotky:

Isto mata o algoritmo de optimização - é como optimizar numa direcção aleatória.

Em primeiro lugar, estamos a falar de uma ultrapassagem total.

[[Excluído]]

Estou a aprender lentamente o OOP e deparei-me com uma coisa não óbvia.

Existe uma classe A, cujos campos são objectos de outra classe B.

Na classe A, chama-se um método constante que devolve um objecto da classe B.

Depois disso, é chamado um método de classe B, que elimina parâmetros do objecto devolvido.

Parece ser assim (o exemplo é simplificado, escrito no browser):

class B
{
private:
   int m_width;
   int m_length;
public:
   void Reset() { m_width = 0; m_length = 0; }
}
class A
{
private:
   B m_member;
public:
   B GetBMember() const { return( m_member ); }
}
//---
A obj;
obj.GetBMember().Reset();

O resultado é que Reset() não funciona, ou seja, os campos m_member não são limpos.

Pergunta: o compilador não deveria reportar (erro/aviso) no momento da construção que um método não constante para um objecto constante está a ser chamado (ou algo do género)?

[Sergey Dzyublik]

Alexey Kozitsyn:

Pergunta: o compilador não deveria relatar (erro/aviso) no momento da construção que um método não constante está a ser chamado para um objecto constante (ou algo do género)?

Talvez a razão seja uma chamada implícita do construtor de cópias como resultado da chamada deReset para um objecto temporário.

[[Excluído]]

Sergey Dzyublik:

Talvez a razão seja uma chamada implícita do construtor de cópias como resultado da chamada deReset para um objecto temporário.

Obrigado. Provavelmente tem razão, e o especificador const const não afecta o resultado (não ocorre nenhum reset com e sem ele).

[Andrey Barinov]

Alexey Kozitsyn:

Estou a aprender lentamente o OOP e deparei-me com uma coisa não óbvia.

Existe uma classe A, cujos campos são objectos de outra classe B.

Na classe A, chama-se um método constante que devolve um objecto da classe B.

Depois disso, é chamado um método de classe B, que elimina parâmetros do objecto devolvido.

Parece ser assim (o exemplo é simplificado, escrito no browser):

O resultado é que Reset() não funciona, ou seja, os campos m_member não são limpos.

Pergunta: não deveria o compilador reportar (erro/aviso) no momento da construção que um método não constante para um objecto constante está a ser chamado (ou algo do género)?

Indicadores de retorno.

class B
{
private:
   int m_width;
   int m_length;
public:
   void Reset() { m_width = 0; m_length = 0; }
}
class A
{
private:
   B m_member;
public:
   B * GetBMember() const { return( & m_member ); }
}
//---
A obj;
obj.GetBMember().Reset();