OOP, templates et macros dans mql5, subtilités et utilisations - page 6

Nouveau commentaire
 
Alexey Viktorov:

C'est parti.

Donc tous vos codes sont faits sur des béquilles ? Il n'y a rien de personnel.
Oui, à peu près. Car MQL n'a pas de POO à part entière. De plus, il y a beaucoup de bugs, que je signale régulièrement, mais sans succès. Et je dois me défendre contre les bugs avec des béquilles, que puis-je faire ?
 

Voici comment nous procédons.

Si une variable statique est initialisée avec une constante, cette initialisation sera effectuée à l'étape d'initialisation globale, comme précédemment.
Dans le cas contraire (appel ou initialisation de variable), la variable statique sera initialisée sur la première référence (comme en C++), cette référence sera elle-même enveloppée dans une condition avec une variable/un drapeau global implicite, par exemple

pour le code MQL :

class CFoo { };

void func(bool f)
  {
   if(f)
     {
      static CFoo foo;
      foo.MakeMeHappy();
     }
  }

Le pseudo-code suivant sera généré

CFoo static_func_foo={}; // zeromem only
bool static_func_foo_init=false;

void func(bool f)
  {
   if(f)
     {
      if(!static_func_foo_init)
        {
         static_func_foo.CFoo();  // constructor call
         static_func_foo_init=true;
        }

      static_func_foo.MakeMeHappy();
     }
  }
 
Alexey Navoykov:

Vous devrez toujours les séparer d'une manière ou d'une autre dans la fonction.

Pas nécessairement et pas toujours. Je ne vous donnerai pas d'exemples, afin de ne pas encombrer le fil.

 
Ilyas:

Voici ce que nous allons faire.

Bonne nouvelle ! Les dieux ont entendu nos prières après tout).
 
Alexey Navoykov:
Oui, à peu près. Car MQL n'a pas de POO à part entière. De plus, il y a beaucoup de bugs, que je signale régulièrement, mais sans succès. Et contre les bugs, je dois me défendre avec des béquilles, que puis-je faire ?

Tu m'as embrouillé. Si dans ... lire vos mots

Forum sur le trading, les systèmes de trading automatisés et les tests de stratégie

Particularités de mql5, trucs et astuces

Alexey Navoykov, 2019.01.25 11:44

Si les paramètres sont de types différents, il est raisonnable de faire plusieurs méthodes surchargées avec les types correspondants. Vous devez de toute façon les partager dans les fonctions, donc il vaut mieux les diviser en fonctions séparées, que de faire un bazar, qui en plus prend un type impersonnel, c'est-à-dire que vous pouvez par erreur tout lui passer et obtenir une erreur de compilation à l'intérieur de la bibliothèque, ce qui n'est pas bon. Ou même ne pas l'obtenir, ce qui est doublement mauvais).

En bref, dans la POO à part entière, les fonctions de template sont une béquille (à quelques exceptions près).

Et il n'y a pas de POO à part entière dans MQL... Même les béquilles sont manquantes ? Je ne comprends rien du tout.
 
MQL est très bien avec la POO, et si l'héritage multiple est ajouté (au moins pour les interfaces, car elles sont inutiles dans leur forme actuelle), il sera parfait.
 
Ilya Malev:
MQL est OK avec la POO, s'ils ajoutent l'héritage multiple(au moins pour les interfaces, car elles sont inutiles dans leur forme actuelle), ce sera parfait.

Ainsi, les interfaces sont la base de la POO normale, et vous dites que tout va bien dans MQL.

 
Alexey Navoykov:

Les interfaces sont donc la base de la POO normale, et pourtant vous dites que tout va bien dans MQL.

La base de la POO normale est le polymorphisme, pas les interfaces. Les interfaces sont la base d'une certaine structure de classe. En général, j'aimerais beaucoup parler de ces sujets, mais j'ai bien peur que ce fil de discussion ne soit pas le bon endroit pour cela.

 
Ilya Malev:

La base de la POO normale est le polymorphisme, pas les interfaces. Les interfaces sont la base d'une certaine structure de classe. En général, je serais heureux de discuter de ces sujets, mais je crains que cette branche ne s'y prête pas.

Nous discutons des particularités du langage MQL et l'absence d'héritage multiple est un trait caractéristique).

D'accord, la base est bien sûr le polymorphisme, mais sans interfaces séparées, ce n'est pas pratique à utiliser. Cela conduit souvent à passer des objets comme arguments de modèle au lieu d'interfaces.

J'ai décrit ici ma variante de simulation d'interfaces multiples. Par conséquent, une classe peut être déclarée comme suit

class A : public Interface1<Interface2<Interface3<CBase>>>
{
 ...
};
 
Alexey Navoykov:

Nous discutons des particularités du langage MQL et l'absence d'héritage multiple est une particularité).

Ok, la base est certainement le polymorphisme, mais sans interfaces séparées, ce n'est pas pratique à l'usage. Cela conduit souvent à passer des objets comme arguments de modèle au lieu d'interfaces.

J'ai décrit ma variante de l'imitation de plusieurs interfaces ici. En conséquence, une classe peut être déclarée comme telle :

À mon avis, tout n'est pas mauvais. Il n'y a pas tant d'interfaces principales de base en C# que leurs méthodes ne puissent être réduites à une superclasse de base, puis héritées.

P.S. Mettre en œuvre quelque chose de multiple à travers des constructions comme <<<<>>>> est un peu casse-gueule. Il est préférable d'utiliser des opérateurs pour les fonctions, par exemple, a==b appelle a.compareto( b ), a[comparer]==b appelle comparer.compare(a,b), etc.
12345678910111213...28
Nouveau commentaire
Raison: