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

 
TheXpert:

un casting dynamique pour la comparaison ? Vous avez perdu la tête ?

Je ne me préoccupe pas du temps d'exécution dans ce cas, le type peut être défini d'autres façons aussi, par exemple par une fonction de surcharge virtuelle. Le code a été écrit sur place en 10 minutes pour montrer le principe et n'est pas une variante fonctionnelle.

 
Ilya Malev:

Quel est l'intérêt de CBase ? Et pourquoi comparer 2 valeurs du même type ?

Oui, vous n'avez pas du tout besoin de CBase ici. Pour une raison quelconque, vous avez IComparer hérité de Number, bien qu'il s'agisse d'entités totalement différentes. Comparer n'est pas une interface pour Number, c'est un objet indépendant qui accepte deux nombres. Votre Comparer devrait donc être simplement IComparer<T1,T2>, sans Number ni CBase.
 
C'est ça, encore une merdeuse avec un ego.
 
La suffisance, c'est juste quand quelqu'un monte sur une branche et commence à jeter du caca. Un caca très important. J'ai simplement écrit au camarade (pas vous) avec lequel nous discutions du sujet des modèles, comment je vois une telle mise en œuvre.
 
Ilya Malev:

Vous avez donc une erreur sémantique : les notions Comparer et Comparable sont mélangées. La première est un comparateur (une classe indépendante), tandis que la seconde est une interface pour l'objet comparé (c'est-à-dire qu'elle le compare à un autre objet). Cet objet peut hériter de la classe

 
Alexey Navoykov:

Vous avez donc une erreur sémantique. Les notions de Comparer et de Comparable sont mélangées. La première est un Comparer (une classe indépendante) et la seconde est une interface avec l'objet comparé (c'est-à-dire qu'elle le compare à un autre objet).

Mon numéro est simplement le type Comparable, et l'interface est le type Comparer, et ils sont en quelque sorte intelligemment liés dans Sharp aussi. Dans ce cas, ils travaillent l'un par rapport à l'autre. Je vous le dis, ce n'était pas mon but de copier exactement cette structure là. Le but ici est de montrer comment on peut créer une interface basée sur un modèle qui est nécessairement héritée d'une des classes comparées. C'est le mécanisme que j'ai vu avec vous et j'ai aimé ça.

 
Alexey Navoykov:
Pour une raison quelconque, vous avez hérité de IComparer de Number, bien qu'il s'agisse d'entités absolument différentes.

J'ai numéroté ici par le type d'objet de la classe de base, enfin, très grossièrement, je ne me suis pas fixé comme objectif de présenter une architecture fonctionnelle en 100 lignes. Mais tout héritera d'un ancêtre commun de toute façon.

 
Ilya Malev:

Ici, ils travaillent l'un par l'autre.

Mais ce n'est pas le cas. Vous ne pouvez pas hériter d'entités différentes les unes des autres. Un numéro peut hériter de l'interface IComparable, et il peut également renvoyer IComparer pour son type avec une méthode distincte.
 
Alexey Navoykov:
Le nombre peut hériter de l'interface IComparable et il peut également retourner IComparer pour son type via une méthode distincte.

Le nombre n'est pas vraiment un nombre, il n'a même pas de champ de valeur si vous remarquez. Je l'ai juste appelé comme ça... D'accord, si quelque chose qui fonctionne pour moi peut fonctionner, je vous proposerai d'en discuter, mais en attendant, si mon exemple ne convient pas du tout, ne vous donnez pas la peine.

 
Ilya Malev:

Le nombre n'est pas vraiment un nombre, il n'a même pas de champ de valeur si vous remarquez. Je l'ai juste appelé comme ça... OK, si je trouve quelque chose d'utilisable, je vous proposerai d'en discuter, mais en attendant, si mon exemple ne fonctionne pas du tout, laissez-le de côté.

OK. Mais vous devriez penser aux méthodes abstraites. Sans elles, cela semble très peu fiable.
Raison: