OOP, templates et macros dans mql5, subtilités et utilisations - page 14
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
1. Il est préférable de parler d'une chose à l'endroit où elle se trouve, 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 très lourde pour déplacer la discussion normalement en préservant l'ordre des messages et leur sens.
2) Discuter des actions d'un modérateur n'est pas à dédaigner... Ce n'est pas tous les éternuements, mais si vous voulez le défier publiquement, que ce soit pour rétablir l'ordre ou calmer une frénésie. 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 :)
Merci pour cette précision. J'ai pensé qu'il valait mieux que la discussion ait lieu dans un fil distinct afin de ne pas encombrer les informations censées être précieuses dans le fil principal. Si vous décidez de déplacer les postes, je discuterai de l'endroit où vous les déplacez.
Ce n'est pas comme si vous étiez déjà 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 doivent se faire dans une branche séparée, c'est-à-dire ici, plutôt que dans la branche des fonctionnalités elle-même.
Dans votre description, il n'est pas du tout clair comment se référer uniformément à une méthode de classe par référence et par une valeur de type T. Je ne sais pas de quoi vous parlez, mais je parlais justement de cette chose là.
Voici la situation : j'ai réalisé que tout ne peut pas être adapté aux spécificités que les membres du forum s'attendent à voir dans ce fil de discussion. La discussion ici (et elle était là, donc je l'ai déplacée ici) porte sur un sujet assez spécifique, que j'ai décidé de séparer dans un fil distinct. Qu'il y ait des fonctionnalités plus générales et compréhensibles pour la majorité, et ici - des classes, des façons délicates de travailler avec elles, y compris les macros (quel casse-tête pour beaucoup).
Merci pour cette précision. J'ai pensé qu'il valait mieux que la discussion ait lieu dans un fil distinct afin de ne pas encombrer les informations censées être précieuses dans le fil principal. Si vous décidez de déplacer les postes, je discuterai de l'endroit où vous les déplacez.
Gardons-le comme ça à partir de maintenant. Copiez simplement - si possible - l'exemple dont vous parlez dans votre propre message, qui fait référence à cet exemple (j'ai du mal à savoir où il a commencé). Ou, si vous ne pouvez plus modifier votre message, dites-moi en privé où coller quoi.
Que ça reste comme ça à partir de maintenant. Copiez simplement - si possible - l'exemple discuté dans votre message, qui fait référence à cet exemple (il m'est difficile de savoir où il a commencé ici). Ou, si vous ne pouvez pas déjà éditer votre message, dites-moi en privé où coller quoi.
J'ai déjà copié le code ici depuis ce fil de discussion il y a quelques messages, donc aucune action supplémentaire n'est nécessaire, je pense.
J'ai déjà copié le code de ce fil de discussion il y a quelques messages, donc aucune étape supplémentaire n'est nécessaire.
Bien.
Mise à jour sur le thème des interfaces via les modèles et la statique. Pour être plus précis, il ne s'agit pas d'interfaces, mais plutôt d'opérations paramétrables de manière pratique sur des types arbitraires, mises en œuvre par des classes externes. Dans ce cas, il s'agit de la comparaison (Comparer) et de la projection (Caster).
J'ai partiellement répondu à la critique précédente, la classe "interface" (bien que ce ne soit pas une interface) n'est pas héritée de la classe paramètre (une telle méthode n'a pas pris...), et sans utiliser dynamic_cast bien sûr. Espérons que ce modèle sera plus logique.
Est-il réaliste d'écrire une macro pour cette section de code ?
Je n'ai pas encore décidé du nombre de variables d'entrée (entrée), je suis fatigué de corriger la section allouée, la macro pour une ligne n'est pas un problème, mais comment la multiplier à 10-15 lignes, je ne sais pas.
Est-il réaliste d'écrire une macro pour cette section de code ?
je n'ai pas encore décidé du nombre de variables d'entrée (entrée), fatigué de corriger la partie sélectionnée, la macro pour une ligne n'est pas un problème, mais comment la multiplier à 10-15 lignes je ne sais pas
Je dois dire tout de suite que je ne l'ai pas vérifié sur µl, je l'ai juste fait passer par le préprocesseur cis pour le tester, µl a des particularités, donc si quelque chose ne va pas, veuillez le modifier.
J'ai obtenu la sortie (gcc -E) :
arguments supplémentaires vous/donner à la liste ARGS.
Est-il réaliste d'écrire une macro pour cette section de code ?
Je n'ai pas encore décidé du nombre de variables d'entrée (entrée), je suis fatigué de corriger la section allouée, la macro pour une ligne n'est pas un problème, mais comment la multiplier à 10-15 lignes , je ne sais pas.
Jusqu'à présent, on n'a trouvé que ça. Si les développeurs avaient ajouté un nombre variable de paramètres, comme en C, il pourrait être plus court.
Pour l'instant, c'est tout ce que j'ai trouvé. Si les développeurs vissaient un nombre variable de paramètres, comme en C, il serait possible de le rendre plus court.
Quelque chose que j'ai surcompliqué ;)).
Et laissez-les utiliser le premier, c'est probablement le meilleur.
#define TEST(dId)
Ce n'est pas un problème d'écrire TEST plusieurs fois.