Erreurs, bugs, questions - page 1667

Nouveau commentaire
 
BlackTomcat:
Bien sûr, je ne comprends pas grand chose, mais je pense, pour une raison quelconque, que les copies d'indicateurs créées par différents "maîtres", même avec les mêmes paramètres et appliquées à un seul et même graphique, auront des poignées différentes. En principe, ils ne sont pas au courant de la copie existante de l'indicateur, et ils ne devraient pas l'être. Lors du dessin, ils se superposeront simplement les uns aux autres.
Je peux me tromper. Mais la logique suggère qu'il doit en être ainsi, comme écrit dans le paragraphe précédent.

Je ne suis certainement pas un développeur MQ, mais d'après ce qu'on m'a expliqué, Five a effectué une mise en cache efficace des indices, de sorte qu'il n'y aura toujours qu'un "même" indentation, et que plusieurs "maîtres" auront un lien avec elle. Les poignées seront peut-être différentes - je n'ai pas vérifié - mais à l'intérieur, ce sera la même entité. Personne n'a dit qu'ils devraient être au courant de la copie qui existe déjà - s'il vous plaît, ne spéculez pas. Absolument, personne d'autre que l'"hôte" ne connaît ses indicateurs, et pour un indicateur, un compte de référence est maintenu pour lui à partir de différents "hôtes", mais il ne connaît pas les hôtes.

Comme le montre la pratique, la logique varie d'une personne à l'autre. Par exemple, très souvent, ma logique ne coïncide pas avec celle de MQ, mais ici je ne fais que raconter ce que j'ai entendu de leur part.

 
Stanislav Korotky:

Je ne suis certainement pas un développeur MQ, mais d'après ce qu'on m'a expliqué, Five a effectué une mise en cache efficace des indices, de sorte qu'il n'y aura toujours qu'un "même" indentation, et que plusieurs "maîtres" auront un lien avec elle. Les poignées seront peut-être différentes - je n'ai pas vérifié - mais à l'intérieur, il s'agira de la même entité. Personne n'a dit qu'ils devraient être au courant de la copie qui existe déjà - s'il vous plaît, ne spéculez pas. Absolument, personne d'autre que l'"hôte" ne connaît ses indicateurs, et pour un indicateur, un compteur de référence est maintenu pour lui depuis différents "hôtes", mais il ne connaît pas les hôtes.

Comme le montre la pratique, la logique varie d'une personne à l'autre. Par exemple, très souvent, ma logique ne coïncide pas avec celle de MQ, mais ici je ne fais que raconter ce que j'ai entendu de leur part.

En effet, ce que vous avez écrit est écrit directement dans la Documentation :

