Características da linguagem mql5, subtilezas e técnicas - página 113

Novo comentário
 
pavlick_:

Não vejo porque é que a minha solução é pior, vou colocá-la aqui também:

Porque era originalmente um desempenho "ver como o faço" e exigia exactamente a solução que tinha sido pensada de antemão. E o seu não cabia na produção.

Mas mesmo o director não teve em conta que, de acordo com a documentação, a ordem de cálculo dos parâmetros não é garantida

 
A100:

Mas mesmo o director não teve em conta que, de acordo com a Documentação, a ordem de cálculo dos parâmetros não está garantida.

Para ser justo, a documentação MQL descreve isto mesmo:

Nota

Deve lembrar-se que os parâmetros são passados para a função ao contrário, ou seja, o parâmetro mais recente é calculado e passado primeiro, depois o penúltimo, e assim por diante. O parâmetro que vem primeiro após o parêntese de abertura é calculado e transmitido por último.

Isto é certamente uma loucura do ponto de vista do C++, mas se for uma regra documentada em MQL, pode não haver problema, se não planear portar o seu código no futuro. E se o fizer, pode assegurar este lugar verificando #ifdef __MQL__.

 
A100:

A ordem em que os parâmetros são calculados não é garantida

Acabei de prestar atenção à sua ligação. Na verdade, não é garantida. Que MQL contraditório )

 
Alexey Navoykov:

Há pouco prestou atenção à sua ligação. De facto, não está garantido lá. É o controverso MQL ))

No x32 reverso (penso que vai poupar), porque existe uma ligação directa à pilha. Enquanto em x64 não há sentido no sentido contrário e é por isso que não há garantias para o futuro... além disso, não parece natural lá

Nem me surpreenderei se a encomenda for diferente com e sem optimização

 

Por todas as opções oferecidas, gostaria de dizer obrigado. Tem ajudado construtivamente a resolver um problema prático.


A tarefa ficou bem demonstrado que não iria funcionar se nulo TimeCurrent() falharia. O vazio, na sua forma actual, é capaz de aleijar muitas coisas.

 

Quero chamar o método dos pais

Aqui está o código, o que estou a fazer mal ?

//+------------------------------------------------------------------+
class A
  {
public:
   virtual int Test_A()
     {
      return 100;
     }
  };
//+------------------------------------------------------------------+
class B :public A
  {
public:
   virtual int Test_A()
     {
      return 200;
     }
  };

B b;
//+------------------------------------------------------------------+
void OnStart()
  {
   Comment (A::b.Test_A());
  }
//+------------------------------------------------------------------+


 
Vladimir Pastushak:

Quero chamar um método parental

a sintaxe correcta é como esta:

b.A::Test_A()

mas em mql não há nem certo nem errado.

Mas a questão é mais para si - se uma função precisa de ser chamada a partir de uma derivada, porquê colocá-la numa função virtual de base?

 

fxsaber:

A tarefa mostrou bem que se o nulo TimeCurrent() foi chamado, nada iria funcionar. O vazio, na sua forma actual, é capaz de mutilar muitas coisas.

Num relance:

#define  MACROSV(NEW_HANDLE_, VOIDFN_) \
do{                                   \
   int prev=GetHandle();              \
   if(SelectHandle(NEW_HANDLE_))      \
      VOIDFN_;                        \
   SelectHandle(prev);                \
}while(false)

Duas macros não parecem doer muito. Algo mais elegante, pelo poder de μl, não me vem à mente.

 
pavlick_:

Fora do topo da minha cabeça:

Porquê fazer...enquanto...só o aparelho encaracolado é suficiente.
 
Alexey Navoykov:
Porquê fazer...enquanto...só o aparelho encaracolado é suficiente.

Para que funcione:

if(...)
   MACROSV(...);
else
{
}
1...106107108109110111112113114115116117118119120...247
Novo comentário