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
J'écris de cette façon parce que j'aime ça. Cela dit, cela devient vraiment mauvais lors du débogage.
Même dans cette expression.
c'est difficile de savoir qui a rendu quoi. Dans les plus complexes (je le pratique tout le temps), c'est vraiment difficile.
Si vous voulez utiliser 2-3... supposons que 5 résultats d'exécution de fonctions unis par des opérations logiques (ou opérateur ternaire conditionnel) - je l'ai vu sur githab ou ailleurs, ce code peut être traité
Mais si vous avez une douzaine de ces "goodies"... imho, ce n'est pas pratique
Je ne suis pas un développeur mql, bien sûr,
mais en C, le commutateur génère une recherche binaire assez efficace et ne provoque pas de pagination inutile ni de vidage du cache. Donc oui, c'est souvent mieux que l'adressage indirect via les tableaux et les structures.
les développeurs ont écrit quelque part et ici des informations similaires
n'a trouvé que ça :
Forum sur le trading, les systèmes de trading automatisés et les tests de stratégie
Voici l'article que nous avons trouvé dans MQL5.
Slava, 2011.04.14 09:59
Non, malheureusement, ce ne sera pas le cas. Pour les types de chaînes de caractères, seulement si ... sinon si ... sinon
L'utilisation de types entiers dans le switch accélère le code de l'analyseur plusieurs fois plus que si
Mais si c'est une douzaine ou plus... imho, ce n'est pas pratique.
Petit monstre.
Lesopérations logiques vous permettent d'écrire succinctement lorsque vous utilisez différents paramètres via des macros. Mais c'est une horreur, bien sûr.
Lesopérations logiques permettent une écriture concise lors de l'utilisation de divers paramètres via des macros. Mais c'est une horreur, bien sûr.
Votre exemple de "la fin justifie les moyens".
ma question portait sur un style très différent et incompréhensible
Le petit monstre.
On ne peut pas regarder un cheval donné dans la bouche. Mais voici quelques autres exemples de code d'autres personnes, qui m'ont donné quelques dizaines de minutes inoubliables de débogage. Peut-être que quelqu'un reconnaîtra son propre code.
Je ne sais pas si c'était facile de l'écrire comme ça mais c'est irréel de le déboguer, d'autant plus de le lire. Et je ne vois pas de raisons objectives pour l'écrire de cette façon.
Et je ne vois pas de raisons objectives pour l'écrire de cette façon.
Elles sont subjectives, bien sûr. Je n'aime pas les variables inutiles et les retours multiples. Pour une raison quelconque, je crois que le EX5 sera plus court et exécuté plus rapidement sans eux.
Elles sont subjectives, bien sûr. Je n'aime pas les variables inutiles et les retours multiples. Pour une raison quelconque, je crois que l'EX5 sera plus court et plus rapide sans eux.
D'ailleurs, cette confiance dans le fait que le code sera plus court et plus rapide n'est pas justifiée.
c'est ici
et ceci
return A()||B()||X();
Je suis sûr que la vitesse sera la même (et peut-être la taille du code et de la mémoire utilisée).
C'est juste que la seconde variante est plus rapide à écrire et que tout le monde l'écrit, puis, lorsqu'il est nécessaire d'ajouter/compliquer quelque chose, ils laissent la seconde variante mais gonflée en une variante difficile à lire.
Vous devriez périodiquement effectuer un remaniement à cet égard et vous n'aurez pas de problèmes.
Effectuez périodiquement des remaniements à cet égard et il n'y aura aucun problème.
Seulement pour ceux qui ont beaucoup de temps libre ou qui sont objectivement si pressés qu'il n'y a nulle part où aller sans cela.
Lorsqu'il y a beaucoup de retours, le code sera différent à 100%.Seulement pour ceux qui ont beaucoup de temps libre ou qui sont objectivement si pressés qu'il n'y a nulle part où aller sans cela.
ZS Quand il y a beaucoup de retours, le code sera différent à 100%.Je comprends, je suis en partie d'accord, je pense juste que tout le monde a fait l'expérience de temps de correction de bogues relativement longs, qui seraient trouvés plus rapidement si le code était "parfaitement prêt" pour le débogage.
On ne sait pas ce qui prend le plus de temps - écrire du code "utilisable" ou déboguer et trouver des bugs, c'est toujours différent je suppose.
Quand il y a beaucoup de retours, le code sera 100% différent.
C++ VS2019 sous débogueur
code source :
débogueur asm
réduit par les commandes un appel juste dans 2 colonnes à ne pas compter :
comme vous pouvez le voir ici et les commandes se répètent presque l'une l'autre, il est clair que dans le premier test vous devez ajouter un peu plus de retour
avec 99 % de confiance, je pense qu'au niveau du processeur, ces codes fonctionneront à la même vitesse jusqu'à une horloge - dans le processeur, l'optimisation, la mise en parallèle et qui sait quoi d'autre fonctionnent au niveau des micro-commandes.