Caractéristiques du langage mql5, subtilités et techniques - page 113

Nouveau commentaire
 
pavlick_:

Je ne vois pas pourquoi ma solution est pire, je la mets ici aussi :

Parce qu'il s'agissait à l'origine d'un spectacle "voyez comment je fais" et qu'il nécessitait exactement la solution qui avait été imaginée au préalable. Et le vôtre ne s'intégrait pas dans la production.

Mais même le directeur n'a pas tenu compte du fait que, selon la documentation, l'ordre de calcul des paramètres n'est pas garanti.

 
A100:

Mais même le directeur n'a pas tenu compte du fait que, selon la documentation, l'ordre de calcul des paramètres n'est pas garanti.

Pour être juste, la documentation de MQL le décrit :

Note

Vous devez vous rappeler que les paramètres sont transmis à la fonction à l'envers, c'est-à-dire que le paramètre le plus récent est calculé et transmis en premier, puis l'avant-dernier, et ainsi de suite. Le paramètre qui vient en premier après le crochet d'ouverture est calculé et transmis en dernier.

C'est certainement une folie du point de vue du C++, mais s'il s'agit d'une règle documentée dans MQL, cela peut être acceptable, si vous ne prévoyez pas de porter votre code à l'avenir. Et si c'est le cas, vous pouvez sécuriser cette place en vérifiant #ifdef __MQL__.

 
A100:

L'ordre dans lequel les paramètres sont calculés n'est pas garanti.

Je viens de prêter attention à votre lien. En effet, ce n'est pas garanti. Quel MQL contradictoire ;))

 
Alexey Navoykov:

Je viens de prêter attention à votre lien. En effet, ce n'est pas garanti là-bas. C'est le MQL controversé ;))

Sur x32 inversé (je pense que ça va sauver), car il y a un lien direct avec la pile. Alors que sur x64, l'inverse n'a aucun sens et c'est pourquoi il n'y a aucune garantie pour l'avenir... de plus, ça ne semble pas naturel ici

Je ne serai même pas surpris si l'ordre est différent avec et sans optimisation.

 

Pour toutes les options proposées, je tiens à dire merci. Vous avez contribué de manière constructive à la résolution d'un problème pratique.


La tâche a été bien démontrée qu'elle ne fonctionnerait pas si void TimeCurrent() échouerait. Le vide dans sa forme actuelle est capable de paralyser beaucoup de choses.

 

Je veux appeler la méthode parent

Voici le code, qu'est-ce que je fais 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:

Je veux appeler une méthode parent

la syntaxe correcte est la suivante :

b.A::Test_A()

mais dans le MQL, il n'y a ni bien ni mal.

Mais la question s'adresse davantage à vous : si une fonction doit être appelée à partir d'une fonction dérivée, pourquoi la mettre dans une fonction virtuelle de base ?

 

fxsaber:

La tâche a bien montré que si le void TimeCurrent() était appelé, rien ne fonctionnait. Le vide dans sa forme actuelle est capable de mutiler beaucoup de choses.

En un coup d'œil :

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

Deux macros ne semblent pas faire beaucoup de mal. Quelque chose de plus élégant, par la puissance de μl, ne me vient pas à l'esprit.

 
pavlick_:

En haut de ma tête :

Pourquoi faire... pendant ? Les accolades sont suffisantes.
 
Alexey Navoykov:
Pourquoi faire... pendant ? Les accolades sont suffisantes.

Pour que ça marche :

if(...)
   MACROSV(...);
else
{
}
1...106107108109110111112113114115116117118119120...247
Nouveau commentaire