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
Actuellement, je voudrais attacher un formulaire VS à une .dll à MT5 d'une manière simple )))). - Je veux intégrer les gestionnaires de clics de boutons dans une classe et les appeler en parcourant un tableau de pointeurs de fonctions de gestionnaires, et je veux avoir dans le code principal de l'EA la possibilité d'écrire les mêmes noms de fonctions que dans VS, c'est-à-dire button2_Click() ....button2_Click()
SZY : C'est un problèmeEOP))))
Ne le prenez pas mal, mais ça me rappelle beaucoup de choses :
- Créer des structures automatiques dans une POO dynamique est un non-sens
Donc empiler des objets : myclass obj ; est un non-sens ? Alors je suis un handicapeur :)
Donc, la pile d'objets : myclass obj ; est un non-sens ? Donc, je suis un artisan :)
Il y a toutes sortes de tâches. Vous pouvez pratiquer la rhétorique pendant longtemps, si vous ne décrivez pas de tâches spécifiques, vous pouvez inventer n'importe quoi...
Oui, les objets "empilables" (automatique vous voulez dire ?) sont fondamentalement un non-sens. A mon humble avis, qui n'est en aucun cas la vérité et certainement pas en dernière instance...Vous voulez un objet qui ne remplit pas la fonction principale de la POO - la propriété de polymorphisme? Vous n'affecterez pas à une telle variable un objet ayant des propriétés différentes en fonction de son contenu. Vous ne pourrez pas du tout faire correspondre un autre objet à cette "variable" de la liste. Pourquoi avoir besoin d'objets ? Ne vaut-il pas mieux utiliser des structures à la place ? Peut-être parce que les structures µl ne peuvent pas renvoyer de références à elles-mêmes... Et avec eux commence une période sombre de création-destruction-autocopie constante, etc.
Comment vivre sans polymorphisme ... Et si je dis que nous pouvons nous passer du polymorphisme dans >90% des cas ? Prenez le "principe d'inversion de dépendance SOLID", si nous sommes de bons progers, nous devrions créer des abstractions, des méthodes virtuelles partout (ce qui entraîne des frais généraux élevés, bien sûr). Les adeptes du C# écriraient quelque chose comme ceci https://pro-prof.com/forums/topic/dependency-inversion-principle. Ou nous pourrions prendre des modèles et écrire quelque chose comme :
public:
void activate();
void deactivate();
};
template <typename T>
class Button {
Button(T& switchable)
: _switchable(&switchable) {
}
void toggle() {
if (_buttonIsInOnPosition) {
_switchable->deactivate();
_buttonIsInOnPosition = false;
} else {
_switchable->activate();
_buttonIsInOnPosition = true;
}
}
private:
bool _buttonIsInOnPosition{false};
T* _switchable;
}
int main() {
Lamp l;
Button<Lamp> b(l)
b.toggle();
}
Button est également indépendant des détails, sans tout le polymorphisme et les interfaces. Le polymorphisme a sa propre niche, mais elle est beaucoup plus étroite qu'on ne le dit.
ZS : Eh bien, personne ne l'interdit :
ZS : Eh bien, personne ne l'interdit :
Personne n'interdit toutes sortes de béquilles et de schematosis, mais pourquoi ? Par exemple : ce sera amusant lorsque votre auto-objet s'autodétruira soudainement au moment où vous vous y attendrez le moins, n'est-ce pas ?
Personne n'interdit d'inventer des béquilles et des schémas, mais pourquoi ? Par exemple : ce sera drôle lorsque votre auto-objet se détruira soudainement au moment où vous vous y attendrez le moins, n'est-ce pas ?
Parce qu'un objet de la pile est beaucoup plus rapide qu'un objet du tas (allocation de mémoire). L'autodestruction ? - C'est quelque chose de nouveau :). Mais cela est parfois nécessaire, bien sûr - le nombre d'objets n'est connu qu'au moment de l'exécution, par exemple.
ZS : vous pouvez être plus à l'aise autrement, c'est une question personnelle.
L'intérêt de la POO n'est pas d'utiliser la méthode que vous avez choisie pour appuyer sur le bouton, que vous pouvez tout aussi bien mettre en œuvre par le biais de modèles ou de pointeurs de fonction, mais simplement d'appliquer à n'importe quel objet du système des méthodes telles que list, qui permettent de s'auto-organiser en structures de liste et de créer des sélections arbitraires au bon moment sans aucune béquille comme CArrayObj, etc. et les tracas associés, en surchargeant des méthodes comme Select, Query, Compare, Sort, etc. (et même Clone/Copy, lorsque chaque objet peut décider sans votre participation s'il doit être copié dans une liste/un tableau ou non, et s'il doit être copié, comment).
J'ai écrit - le polymorphisme a sa propre niche, je ne le conteste pas. Mais la pratique montre (la mienne en tout cas) que ce n'est pas si important. Je suis beaucoup plus enclin à résoudre les problèmes avec des modèles.