Questions des débutants MQL5 MT5 MetaTrader 5 - page 192

Nouveau commentaire
 

J'ai commencé à apprendre la programmation opérationnelle et je n'arrive pas à surmonter l'obstacle suivant. Le script suivant est un exemple :

CSum result;
void OnStart()
  {
//---
  }
//+----------------------------------------+
class CSum
  {
public:
   int               Calculate(int A,int B);
  };
//---
int CSum::Calculate(int A,int B)
  {
   return(A+B);
  }

Sans la ligne "CSum result ;", le compilateur ne générera pas d'erreur. Mais cela provoque une erreur :

Dites-moi ce qui ne va pas. Il semble que j'ai déclaré l'objet de la classe correctement.

 
paladin800:

J'ai commencé à apprendre la programmation opérationnelle et je n'arrive pas à surmonter l'obstacle suivant. Le script suivant est un exemple :

Sans la ligne "CSum result ;", le compilateur ne générera pas d'erreur. Mais cela provoque une erreur :

Dites-moi ce qui ne va pas. Il semble que j'ai déclaré l'objet de la classe correctement.

Une variable du type CSum (résultat) est déclarée avant que la description du CSum ne soit faite, ce qui signifie que le compilateur ne connaît pas encore ce type. Insérez CSum au tout début du fichier.
 
Lone_Irbis:
Par ailleurs, dans quelle mesure le système de variables globales peut-il/doit-il être exploité ? Est-il possible de surcharger quelque chose de cette manière, ou y a-t-il une limite ? Par exemple, disons deux ou plusieurs centaines de variables (dont environ la moitié se transforment en entrée et en sortie, selon le morceau de code à tester) et environ une douzaine et demie de petits tableaux au niveau global - est-ce beaucoup ou peu ? ^^' Et s'il y en a deux ou trois fois plus au fur et à mesure que vous peaufinez le système ? Et si nous ne devons pas nous emballer, existe-t-il un moyen plus simple de gérer l'échange de données entre une douzaine de sous-systèmes différents, dont beaucoup ont besoin des résultats des autres ?
Non, il n'y en a pas. Les variables globales sont utilisées à d'autres fins. Utilisez des classes pour décrire les sous-systèmes. Et vous feriez mieux d'éviter complètement d'utiliser les tableaux et les variables globales.
 
C-4:
Une variable de type CSum (résultat) - est déclarée avant la description du CSum, ce qui signifie que le compilateur ne connaît pas encore ce type. Insérez CSum au tout début du fichier.
Oups, ça a marché. Je place la classe à la fin du code par analogie avec le placement des fonctions. Je ne m'attendais pas à ce que, pour une classe, une telle commande fasse la différence.
 
paladin800:
Oups, ça a marché. Je place la classe à la fin du code, de façon similaire au placement des fonctions. Je ne m'attendais pas à ce qu'une telle commande fasse une différence pour la classe.
Oui, malheureusement, l'ordre de préséance a de l'importance. Le cas le plus difficile est celui où deux classes s'utilisent simultanément. Quelle que soit la classe que nous introduisons en premier, la deuxième classe sera inconnue du compilateur et générera une erreur. Dans ce cas, vous ne pouvez pas vous passer de la déclaration de classe. Dans votre cas, il est préférable de séparer CSum dans un fichier séparé, par exemple Sum.mqh et de l'inclure en utilisant la dictée #include "Sum.mqh".
 
C-4:
Non, tu ne devrais pas. Les variables globales sont utilisées à d'autres fins. Utilisez des classes pour décrire les sous-systèmes. Et il est préférable de ne pas utiliser du tout les tableaux et les variables globales.
Bien sûr, je comprends que c'est une bonne idée d'utiliser des classes, mais je suis quand même un peu paresseux, vu que c'est plus familier sans elles, et qu'elles semblent fonctionner dans tous les cas. Mais je suis juste curieux, quel est leur avantage ? Pour autant que l'on sache avec certitude que le code est écrit par un auteur exclusivement pour lui-même et qu'il ne sera jamais utile en dehors d'un programme particulier ? Il m'a toujours semblé que les cours n'avaient de sens que si l'on écrivait pour quelqu'un/quelque chose/vendre, alors que pour soi-même, en tant que hobby, cela ne fait pas grande différence. En dehors de l'esthétique et du "moins bien" général, y a-t-il un sens pratique à s'impliquer dans toutes ces classes-structures ? La vitesse ? Autre chose ?
 
Lone_Irbis:
Bien sûr, je comprends qu'il serait agréable de s'occuper des classes, mais je suis encore trop paresseux, considérant qu'il est plus familier sans elles, et qu'elles semblent fonctionner de toute façon. Mais je suis juste curieux, quel est leur avantage ? Pour autant que l'on sache avec certitude que le code est écrit par un auteur exclusivement pour lui-même et qu'il ne sera jamais utile en dehors d'un programme particulier ? Il a toujours semblé que les cours n'ont de sens que si vous écrivez pour quelqu'un/quelqu'un d'autre/vendu, alors que pour vous-même en tant que hobby, cela ne fera pas grande différence. En dehors de l'esthétique et du "moins bien" général, y a-t-il un sens pratique à s'impliquer dans toutes ces classes-structures ? La vitesse ? Quelque chose d'autre ?

