Implémentations alternatives de fonctions/approches standard - page 9

Nouveau commentaire
 
fxsaber:

Je suis arrivé au point où le problème ne se produit plus et je l'ai oublié. C'est génial quand on n'a pas besoin de revenir à un code déjà écrit. Il fonctionne - c'est l'essentiel.

C'est vrai. Je le fais toujours moi-même (et cette fois-ci aussi, comme vous pouvez le voir).

Le problème se posera si quelque chose change soudainement. Lorsque le code est clair et que les endroits non évidents sont bien commentés, les causes des erreurs dans certaines modifications sont faciles à trouver. Mais dans ces cas de "et oublié" - il est beaucoup plus difficile de faire des corrections.

Oui, bien sûr, que c'est un cas rare... Mais ces cas très rares - personnellement, je suis très nerveux. C'est pourquoi, dans de telles situations, j'essaie d'écrire un code aussi clair que possible et de commenter autant que possible les endroits non évidents.

 
fxsaber:

Un exemple de mon code, que je ne comprends pas du tout pour l'instant. Et il y a beaucoup de facteurs qui doivent être très bien compris.


Comme vous pouvez le constater, le code/style est très simple. Mais je ne pourrai détecter une erreur dans ce code ou son absence que lorsque je serai en mesure de réécrire le même code. Cela va vraiment me prendre beaucoup de temps, car je dois entrer complètement dans le problème.

C'est pourquoi le principe est que les choses complexes sont nettoyées (des tests de stress sont écrits) au stade de la création et utilisées sous une forme simple en branchant mqh. Comme vous pouvez le constater, la complexité n'est pas toujours déterminée par le style ou la brièveté.


Il existe également un exemple de construction purement linguistique - TypeToBytes. La complexité de la compréhension y est d'un tout autre niveau. Et c'est là que je dépérirais sans les macros. C'est grâce aux macros que l'on accède assez rapidement au code source. Car les macros sont souvent utilisées non pas pour la brièveté, mais pour la compréhension.


Et il y a aussi le cas où vous devez tenir compte d'un grand nombre de pièges peu compliqués mais oubliables. C'est le cas avec MT4Orders. C'est pourquoi certaines lignes y sont accompagnées de commentaires adressés uniquement à soi-même. Cela aide à comprendre votre code.


Mais notez que ce sont toutes des mqh, qu'il n'est pas nécessaire d'aborder. Et le code de TC est écrit avec mqh, ce qui est très simple. Vous ne regardez pas dans le code source des fonctions régulières de iHigh. Et ils sont en effet monstrueux. Vous les utilisez simplement. Vous devriez faire de même avec les bibliothèques. L'utilisation du même Generic-bibble ne nécessite pas que vous le compreniez parfaitement.


Regardez le QB pour les EA MT4 et leurs ports MT5. Les ports MT5 sont difficiles à comprendre. Non seulement il est loin d'être concis (le code est plusieurs fois plus gros que l'original), mais il est également truffé de pièges MT5 qui ne sont pas pris en compte dans les fichiers mqh.

Honnêtement, je n'ai rien à redire ici. Évidemment, tout est correct selon votre approche de la programmation (peut-être seulement à l'exception des cas de compression de code excessive et injustifiée), mais si vous adoptez mon approche, beaucoup de choses sont fausses.

1. bien sûr, des erreurs difficiles à trouver peuvent se cacher même dans un code très simplement écrit. Mais ils sont encore plus difficiles à trouver dans un code difficile à écrire. Considérez l'effort mental qu'implique le déballage de la signification. Si vous devez effectuer une grande quantité de travail (écrire beaucoup de fonctions, construire de nouveaux mécanismes, les intégrer avec succès dans des mécanismes existants), l'économie de temps et d'efforts est la chose principale. Il ne s'agit pas de la "beauté" du code. Pas sur les styles. Vous devez composer votre code de telle sorte que vous puissiez le lire au milieu de la nuit et le comprendre aussi rapidement que possible. Vous commencez à chercher la méthode de codage idéale pour obtenir un résultat maximal. Et en le regardant :

return((int)((Value > 0) ? Value / Points[digits] + HALF_PLUS : Value / Points[digits] - HALF_PLUS) * Points[digits]);

vous comprenez immédiatement tous les inconvénients de l'écrire de cette façon :

1. Beaucoup de personnages.

2. Un "emballage" excessif.

3. les opérations mathématiques non commentées.

Vous ne serez pas capable de gérer ce code pendant que vous êtes éveillé. Il est également difficile de faire face au fait d'être surmené et très fatigué. Imaginez que vous travaillez comme ça tous les jours. Vous vous détournez immédiatement d'un tel code.


2. Ne pas regarder le code d'autres personnes et juste le brancher ?

Je pense que les programmes importants, sérieux et, surtout, de grande qualité ne sont pas créés simplement en assemblant les blocs d'autres personnes. Vous ne pouvez pas créer un programme efficace en n'en créant qu'une petite partie et en attachant le reste. Ce sera un "désordre".

Cela peut et va fonctionner. Mais ce sont des programmes "de fortune".

Je ne crois pas à l'efficacité des programmes assemblés à partir de blocs (dans lesquels le développeur ne regarde même pas). C'est une fiction. Le programme sera boiteux et les solutions seront inefficaces. Il y aura beaucoup de problèmes. Si les programmeurs travaillent en équipe et résolvent une tâche commune, c'est bien, mais si l'on utilise des solutions qui "flottent" entre les différents programmes de différentes personnes (qui ne les regardent même pas), cela ne représente rien du point de vue de l'efficacité.

 
Реter Konow:

Cela peut et va fonctionner. Mais c'est, - des programmes "à genoux".

