Erros, bugs, perguntas - página 815

[Stanislav Korotky]

tol64:

Pode dizer-me por que razão ocorre um erro ao obter um manípulo indicador, se o nome do indicador a ser chamado está contido numa variável?

Não há erro nenhum como este:

É assim que obtemos o erro 4802 (Indicador não pode ser criado):

Leia sobretester_indicator aqui.

[Anatoli Kazharski]

marketeer:
Leia aqui sobreo indicador_teste.

Sim, eu já li e reli tudo muitas vezes. )) Mas não consegui obter o que precisava. E eu preciso de definir o nome do indicador para uma variável.

[Stanislav Korotky]

tol64:
Tenho lido e relido tudo uma e outra vez. )) Mas não consigo obter o que preciso. E eu preciso de definir o nome do indicador para uma variável.

Então, acrescentou o indicador de teste de propriedade? Acho que não o posso fazer sem ele.

[Anatoli Kazharski]

marketeer:
Então, adicionou o indicador de teste de propriedade? Não creio que o pudesse ter feito sem ele.

Eu tentei. Algo não funciona desta forma. Pode dar-me um exemplo (talvez o esteja a fazer mal)?

P.S. Funcionou. Não podia ser mais simples. Fora para descansar. ))

P.S2. Mas fico dependente do facto de ter de registar todos os indicadores através do indicador de teste_de_propriedade. Ou seja, se o nome do indicador for especificado por parâmetro externo e um utilizador tiver um novo indicador, temos de abrir novamente o código. Isto não é exactamente o que queremos.

[Stanislav Korotky]

tol64:

P.S2. Mas ainda temos a dependência de ter de escrever todos os indicadores através do property test_indicator. Ou seja, se o nome do indicador for especificado por parâmetro externo e um utilizador tiver um novo indicador, temos de abrir novamente o código. Isto não é exactamente o que queremos.

É feito em cinco. Utilizei-o para construir índices a partir de alguns outros índices seleccionados aleatoriamente. Talvez os criadores nos digam o que pensam sobre o assunto.

[Renat Fatkhullin]

marketeer:
É assim que se faz em cinco. Eu próprio a utilizei para construir índices a partir de vários outros índices seleccionados aleatoriamente. Talvez os criadores nos digam o que pensam sobre o assunto.

O problema é que as EAs no testador MT5 são lançadas fora do terminal e não têm todo o ambiente de biblioteca que estava no MT4.

Por exemplo, o Expert Advisor é enviado para a nuvem e, para passar ligações adicionais, temos de o fazer:

1. utilizar nomes indicadores estáticos nas chamadas, que permitem ao compilador prescrever automaticamente as dependências do perito
2. prescrever explicitamente através da propriedade a lista de indicadores necessários para construir manualmente a lista de dependências.

Se forem utilizadas chamadas de indicadores dinâmicos, é necessário prescrever manualmente a lista de indicadores utilizados. Ao executar um teste de terceiros, todos os ficheiros dependentes são enviados em conjunto com o Consultor Especialista. Estes podem ser tanto locais (de qualquer forma estão fora do terminal), como remotos ou agentes nebulosos.

Este é o preço a pagar para "carregar no início e não pensar em mais nada, tudo funciona automaticamente".

[Stanislav Korotky]

Renat:

A questão é que as EAs no testador MT5 funcionam fora do terminal e não têm todo o ambiente de biblioteca que o MT4 tinha.

Este é o preço a pagar para "carregar no início e não pensar em mais nada, tudo funciona automaticamente".

Isto é compreensível, mas, por outro lado, os utilizadores têm regularmente uma contra-opergunta, porque a habitual e eficaz flexibilidade foi perdida. De facto, apenas implementou um modelo de ligação estática. E as pessoas estão também a pedir uma ligação dinâmica. A ideia é que mesmo que algo seja enviado para a nuvem, comece a ser contado e de repente aceda a uma torre externa, pode consultá-la e recuperá-la de forma semelhante ao resto do ambiente, que é passado do terminal para o agente. Bem, é apenas um pensamento em voz alta. Eu não fiz esta pergunta ;-).

[mvk]

Esta questão pode já ter sido levantada, mas não a consegui encontrar no fórum.

No seguinte código (no método test(), ao tomar um descritor constante (referência) a um objecto e atribuí-lo a um não constante, o compilador (MetaEditor 5.00, Build 687) não gera um erro:

class A{
   public:
      void someDo() {}
};

class B{
   public:
      void B( A* aA ) : mA( aA ) {}
      const A* getA() { return (mA); }   
   private:
      A* mA;
};

void test(){
   A a;
   B b( GetPointer( a ) );

   //Ошибки нет. И это правильно   
   const A* a1 = b.getA();
   //Ошибка есть: "...someDo' - call non-const method for constant object..". И это правильно   
   a1.someDo();
   
   //Ошибки нет. Это НЕ правильно(CONST A* B::getA())!
   A* a2 = b.getA();
   //ошибки нет. Правильно (а2 не const)
   a2.someDo();
}

[---]

mvk:

Esta questão pode já ter sido levantada, mas ainda não a encontrei no fórum.

No código seguinte (no método test()), ao obter um descritor constante (referência) para um objecto e atribuí-lo a um não constante, o compilador (MetaEditor 5.00, Build 687) não gera um erro:

este seria o caso sem o erro.

class A{
   public:
      void someDo() const {};
};

[---]

pergunta aos criadores sobre a velocidade dos apontadores de objectos

Porque é que o primeiro código

class CSomeObj
{
public:
   double prm;
};

CSomeObj arr;

void OnStart()
{
        EventSetTimer(1);

        uint s0=GetTickCount();
        for (int i=0; i<100000000; i++) arr. prm=10;
        Print("1=", GetTickCount()-s0);
        
        s0=GetTickCount();
        CSomeObj *item=GetPointer(arr);
        for (int i=0; i<100000000; i++) item. prm=10;
        Print("2=", GetTickCount()-s0);
}

funciona duas vezes mais rápido do que o segundo?

2012.08.21 09:56:40 info (EURUSD,D1) 2=1654
2012.08.21 09:56:38 info (EURUSD,D1) 1=795

pode optimizá-lo para aumentar a velocidade?