Comment faire pour passer une énumération de manière cohérente ? - page 3
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
Les exemples montrés ici (cas 1 : valeur de retour1 ; cas 2 : valeur de retour2 ; cas 3 : valeur de retour3... Une personne compétente mettrait toutes les valeurs dans un tableau et obtiendrait simplement la valeur requise par son index. Et pour la tâche inverse, elle utiliserait la recherche binaire.
Je suis à deux mains en faveur d'un code agréable avec des tableaux. Mais en écrivant un NormalizeDouble plus rapide que le normal, j'ai rencontré un effet d'optimiseur - une bonne solution via const-array était beaucoup plus lente qu'une solution encombrante via switch-case. J'ai laissé la deuxième variante car NormalizeDouble est beaucoup utilisé dans le testeur. Je le mets dans l'indicateur et ne regarde pas ce monstre. Mais les backtests sont plus rapides.
Je me souviens d'un fil de discussion sur le switch, où les développeurs ne parlaient que de l'implémentation sous forme de recherche binaire, ce qui est bien sûr beaucoup plus lent qu'un simple accès par index calculé.Mais maintenant ils semblent l'avoir fait plus judicieusement : si une étape est constante, l'index est calculé, sinon une recherche binaire est effectuée. Bien sûr, une implémentation native est toujours plus rapide qu'une implémentation wrapper.
Bien sûr, cela dépend de vos priorités. Mais je pense que si la vitesse est si cruciale que vous êtes prêt à inventer des béquilles, alors vous devriez abandonner la POO et MQL également ;) Bien que je sois sûr qu'avec un codage correct, cette différence de vitesse ne sera pas si importante. Dans les mesures de test, vous faites simplement passer la fonction dans la boucle des millions de fois. Et vous l'utilisez plus rationnellement dans le code réel, n'est-ce pas ?
Je me souviens d'un fil de discussion sur le switch, où les développeurs ne parlaient que de l'implémentation sous forme de recherche binaire, qui est bien sûr beaucoup plus lente qu'un simple accès par index calculé.Mais maintenant ils semblent l'avoir fait plus judicieusement : si le pas est constant, alors l'index est calculé, sinon c'est une recherche binaire. Bien sûr, une implémentation native est toujours plus rapide qu'une implémentation wrapper.
Le compilateur, s'il n'est pas idiot, devrait transformer le const-array et la seule référence de type à celui-ci par l'index en code switch.
Bien sûr, vous devrez peut-être le faire en fonction de vos priorités. Mais je pense que si la vitesse est si cruciale que vous êtes prêt à inventer des béquilles, alors vous devriez abandonner la POO et MQL en général ;) Bien que je sois sûr qu'avec un codage correct, la différence de vitesse ne sera pas si importante. Dans les mesures de test, vous faites simplement passer une fonction dans une boucle des millions de fois. Et dans le code réel, vous l'utilisez de manière plus rationnelle, n'est-ce pas ?
Le compilateur, s'il n'est pas idiot, aurait été obligé de transformer le const-array et la seule référence de type à celui-ci par index en code switch.
Donc le tableau est juste un const ? Et les statiques ? Il s'agit d'une opération simple : comparer la valeur de l'index avec la taille du tableau/enum, et si elle est inférieure, obtenir l'adresse de l'élément requis comme adresse du tableau + index, puis lire la valeur à partir de là. Je pensais qu'une telle absurdité devait se compiler également.
Donc le tableau est juste un const ? Et les statiques ? Il s'agit d'une opération simple : comparer la valeur de l'index avec la taille du tableau/enum, et si elle est inférieure, obtenir l'adresse de l'élément requis comme adresse du tableau + index, puis lire la valeur à partir de là. Je pensais que de telles absurdités devaient se compiler de la même manière.
Je ne me souviens pas avec certitude si vous pouvez créer des tableaux statiques en utilisant des méthodes const - vous ne le pouvez certainement pas. Par principe, je faisais des constantes et non des statiques. Compter sur l'intelligence du compilateur. Après la compilation, il n'y aurait pas dû y avoir le moindre indice d'un tableau dans les boyaux. Un statik est une structure beaucoup plus compliquée qu'un const, j'étais donc sûr que le compilateur ne parviendrait pas à gérer le statik. Mais je devrais essayer.
Je ne me souviens pas exactement si les tableaux statiques peuvent être transformés en const. méthodes - certainement pas. Par principe, je faisais des constantes, pas des statiques. Compter sur l'intelligence du compilateur. Après la compilation, il n'y aurait pas dû y avoir le moindre indice d'un tableau dans les boyaux. Un statik est une structure beaucoup plus compliquée qu'un const, donc j'étais sûr que le compilateur ne parviendrait pas à gérer le statik. Mais je devrais essayer.
Oh, bien, ça explique tout. Vous ne devriez pas vous fier à l'intelligence excessive du compilateur, qui optimise davantage une solution mal conçue pour vous. Si vous êtes vous-même trop paresseux pour le faire correctement, en disant que "la statique est beaucoup plus compliquée" (bien que ce qui est compliqué là, je ne comprends pas), alors pourquoi accuser le compilateur ?
Oh, bien, ça explique tout. Il ne faut pas compter sur l'intelligence excessive du compilateur, car il optimisera pour vous une solution mal conçue. Si vous étiez vous-même trop paresseux / n'avez pas pensé à le faire correctement, en disant "la statique est beaucoup plus compliquée" (bien que ce qui est compliqué là, je ne comprends pas), alors pourquoi accuser le compilateur ?
De rien. Ça me servira de leçon pour l'avenir, que je devrais réfléchir 7 fois, avant de courir partout en inventant des béquilles).
Il s'avère maintenant que j'ai fait l'éloge de l'interrupteur, ou plutôt de ses développeurs, trop tôt. Ainsi, tout est implémenté par recherche binaire uniquement, même lorsque l'énumération est multiple. Pas bon.
De rien. Ce sera une leçon pour l'avenir, de réfléchir 7 fois avant de courir et d'inventer des béquilles).