Vous pouvez consulter mes publications dans KB. Quelqu'un doit les utiliser.

Je n'écris que pour moi-même et "à genoux". Les publications sont un sous-produit.

 
Georgiy Merts:

La vérification de LONG_MAX - devrait donc avoir lieu avant la conversion du double en long. Il est clair que la fonction d'arrondi n'est pas conçue pour les valeurs qui ne tiennent pas dans un entier. Et cela ne change rien au problème.

Si la fonction renvoie un double, que nous convertissons ensuite en long, nous sommes confrontés au même danger de débordement.

Personnellement, j'ai toujours un assert-checking pour les valeurs limites juste avant l'arrondi ; en outre, la logique du programme veut que je m'assure toujours qu'une valeur supérieure au maximum pour un entier ne puisse jamais arriver à la transformation.

Vous faites souvent des lancers longs en char ? C'est la même chose avec double - c'est le dernier échelon de la hiérarchie, vous n'avez pas besoin de le couler, dans la plupart des cas vous n'en avez pas besoin, std a tout pour fonctionner avec lui. Ne rabaissez pas la hiérarchie et ne vous en faites pas.

Ajoutez des contrôles sur LONG_MAX/MIN - et quelque chose me dit que les tests de performance ne seront pas si roses. Et la personne vise une substitution standard, donc cela devrait fonctionner pour toute la gamme de valeurs.

 
pavlick_:

Est-ce que vous lancez souvent le long dans l'omble ? C'est la même chose avec le dabl - c'est le dernier échelon de la hiérarchie, il n'y a pas besoin de faire des castings à partir de lui, dans la plupart des cas il n'y a rien à faire avec lui, std a tout pour travailler avec lui. Ne pas se jeter dans la hiérarchie et ne pas se donner la peine.

Ajoutez des contrôles pour LONG_MAX/MIN et je suis sûr que les tests de performance n'auront pas autant de chance. Et l'homme vise la substitution standard, donc il devrait fonctionner pour toute la gamme de valeurs.

long à ulong (et vice versa) - trop souvent.

long à char - rarement.

La conversion est nécessaire car les résultats des opérations en nombres entiers et en nombres flottants sont sensiblement différents. La vitesse d'exécution des données entières est également censée être plus rapide.

A propos de la vérification de l'étendue - j'ai déjà souligné qu'il s'agit d'un ASSERT - c'est-à-dire que cette vérification ne fonctionne que dans la version DEBUG. Dans mon cas, la validité de tous les paramètres d'entrée est toujours vérifiée par des assertions au début de toute fonction publique, ce qui m'a aidé plus d'une fois. Les versions RELEASE, bien sûr, fonctionnent déjà sans aucune vérification.

 
fxsaber:

Vous pouvez consulter mes publications dans KB. Quelqu'un doit les utiliser.

Je n'écris que pour moi-même et "à genoux". Les publications sont un sous-produit.

Je ne remets pas en cause votre expérience et votre professionnalisme.

C'est juste qu'au cours d'un processus de programmation et de développement épuisant et quotidien pendant plusieurs années, vous commencez à estimer les avantages de tel ou tel code, solution ou approche. Et vous arrivez souvent à des conclusions très étranges... Elles sont étranges mais justifiées par beaucoup de pratique.

Je ne fais que partager mon point de vue.

 
Georgiy Merts:

La conversion est nécessaire car le résultat des opérations en nombres entiers et en virgule flottante est sensiblement différent.

Je ne peux pas imaginer dans quelles situations quelque chose ne peut pas être fait correctement avec des doublages. En Lua (attaché à quik), il n'y a pas du tout de types entiers, seulement des dubles, et rien.

 
pavlick_:

J'ai une mauvaise idée des situations dans lesquelles quelque chose ne peut pas être fait correctement sur les doublages.

Compteur.

void OnStart()
{
  const long Num1 = 9007199254967295;
  const long Num2 = Num1 + 1;

  Print(Num1 == Num2); // false
  Print((double)Num1 == (double)Num2); // true
}

double ne perd pas toutes les informations à l'intérieur de la portée, ce qui n'est plus le cas avec les longues distances.

Особенности языка mql5, тонкости и приёмы работы
Особенности языка mql5, тонкости и приёмы работы
  • 2018.01.15
  • www.mql5.com
В данной теме будут обсуждаться недокументированные приёмы работы с языком mql5, примеры решения тех, или иных задач...
 
fxsaber:

Compteur.

Eh bien, il faut encore compter jusqu'à ce nombre)). Et si tu le veux vraiment, ce n'est pas une option :

double cnt;
double high_cnt;
if (++ cnt == 1 000 000) {
   ++ high_cnt;
   cnt = 0;
}
 
pavlick_:

Eh bien, il faut encore compter jusqu'à ce nombre)). Mais si vous le voulez vraiment, ce n'est pas une option :

Il est compréhensible qu'il soit possible d'être tordu. Mais cela en vaut-il la peine ?

À mon avis, si la variable ne doit avoir que des valeurs entières - elle doit être entière juste pour rendre impossible l'écriture d'une valeur à virgule flottante dans celle-ci. Le type de variable ou de valeur de retour lui-même contient déjà des informations importantes sur la variable et partiellement sur l'algorithme. Si nous utilisons partout des valeurs à virgule flottante, cette information sera perdue.

Et même l'entier - selon l'algorithme, à mon avis - doit être déclaré comme signé ou non signé, et pas nécessairement long, mais peut-être "plus court" - juste pour que, en regardant le code, nous puissions immédiatement comprendre quelle gamme de valeurs la variable en question est autorisée à avoir.

Le fait qu'il n'y ait pas de valeurs entières en Lua est, à mon avis, un sérieux désavantage.

12345678910111213
Nouveau commentaire