Erreurs, bugs, questions - page 1997
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
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.
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.
Cela fonctionne depuis la version 1565. Depuis mars 2017.
GetLastError : que renvoie-t-il ?
Merci...
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.
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.
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.
...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.
...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.
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.
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.