Bogue de compilation avec le paramètre template = void* - page 18

Nouveau commentaire
 
Igor Makanu:

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 :


1
 
Ilya Malev:

- 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 :)

 
pavlick_:

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...
 
Un joker a besoin d'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.
 
Ilya Malev:
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 :

class Lamp {
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 :

derived1 obj1;
baseclass *p1 = &obj1;
derived2 obj2;
baseclass *p2 = &obj2;
pass_through_generalized_algoritm(p1);
pass_through_generalized_algoritm(p2);
 
Bien sûr, on peut se passer du polymorphisme, mais pour ce cas, il est beaucoup plus honnête et logique d'utiliser des structures simples plutôt que des objets, sinon on cloue avec un microscope. Pour être plus précis, dans le cas de µl5 nous contournons plutôt les "caractéristiques d'implémentation" qui ne permettent pas d'utiliser pleinement les structures non-objets (impossibilité de leur passer des pointeurs, contrairement aux objets). C'est un problème entièrement différent, ce n'est plus OOP, mais juste OO
 
pavlick_:

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 ?

 
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 est copié, comment il doit être copié).
 
Ilya Malev:

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.

 
Ilya Malev:
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.

1...11121314151617181920
Nouveau commentaire