Caratteristiche del linguaggio mql5, sottigliezze e tecniche - pagina 113

[A100]

pavlick_:

Non vedo perché la mia soluzione sia peggiore, la metterò anche qui:

Perché in origine era una performance "vedi come faccio io" e richiedeva esattamente la soluzione che era stata pensata in precedenza. E il tuo non si adattava alla produzione.

Ma anche il direttore non ha tenuto conto che secondo la documentazione l'ordine di calcolo dei parametri non è garantito

[Alexey Navoykov]

A100:

Ma anche il direttore non ha tenuto conto che secondo la Documentazione, l'ordine di calcolo dei parametri non è garantito.

Per essere onesti, la documentazione MQL lo descrive:

Nota

Dovete ricordare che i parametri vengono passati alla funzione al contrario, cioè, il parametro più recente viene calcolato e passato per primo, poi il penultimo, e così via. Il parametro che viene prima dopo la parentesi di apertura è calcolato e trasmesso per ultimo.

Questo è certamente folle dal punto di vista del C++, ma se è una regola documentata in MQL, potrebbe essere ok, se non avete intenzione di portare il vostro codice in futuro. E se lo fate, potete assicurare questo posto controllando #ifdef __MQL__.

[Alexey Navoykov]

A100:

L'ordine in cui i parametri sono calcolati non è garantito

Ho appena prestato attenzione al tuo link. Infatti, non è garantito. Che MQL contraddittorio ))

[A100]

Alexey Navoykov:

Solo ora ho prestato attenzione al tuo link. Infatti, non è garantito lì. Questo è il controverso MQL ))

Su x32 invertire (penso che salverà), perché c'è un collegamento diretto allo stack. Mentre su x64 non ha senso il contrario ed è per questo che non ci sono garanzie per il futuro... inoltre sembra innaturale lì

Non mi sorprenderà nemmeno se l'ordine è diverso con e senza ottimizzazione

[fxsaber]

Per tutte le opzioni offerte, vorrei dire grazie. Hai aiutato costruttivamente a risolvere un problema pratico.

Il compito era ben dimostrato che non avrebbe funzionato se void TimeCurrent() fallirebbe. Il vuoto nella sua forma attuale è in grado di paralizzare molte cose.

[Vladimir Pastushak]

Voglio chiamare il metodo padre

Ecco il codice, cosa sto sbagliando?

//+------------------------------------------------------------------+
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());
  }
//+------------------------------------------------------------------+

[TheXpert]

Vladimir Pastushak:

Voglio chiamare un metodo padre

la sintassi corretta è così:

b.A::Test_A()

ma in mql non c'è né giusto né sbagliato.

Ma la domanda è più per voi - se una funzione deve essere chiamata da una derivata, perché metterla in una funzione virtuale di base?

[pavlick_]

fxsaber:

Il compito ha mostrato bene che se il void TimeCurrent() è stato chiamato, niente funzionerebbe. Il vuoto nella sua forma attuale è in grado di mutilare molte cose.

A colpo d'occhio:

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

Due macro non sembrano fare molto male. Qualcosa di più elegante, per la potenza di μl, non mi viene in mente.

[Alexey Navoykov]

pavlick_:

Così su due piedi:

Perché fare...while? Le parentesi graffe da sole sono sufficienti.

[pavlick_]

Alexey Navoykov:
Perché fare...while? Le parentesi graffe da sole sono sufficienti.

Per farlo funzionare:

if(...)
   MACROSV(...);
else
{
}