Toutes les fonctions comme iMA, iAC, iMACD, iIchimoku, etc., créent une copie de l'indicateur technique approprié dans le cache global du terminal client. Si une copie de l'indicateur avec ces paramètres existe déjà, une nouvelle copie n'est pas créée, mais le compteur de références à cette copie est augmenté.
Seulement, je me demande si le "cache global du terminal du client" inclut par exemple le Testeur ? Parce que je peux exécuter un seul et même conseiller expert avec les mêmes indicateurs dans le terminal (sur un compte) et dans le testeur de stratégie (sur l'historique) en même temps, et je ne suis pas sûr que leurs tampons de calcul seront identiques. Cependant, si vous calculez la profondeur de l'historique stocké dans le terminal du client, ils le peuvent.
 
A100:

J'ai réussi à réaliser un script de test proche du programme source avec une erreur lors de l'exécution

Résultat : appel de pointeur de fonction invalide dans 'Script2.mq5'.

construire 1405. L'erreur elle-même demeure - déplacée vers une autre partie du programme - je m'en occuperai plus tard.

Mais de nouveaux sont apparus, qui n'existaient pas auparavant.

typedef int (*fn)();
class A {
public:
        A() { a = &this; ::ArrayResize( f, 1 ); f[ 0 ] = f0; }
        virtual int g0() { return 0; }
        static  int f0() { return a.g0(); }
        static A* a;
        fn f[];
};
A* A::a;
void OnStart() { A b; }
Résultat : fichier EX5 invalide (8)
 
Comment rendre visibles les éléments du tableau Shift+F9 dans le débogage ?
 
fxsaber:
Comment rendre les éléments du tableau Shift+F9 visibles dans le débogage ?
L'affichage des éléments d'un tableau n'est pas encore pris en charge
 
Renat Fatkhullin:

En fait, dans 99 % des cas, l'appel à IndicatorRelease est une erreur logique du programmeur.

La création d'indicateurs est l'une des opérations les plus coûteuses qui mettent en jeu des mécanismes très profonds de leur calcul. Tenter de fermer une poignée d'indicateur est également une opération très coûteuse, si l'on pense aux véritables processus sous-jacents de sa mise en œuvre. La création et la fermeture fréquentes d'indicateurs montrent que le développeur ne comprend pas du tout l'essence des opérations.

Il est très facile à comprendre.

Est-ce que je comprends bien qu'en utilisant iCustom au lieu d'IndicatorCreate, l'utilisateur transfère la responsabilité d'IndicatorRelease à la solution universelle (donc non optimale) des développeurs ?

Dans lequel les indicateurs créés sont stockés pendant un certain temps, tandis qu'ils sont appelés avec une certaine fréquence. S'ils ne sont pas appelés pendant un certain temps, alors il y a un IndicatorRelease forcé. N'est-ce pas ?

Autrement dit, iCustom doit être utilisé de manière optimale, en tenant compte du juste milieu entre la complexité de la mise en œuvre et les performances. Mais si vous voulez la vitesse maximale, il vaut mieux essayer de tout faire par IndicatorCreate, en créant votre propre algorithme d'indicateurs plus rapide (pas universel), en connaissant les particularités de leur utilisation.

Ai-je bien compris ?

 
fxsaber:

Est-ce que je comprends bien qu'en utilisant iCustom au lieu d'IndicatorCreate, l'utilisateur transfère la responsabilité d'IndicatorRelease à la solution universelle (donc non optimale) des développeurs ?

Dans lequel les indicateurs créés sont stockés pendant un certain temps, tandis qu'ils sont appelés avec une certaine fréquence. S'ils ne sont pas appelés pendant un certain temps, alors il y a un IndicatorRelease forcé. N'est-ce pas ?

Autrement dit, iCustom doit être utilisé de manière optimale, en tenant compte du juste milieu entre la complexité de la mise en œuvre et les performances. Mais si vous voulez la vitesse maximale, il vaut mieux essayer de tout faire par IndicatorCreate, en créant votre propre algorithme d'indicateurs plus rapide (pas universel), en connaissant les particularités de leur utilisation.

Ai-je bien compris ?

Non, vous ne l'êtes pas.

Les deux fonctions sont absolument égales. Les deux fonctions renvoient le manche de l'indicateur

 
Slawa:

Non, c'est faux.

Les deux fonctions sont absolument égales. Les deux fonctions renvoient le manche de l'indicateur

IndicatorRelease doit être fait après iCustom ?

En fait, il s'avère qu'il est tout à fait possible d'exécuter des EAs MT4 dans MT5. Pour ceux qui n'utilisent pas d'autres indicateurs en interne - très facile. Ceux qui les utilisent - créent un analogue du stockage MT4-iCustom. La question de l'impréparation des données est également tout à fait possible.

Ecrivez un tel adaptateur et tout indicateur MT4 fonctionnera avec succès dans MT5. Mais dans ce cas, Nikolay Kositsyn perdra son emploi... Non, il vaut mieux pas.

 
fxsaber:

IndicatorRelease doit être fait après iCustom ?

En fait, il s'avère qu'il est tout à fait possible d'exécuter des EAs MT4 dans MT5. Pour ceux qui n'utilisent pas d'autres indicateurs en interne - très facile. Ceux qui les utilisent - créent un analogue du stockage MT4-iCustom. La question de l'impréparation des données est également tout à fait possible.

Ecrivez un tel adaptateur et tout indicateur MT4 fonctionnera avec succès dans MT5. Mais dans ce cas, Nikolay Kositsyn perdra son emploi. Non, je ne préfère pas.

Je me souviens que la documentation indique que la manière la plus correcte d'initialiser (créer) les poignées d'indicateurs dans la fonction OnInit, et d'effectuer IndicatorRelease dans la fonction OnDeinit. Cela signifie que pendant toute la durée de fonctionnement du conseiller expert, les manipulations des indicateurs restent pertinentes.
 
BlackTomcat:
Je me souviens, la documentation dit qu'il est préférable d'initialiser (créer) les poignées d'indicateurs dans la fonction OnInit, et d'effectuer IndicatorRelease dans la fonction OnDeinit. Cela signifie que pendant toute la durée de fonctionnement du conseiller expert, les manipulations des indicateurs restent pertinentes.

Pas seulement à jour, mais recalculé (enfin, ou en extrayant des données pour les recalculer) ! C'est pourquoi il est toujours judicieux d'utiliser IndicatorRelease si vous êtes sûr à 100% de ne plus en avoir besoin. Et cela peut arriver bien avant OnDeinit.

Par exemple, si vous appelez un indicateur avec des paramètres d'entrée aléatoires à chaque fois, il n'y a aucun intérêt à ne pas faire IndicatorRelease.

1...166016611662166316641665166616671668166916701671167216731674...3184
Nouveau commentaire