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

Nouveau commentaire
 

Hier encore, nous discutions de ce problème avec les méthodes abstraites, mais aujourd'hui, j'ai rencontré le même problème dans mon code : j'avais une méthode virtuelle non abstraite dans la classe de base, à laquelle je faisais référence dans les classes héritées, puis j'ai décidé de rendre la méthode abstraite, mais le compilateur ne m'a pas informé qu'elle n'était plus référençable. En conséquence, l'erreur de récursion était la plus méchante et la plus difficile à détecter, et j'ai perdu beaucoup de temps. Maintenant, je pense que la fonction de corps de méthode abstraite par défaut sera très utile ici, au moins jusqu'à ce que ce bogue soit corrigé.

 
Alexey Navoykov:

Oui, pour qu'il soit aussi facile que possible d'assigner des mouches aux escalopes, et personne n'a sourcillé).

Si le processus d'affectation transforme des mouches en escalopes (ou produit une erreur si ce n'est pas possible), il n'y a pas de problème.

Alexey Navoykov:

Pourquoi déclarer un motif si son paramètre n'a aucun rapport avec le comportement de la classe ?

2) C'est trop de problèmes. Transfert du contrôle de type à l'étape de l'exécution... Vos codes prendront des années à déboguer

1. la "classe juste A" ne peut pas contenir un champ d'un type arbitraire sans sa paramétrisation (de classe). Et sans ces danses, que j'ai décrites, il est impossible de faire une manipulation uniforme d'un paramètre de classe par référence et par valeur.

2. Vous l'avez déjà comme un mantra - dans ce cas, un enregistrement absolument sans ambiguïté garantissant que F est T, c'est-à-dire comme s'il n'y avait aucun enregistrement du second modèle. mais non. Encore une fois "je vais passer des années à déboguer" ))))))

 
Ilya Malev:

1. "Juste la classe A" ne peut pas contenir un champ de type arbitraire sans son paramétrage (de classe). Et sans les bricolages que j'ai décrits, il est impossible de faire une gestion uniforme d'un paramètre de classe par référence et par valeur.

2. Vous l'avez déjà comme un mantra - dans ce cas, un enregistrement absolument sans ambiguïté garantissant que F est T, c'est-à-dire comme s'il n'y avait aucun enregistrement du second modèle. mais non. Encore une fois "je passerai des années à déboguer plus tard" ))))))

Et pourquoi répondez-vous dans ce fil ? Code à un endroit, discussion à un autre... )

1. Oui, tout peut être fait de manière humaine, et presque sans danse :

struct __A
{
  template<typename T>
  void f(T&) { }  // Сюда структуры и классы
};

struct A : __A
{
  template<typename T>  
  void f(T) { }  // Сюда простые типы и указатели
};

2. Ce n'est pas ce dont je parlais, mais peu importe.

 
Alexey Navoykov:

Pourquoi répondez-vous dans ce fil ? Code à un endroit, discussion à un autre... )

1. Oui, tout peut être fait de manière humaine, et presque sans danse :

2. Il y avait autre chose, mais ce n'est pas le sujet.

Ce n'est pas comme si vous étiez encore un modérateur, pour déterminer dans quel fil ce qui est plus approprié. Et les modérateurs ont déjà clairement indiqué que les discussions sur les fonctionnalités ne doivent pas se tenir dans la branche des fonctionnalités elles-mêmes, mais dans une branche séparée, c'est-à-dire ici.

Dans votre description, il n'est pas du tout clair comment se référer de manière uniforme à une méthode de classe par référence et par une valeur de type T. Je ne sais pas ce que vous entendez par là, mais c'est exactement ce que je voulais dire.

 
Ilya Malev:

Ce n'est pas comme si vous étiez encore un modérateur, pour déterminer quels fils sont plus appropriés. Et les modérateurs ont déjà clairement indiqué que la discussion sur les fonctionnalités ne devait pas avoir lieu dans la branche des fonctionnalités, et dans un fil séparé, c'est-à-dire ici.

Si un modérateur veut le déplacer, c'est une chose, mais pourquoi créer vous-même la confusion ? Je n'ai, par exemple, aucune envie de parcourir les fils de discussion.

 
Alexey Navoykov:

Si un modérateur veut le déplacer, c'est une chose, mais pourquoi créer vous-même la confusion ? Je n'ai, par exemple, aucune envie de parcourir les fils de discussion.

Si vous savez qu'un modérateur ferait une telle chose, il est toujours préférable de le faire vous-même plutôt que d'attendre qu'un modérateur le fasse. Cependant, discuter des actions des modérateurs n'est pas non plus l'un des menus préférés des modérateurs, il serait donc préférable d'y mettre un terme.

 
Alexey Navoykov:
Сюда простые типы и указатели

Pour les pointeurs, d'ailleurs, il est logique de créer une méthode distincte avec l'argument T*, car il n'y a absolument aucune confusion, et l'avantage est le plus souvent que la manipulation des pointeurs est différente de celle des types ordinaires (contrôle de validité, suppression, etc.).

 
Alexey Navoykov:

Code dans un endroit, discussion dans un autre

Voici le code :

template<typename T>
class A
 {
public:
  A* operator<<(T&p){ Print("<< &",typename(T)); return &this; }
  template<typename F>
  A* operator<<(F p){ Print("<< ",typename(F)); return &this; }
 };

En fait, il existe une autre solution que cette entrée : lister par nom tous les types simples passés par valeur et ensuite écrire une méthode de modèle avec &, alors il n'y aura pas d'erreur non plus. Cette option convient aux classes sans paramétrage intrinsèque.

 
Ilya Malev:

Si vous vous rendez compte qu'un modérateur ferait probablement exactement cela, il est toujours préférable de le faire vous-même, plutôt que d'attendre qu'un modérateur le fasse. Cependant, discuter des actions des modérateurs n'est pas non plus un menu favori des modérateurs, il serait donc préférable d'y mettre un terme.

Un modérateur ne diviserait certainement pas la discussion en plusieurs fils. Vous êtes probablement si désireux de vous bannir vous-même,"sans attendre qu'un modérateur le fasse" ;))
 
Ilya Malev:

Si vous vous rendez compte qu'un modérateur ferait probablement exactement cela, il est toujours préférable de le faire vous-même, plutôt que d'attendre qu'un modérateur le fasse. Cependant, discuter des actions des modérateurs n'est pas non plus un menu favori des modérateurs, il serait donc préférable d'y mettre un terme.

1. Il vaudrait mieux commencer tout de suite à parler de quelque chose, où se trouve ce "quelque chose", plutôt que de penser à la façon dont le modérateur s'y prendrait. Sinon, tout s'est vraiment brouillé en deux fils et maintenant, même si le modérateur décide que la discussion doit être là ou là, c'est une tâche assez laborieuse de déplacer la discussion normalement, en préservant l'ordre et le sens des messages.

2 Discuter des actions d'un modérateur n'est pas à la portée de tous... Ce n'est pas à chaque fois que vous éternuez, mais lorsque vous contestez publiquement leurs actions, que ce soit pour rétablir l'ordre ou apaiser les fauteurs de troubles. Et si vous avez une opinion, qui vous interdit de l'exprimer ? Peut-être que votre opinion est une suggestion très rationnelle, mais que vous avez peur de la dire, pour ne pas tomber dans le menu mal aimé du modérateur ? Donc c'est des conneries :)

1...67891011121314151617181920...28
Nouveau commentaire