![MQL5 - Langage des stratégies de trading intégré au terminal client MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
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
Et si je ne me contente pas de modifier les données internes de l'objet, mais que je n'y accède pas non plus, j'écris immédiatement la méthode comme statique. Pour moi, l'utilisation de const et static augmente considérablement la lisibilité/compréhension de mon propre code. Et cela me permet souvent de repérer des bogues ou des failles dans ma propre architecture aux premiers stades de la mise en œuvre.
Je n'écris tout que pour moi. Et il semblerait que je ne vais pas changer certaines données que je ne devrais pas de toute façon. Mais le désir de me protéger de ma propre stupidité me fait riveter l'architecture OOP d'une telle manière, que seul ce qui doit être accessible à changer. Le reste ne l'est pas. Et c'est là que les types const + inheritance sont d'une grande aide. Je le recommande.
Il s'agit peut-être d'une partie qui est donnée par les créateurs aux utilisateurs ordinaires. Comme la fonction de démarrage dans l'EA et les variables Bid et Ask. Quand on fait tout soi-même, il est inutile de s'embarrasser de toutes sortes de contraintes.
J'ai remarqué une tendance intéressante : dans la grande majorité des cas, ceux qui n'y connaissent rien parlent de la monstruosité des plus. Surtout des affûteurs, c'est typique.
Oui, bien sûr, Sharpe est meilleur et plus pratique quand on a besoin de faire quelque chose d'aussi droit qu'un bâton).
Il n'est pas rare que j'utilise de telles constructions intentionnellement :
Si je ne modifie pas les données de l'objet interne et ne m'y applique pas, je spécifie la méthode comme statique. Pour moi, l'utilisation de const et static augmente considérablement la lisibilité/compréhension de mon propre code. Et cela vous permet souvent de détecter des bogues ou des failles dans votre propre architecture à un stade précoce de la mise en œuvre.
...
Oh les gars. Ayez pitié de MetaQuotes. L'un des principaux commandements d'un programmeur : ne jamais utiliser de statique. Deuxième commandement : si vous voulez utiliser la statique, voir le premier point :)
Si des données statiques sont modifiées par un thread pendant qu'un autre les lit, de telles merveilles de la programmation multithreading apparaissent, que l'on peut se souvenir de cette statique comme d'un mauvais rêve.
Mais c'est une bonne chose pour les utilisateurs de MQL : pas de multithreading et, par conséquent, aucune méthode ne modifiera les données statiques avant qu'un thread utilisateur ait fini de les lire.
Un des premiers commandements d'un programmeur : ne jamais utiliser de statique. Deuxième commandement : si vous voulez utiliser la statique, voir le premier point :)
Si des données statiques sont modifiées par un thread pendant qu'un autre les lit, de telles merveilles de la programmation multithreading apparaissent, que l'on peut se souvenir de cette statique comme d'un mauvais rêve par la suite.
J'ai remarqué une tendance intéressante : dans la grande majorité des cas, ceux qui n'y connaissent rien parlent de la monstruosité des plus. Surtout des affûteurs, ce qui est typique.
Oui, bien sûr, Sharp est meilleur et plus pratique quand on a besoin de faire quelque chose d'aussi droit qu'un bâton).
Classique masa b pluses : "Vous n'aimez pas les chats ? Tu ne sais juste pas comment les cuisiner."
Non, je ne le nie pas, C++ comme aucun autre langage peut être adapté aux normes de développement. Mais tant que vous ne vous conformerez pas à ces normes, vous risquez d'être tué sur un tel râteau que vous deviendrez un très bon programmeur C++ ou que vous abandonnerez et irez au 1C pour fabriquer des tickets ERP.
Masque classique des personnes de catégorie B : "Vous n'aimez pas les chats ? Vous ne savez simplement pas comment les cuisiner".
C'est comme ça, c'est tout.)
Je n'ai rien contre Sharp, j'écris des bots avec, c'est pratique, rapide.
C'est juste que je n'aime pas que les gens jettent de la boue sur quelque chose qui ne le mérite pas et qui plus est, quelque chose que personne n'est nécessairement obligé d'utiliser.
Cela vaut aussi bien pour les inconvénients que pour les avantages en général.
C'est comme ça, c'est tout.)
Je n'ai rien contre Sharp, j'écris des bots dedans maintenant, c'est pratique, rapide.
Je n'aime pas que l'on s'en prenne à quelque chose qui ne le mérite pas et que personne n'est nécessairement obligé d'utiliser.
Cela s'applique aux constantes et aux pros en général.
Ok, le monde. C'est juste que les discussions sur le C++ se transforment toujours en charivari.
Z.U. Si quelqu'un pouvait m'expliquer quel est le problème avec const, je l'apprécierais. Je ne le comprends vraiment pas.
Alexey a écrit l'exemple. Une méthode constante ne peut pas modifier les membres de sa classe.
Peut-être que je rate quelque chose, mais... ici. Alexey a écrit que la méthode constante bar change l'objet de sa classe obj. Quel est le problème ?
Oui, obj est passé par référence, mais la méthode n'est pas encore devenue constante...
Peut-être que je rate quelque chose, mais... ici. Alexey a écrit que la méthode constante bar change l'objet de sa classe obj. Quel est le problème ?
Oui, obj est passé par référence, mais la méthode reste constante...