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

Nouveau commentaire
 
Ilya Malev:

J'ai obtenu "stack overflow")

Je suppose que c'est un cafard après tout...

Eh bien, ce n'est pas le compilateur, mais à l'exécution. Et le compilateur devrait réagir.

Voici ce que j'ai essayé dans VS 2010 :

class A
 {
  public:
   virtual int f2() = 0;
 };

class B : public A
{
 public:
  virtual int f2() { return A::f2(); }
};

B b;

Je reçois une erreur de compilation : Erreur 1 erreur LNK2001 : unresolved external symbol "public : virtual __thiscall A::f2(void)".

Mais Metaeditor ne dira rien. Pas bon.

 
Il s'avère qu'appeler une fonction ancêtre avec = 0 revient à s'appeler soi-même. Si vous attrapez vous-même cette erreur, vous pourrez peut-être en tirer profit...
 
Alexey Navoykov:

C'est ainsi que le compilateur devrait réagir.

J'ai essayé cela dans VS 2010 :

Je reçois une erreur de compilation : Erreur 1 erreur LNK2001 : unresolved external symbol "public : virtual __thiscall A::f2(void)".

Metaeditor ne dira rien. Pas bon.

Alexey, explique-moi pourquoi, si mql est une copie de C, elle doit être absolument identique et un pas à gauche, un pas à droite - peloton d'exécution ?

Juste parce que les développeurs ont été négligents ? Mais tout langage est construit sur des boucles et des conditions. Tout le reste est dans le trailer. Pourquoi personne n'exige que tout autre langage soit similaire au C dans la partie OOP ou de toute autre manière ?

 
Alexey Viktorov:

Alexey, pouvez-vous m'expliquer sur vos doigts pourquoi si mql est comme C, alors il doit être absolument identique et un pas à gauche, un pas à droite - peloton d'exécution ?

Juste parce que les développeurs ont été négligents ? Mais tout langage est construit sur des boucles et des conditions. Tout le reste est dans le trailer. Pourquoi personne n'exige que tout autre langage soit similaire au C dans la partie OOP ou de toute autre manière ?

Il ne s'agit pas d'être complètement identique. Il s'agit d'une fonctionnalité qui, lorsqu'elle est mise en œuvre, doit fonctionner correctement et de manière cohérente. Mais d'abord vous criez : montrez-moi un autre langage qui fonctionne différemment. Et ensuite, lorsque le C++, qui fonctionne différemment (correctement), est donné en exemple, vous vous lancez dans une vieille diatribe sur le fait que MQL n'est pas C++ et ne devrait pas être identique. Vous devriez vous faire une raison
 
Alexey Viktorov:

Pouvez-vous nous montrer un exemple où tout cela peut faciliter l'écriture du code, le raccourcir ou au moins le protéger des erreurs ? Et s'il vous plaît, n'utilisez pas de fonctions abstraites, mais celles qui sont les plus proches des conditions réelles de trading dans un EA ou un indicateur.

Pas du tout. Les gars essaient juste de mettre leurs fantasmes en pratique.

 
Dmitry Fedoseev:

Pas du tout. Les gars essaient juste de transformer leurs fantasmes en réalité.

Il me semble que c'est un exercice très utile - faire passer le fantasme dans la réalité. C'est le but du développement !
Discussion très éclairante. (gloussements) : Merci.
 
Alexey Navoykov:

Oui, mais j'utilise depuis longtemps une autre option : toutes les interfaces sont conçues à l'origine comme une classe modèle intermédiaire :

De cette façon, vous pouvez créer une chaîne d'héritage composée d'un nombre quelconque de ces interfaces. Oui, bien sûr, vous ne pouvez pas faire de dynamic_cast avec eux, mais ce n'est pas si souvent nécessaire. La tâche principale est de les passer dans les fonctions.

Je l'ai lu attentivement, c'est une démarche intéressante, d'ailleurs. Je n'y avais pas pensé avant =) Je vais expérimenter aussi, à mon aise...

 
Nikolai Semko:
Pour moi, c'est un exercice très utile - pour étirer la fantaisie sur la réalité. C'est le but du développement !
Une discussion très éclairante. Merci.

Les développeurs nous ont entendus et ont décidé de corriger ce bug sur lequel tout le monde bute depuis des années.

Mais l'attitude destructrice de certains utilisateurs du forum est certainement surprenante - ils ne se développent pas eux-mêmes et essaient de gêner les autres avec une persistance remarquable.

 

>> Oui, bien sûr, vous ne pouvez pas faire de dynamic_cast avec eux, mais ce n'est pas un besoin si fréquent.

Pourquoi ne le faites-vous pas, sans problème ?) Mais alors votre principal cauchemar apparaît - la non-détection des erreurs de casting à l'étape de la compilation :)

 
Ilya Malev:

>> Oui, bien sûr, vous ne pouvez pas faire de dynamic_cast avec eux, mais ce n'est pas un besoin si fréquent.

Pourquoi ne le faites-vous pas, sans problème ?) Mais alors votre principal cauchemar apparaît - la non-détection des erreurs de casting à l'étape de la compilation :)

Après tout, la chaîne d'héritage pourrait être de n'importe quelle façon : Interface<CBase> ou Interface<C<B<A<CBase>>>>, il y a d'innombrables variantes. Nous devrions couler CBase de façon cohérente pour toutes les variantes possibles, ce qui n'est pas réaliste.

Je me souviens avoir envisagé d'implémenter le stockage d'informations sur les interfaces dans l'objet de classe lui-même, et en plus des tampons d'interface existants, de créer des classes d'interface indépendantes qui fonctionneraient comme une enveloppe sur notre tampon. Mais j'en suis venu à la conclusion que tout cela était inutile et superflu. En pratique, je n'ai jamais vu le besoin de caster une classe de base vers une interface, cela n'a tout simplement aucun sens. La seule option est de découvrir si la classe supporte cette interface à des fins de débogage, mais nous n'avons pas besoin de caster pour cela.

12345678910111213141516...28
Nouveau commentaire