Au contraire. Lorsque vous écrivez un projet personnalisé, le client demande souvent le code source. Ensuite, vous devez extraire les fonctions des classes et les insérer dans le code source. Il est préférable de donner au client un seul fichier plutôt que de glisser une montagne de vos bibliothèques, qui contiennent un nombre énorme de fonctions, qui ne sont pas utilisées dans le travail transmis au client. C'est-à-dire qu'il est préférable d'utiliser la programmation structurée à la demande.

Pour vos propres besoins, il est préférable d'utiliser la POO - tout y est autosuffisant et vous n'avez pas à vous soucier de transmettre le code source.

 
artmedia70:

Au contraire. Lorsque vous écrivez un projet personnalisé, le client demande souvent le code source. Ensuite, vous devez extraire les fonctions des classes et les insérer dans le code source. Il est préférable de donner au client un seul fichier plutôt que de glisser une montagne de vos bibliothèques, qui contiennent un nombre énorme de fonctions, qui ne sont pas utilisées dans le travail transmis au client. C'est-à-dire qu'il est préférable d'utiliser la programmation structurée pour un client.

Il est préférable d'utiliser la POO pour vos propres besoins - tout votre matériel est là, et vous n'avez pas à vous soucier de transférer le code source.

Hmmm... Eh bien, peut-être que oui :) C'est, bien sûr, le principe qui semble tentant... en théorie. Surtout en tenant compte du fait que je ne peux pas faire un seul fichier sans aucune structure ou classe. En fait, j'écris surtout par intérêt, pour tester mes propres théories aléatoires et inventer des bicyclettes sans fin. En parallèle, je n'étudie que ce qui commence à être nécessaire pour mettre en œuvre l'idée. Tout cela se passe dans le cadre d'un seul conseiller expert expérimental et d'apprentissage - initialement un simple martin, mais maintenant c'est plutôt un scalper multifonctionnel en herbe (et déjà théoriquement rentable). Donc, à un moment donné, le robot est devenu trivialement trop gros. >Alors que je passais la plupart du temps à faire défiler la roue de la souris à la recherche du bon morceau de code, j'ai eu l'idée "géniale" d'en faire des fichiers séparés (13 parties connectables pour le moment), en regroupant simplement les fonctions par leur concept général. Par exemple, l'analyseur syntaxique des nouvelles ici, le traitement des niveaux là, un autre avec les contrôleurs moose, les statistiques séparément, etc. Mais à cette époque, mon enthousiasme pour la POO n'était pas suffisant...

Mon problème semble être que j'attrape toutes les idées qui me viennent à l'esprit et que je les complète sur un robot existant d'une manière plutôt... séquence chaotique. Le résultat est plutôt bizarre, avec toutes sortes d'interrupteurs et de combinaisons de modes, dont beaucoup sont laissés en suspens. Le tout est complété par cent cinquante variables globales, qui doivent être supprimées des entrées, juste pour ne pas prendre trop de temps, étant imprimées dans le visualiseur du testeur au début. Plus, bien sûr, des montagnes de déchets et des rudiments d'idées abandonnées ou remaniées.

Et il semble que ce soit le bon moment pour trier tout ce tas d'ordures et tout mettre en classes (et d'abord lire au moins un article sur la POO sans s'endormir en cours de route)... Mais je suis troublé par la quantité de travail à accomplir et, ahem, par sa relation avec le sens potentiel de toute cette affaire. C'est pour conclure tout en classes - il semble que la tâche ne soit pas si volumétrique... Mais cela aurait-il un sens, si, par exemple, on déverse tout d'un coup dans le public, en ignorant tous ces privés/protégés ? En quoi est-ce mieux que d'avoir un dossier contenant un tas de .mph et une douzaine de fonctions communes chacun, s'ils finissent tous dans un seul robot de toute façon ?

 
Lone_Irbis:

Je vous conseille de créer un modèle unique, qui comporte déjà toutes les étapes nécessaires pour l'initialisation, la connexion, la collecte des données toujours nécessaires, etc...

Une idée inattendue m'est venue à l'esprit : charger un modèle, le renommer et n'y écrire que ce qui est pertinent pour cette idée particulière. Et ces fonctions que vous utilisez toujours, dans n'importe quel code, en retournant les mêmes données dans n'importe quelle situation - mettez-les dans des classes. Et tout se mettra en place d'un seul coup. Vous pouvez également structurer les répertoires. Dans \experts\, je crée (je l'ai fait de cette façon) un dossier appelé Commandes, où je mets également tous les fichiers appartenant à différents clients dans des dossiers séparés, j'ai un dossier nommé Idées, Tests, etc.

De cette façon, vous pouvez garder les choses en ordre.

 
Malheureusement, même en apprenant formellement la POO, vous ne serez pas en mesure de construire un programme POO. Il s'agit plutôt d'entrer dans la philosophie de cette approche, ce qui constitue le niveau suivant après l'acquisition de connaissances formelles. Il s'avère donc que vous en avez vraiment besoin ? Mais si vous posez des questions sur la manière de mieux faire, cela signifie que vous pensez que la méthode que vous avez choisie n'est pas optimale. Dans tous les cas, le choix vous appartient.
1...185186187188189190191192193194195196197198199...1503
Nouveau commentaire