OOP, templates et macros dans mql5, subtilités et utilisations - page 9
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
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 :
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.
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, 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 ?
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.
Pas du tout. Les gars essaient juste de transformer leurs fantasmes en réalité.
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...
Pour moi, c'est un exercice très utile - pour étirer la fantaisie sur la réalité. C'est le but du développement !
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 :)
>> 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.