Erreurs, bugs, questions - page 1997

 
Slava:
La barre oblique au début du nom du fichier signifie "de la racine MQL5".

Merci, je n'ai jamais vu ça nulle part auparavant.

 
fxsaber:

Merci, je n'ai jamais vu ça nulle part auparavant.

Ce qui vient à l'esprit en premier

chemin

[Chemin relatif vers le fichier contenant les données de la ressource. Si le chemin d'accès commence par une barre oblique inverse "\" (orthographié "\\"), le fichier est recherché par rapport au dossier terminal_data_directory\MQL5\.S'il n'y a pas de barre oblique inverse, la ressource est recherchée par rapport à l'emplacement du fichier EX5 à partir duquel la fonction est appelée.

Il y a aussi un autre endroit...
Документация по MQL5: Общие функции / ResourceCreate
Документация по MQL5: Общие функции / ResourceCreate
  • www.mql5.com
Общие функции / ResourceCreate - справочник по языку алгоритмического/автоматического трейдинга для MetaTrader 5
 
Slava:

Cela fonctionne depuis la version 1565. Depuis mars 2017.

GetLastError : que renvoie-t-il ?


Merci...

 
Alexey Viktorov:

Ce qui vient à l'esprit en premier

Il y a plus quelque part...

Merci, je n'avais pas pensé que c'était une règle générale.

 
Alexey Viktorov:

Vous pensez peut-être à autre chose, mais dans ce cas précis, une inattention banale du programmeur a conduit à cette erreur.

Oui, je veux dire autre chose. Si les variables étaient initialisées de force par MQL5 lui-même, le nombre de "le testeur donne des résultats différents" diminuerait considérablement. Nous avons maintenant beaucoup d'opportunités pour écrire des Expert Advisors aléatoires.

 
fxsaber:

Si les variables étaient initialisées de force par MQL5 lui-même, alors le nombre de "le testeur donne des résultats différents" diminuerait de manière significative.

...et la vitesse d'initialisation diminuerait.

Évidemment, dans le cas général, ce serait insignifiant, mais quand même.

 
Andrey Khatimlianskii:

...et le taux d'initialisation baisserait.

Il est clair que dans le cas général, ce serait insignifiant, mais quand même.

C'est la raison pour laquelle je ne fais qu'exprimer mes pensées, mais je ne préconise pas cette solution. Merci à@Anton Ohmat d'avoir mis en évidence une autre facette des CTs aléatoires.

 
Andrey Khatimlianskii:

...et le taux d'initialisation baisserait.

Évidemment, dans le cas général, ce serait insignifiant, mais quand même.

C'est l'argument que je n'ai pas compris (quand il a été avancé par MQ) et que je ne comprends pas maintenant. L'initialisation ne va nulle part. Maintenant, elle est confiée au programmeur de l'application et il le fait quand même, mais comme la pratique le montre, parfois avec des erreurs. Et si cela était fait par un noyau, les performances ne seraient pas affectées et il n'y aurait pas d'erreurs.

 
Stanislav Korotky:

C'est l'argument que je n'ai pas compris (quand il a été avancé par MQ) et que je ne comprends pas maintenant. L'initialisation ne va nulle part. Maintenant, elle est confiée au programmeur de l'application et il le fait quand même, mais comme la pratique le montre, parfois avec des erreurs. Si cela était fait par un noyau, les performances ne seraient pas affectées et il n'y aurait pas d'erreurs.

Une initialisation complète n'est pas toujours nécessaire. Par exemple, pour l'indicateur qui remplit la valeur du tampon pour chaque barre de la boucle (et le fait indépendamment du fait que le tampon de l'indicateur soit initialisé ou non).

Dans ce cas, il serait plus économique sans la mise à zéro forcée.

 
Stanislav Korotky:

C'est l'argument que je n'ai pas compris (quand il a été avancé par MQ) et que je ne comprends pas maintenant. L'initialisation ne va nulle part. Maintenant, elle est confiée au programmeur de l'application et il le fait quand même, mais comme la pratique le montre, parfois avec des erreurs. Si cela était fait par un noyau, les performances ne seraient pas affectées et il n'y aurait pas d'erreurs.

Par exemple, prenons le tableau tampon de l'indicateur : lors de l'initialisation de l'indicateur, le tampon a une longueur nulle. Qu'y a-t-il à initialiser avec des zéros ? Lors de l'ajout d'un autre index, il est forcé d'être mis à zéro, puis rempli avec une valeur quelconque ? À quoi sert cette mise à zéro ou ce remplissage avec EMPTY_VALUE? Et s'il y a un besoin d'assigner PLOT_EMPTY_VALUE et non 0 ou EMPTY_VALUE ou de forcer un, mais nous avons besoin d'un autre... Peu importe comment on le découpe, on finit par perdre son temps...

Et un tableau personnalisé... Le tableau est déclaré pour des données différentes de zéro et EMPTY_VALUE. Alors pourquoi devrait-il être initialisé de force avec quelque chose ?

Il s'avère donc que cela affecte les performances dans la plupart des cas.