Erreurs, bugs, questions - page 2724
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
Glory, c'est exactement le problème. Veuillez consulter le lien que je publie ci-dessus, vous y trouverez le code pour le reproduire.
Le même fichier s'ouvre à partir du même conseiller, 1 descripteur pour l'écriture, 2e pour la lecture, fileflush est utilisé après l'écriture, essayez la lecture, et cela ne fonctionne pas correctement.
Bien sûr, si vous fermez/ouvrez, cela fonctionne, mais alors il n'y a pas besoin d'utiliser FileFlush.
Je comprends le problème que vous décrivez.
Le 1er EA écrit le fichier. Il se peut qu'il ne ferme pas ce fichier, mais dans ce cas, il doit appeler FileFlush
Le 2ème Expert Advisor lit le fichier. Il devrait ouvrir le fichier à chaque fois, puis le fermer.
Ouvrez et fermez le fichier pour le deuxième EA seulement !
C'est exactement ce dont je parle. Fermer, puis rouvrir
Ou voulez-vous dire FileFlush avant de fermer le fichier ?
Oui, est-il nécessaire de tirer la chasse avant la fermeture ? Ou bien sa fermeture garantit-elle la pertinence du fichier enregistré.
Oui, est-il nécessaire de tirer la chasse avant la fermeture ? Ou bien la fermeture garantit que le dossier enregistré est à jour.
Je comprends le problème que vous décrivez.
Le 1er EA écrit le fichier. Il se peut qu'il ne ferme pas le fichier, mais dans ce cas il doit appeler FileFlush
Le 2ème Expert Advisor lit le fichier. Il doit ouvrir le fichier à chaque fois, puis le fermer.
Ouverture et fermeture du fichier uniquement pour la deuxième EA !
Je comprends qu'il s'agit d'une solution de rechange.
Mais il serait préférable de corriger l'erreur, ce n'est pas possible facilement, je suppose ?
Oui, est-il nécessaire de tirer la chasse avant la fermeture ? Ou bien la fermeture garantit que le dossier enregistré est à jour.
Pas nécessairement. Les tampons sont réinitialisés automatiquement si aucun appel à FileFlush n'a été effectué avant la fermeture.
Le bogue MT5 (build 2390) compte incorrectement les accolades dans la description de la structure de la classe.
Un conseiller expert qui lit un fichier doit garder ce fichier fermé.
La particularité de l'implémentation des fichiers dans MQL5 est qu'ils conservent autant que possible les données des fichiers dans leurs propres tampons. Si la taille des informations est si importante qu'elle ne tient pas dans le tampon, votre astuce consistant à déplacer le pointeur au début puis à la fin du fichier peut fonctionner.
Donc, pour le moment, ouvrez le fichier, vérifiez le contenu, puis refermez-le.
Comme je l'ai dit plus haut (dans votre propre texte), c'est l'inverse dans mon test-case - l'indicateur lit, le Conseiller Expert écrit. Mais d'après ce que j'ai compris, le type de programme n'est pas important. Le problème est d'ordre architectural.
L'implémentation du fichier spécifié dans MQL5 est un bug. Fermer et ouvrir un fichier est une solution de contournement, mais cela ne devrait pas être le cas pour la lecture d'un fichier partagé.
Il est bon de veiller à l'optimisation des performances, mais cela ne doit pas avoir d'incidence négative sur la fonctionnalité.
PS. Comme solution rapide, voici une suggestion : en réponse à un appel FileFlush pour un fichier ouvert à la lecture, mettez à jour son tampon.
Probablement parce que µl C++ est similaire, et que les structures y sont venues du C.
Si vous avez besoin de constructeurs, utilisez des classes ou accueillez Sharp. Pourquoi priver les structures de cette connotation ? Cela ne fera que rendre les programmes plus expressifs. Je peux prendre le code de quelqu'un et voir qu'il a une structure au lieu d'une classe et obtenir beaucoup d'informations à partir d'un seul mot. Vous n'obtiendrez rien, vous étudierez assidûment le code source pour obtenir le même résultat, que j'ai obtenu en un clin d'œil. Dans mon expérience - cette convention de structures est respectée, bien, peut-être une sorte de marginalisme nihiliste éolien.
Mais en C++, les structures et les classes sont une seule et même chose. C'est pourquoi tous vos raisonnements sur "l'expressivité du code" n'affectent pas l'essence des choses.Vous pouvez tout aussi bien définir n'importe quel autre mot expressif, à l'exception de struct ou class, par le biais d'une define et cela ne changera rien (je parle du C++).
C'est pourquoi nous devrions parler des structures uniquement du point de vue du C#. C'est de là que vient leur concept. Les structures sont des types de valeurs, elles sont donc beaucoup plus compactes que les classes, elles ne sont pas polymorphes et elles ne peuvent pas être référencées. Ce dernier point est particulièrement important.
Il n'y a pas de mal là-bas, il vous semble. Il y a même une extension dans la norme : la lecture de unsigned char et std::byte non initialisés n'est pas un comportement indéfini. Vous pouvez utiliser l'initialisation d'agrégats pour POD. Et n'oubliez pas - toute cette initialisation n'est pas gratuite, c'est une véritable consommation de ressources (CPU, mémoire, taille d'un exécutable). Si vous n'en avez rien à faire avec votre calculateur, dans le cas d'un microcontrôleur, cela peut être important. Après tout, le C/C++ n'est pas seulement un mélange de Windows comme Sharp.
L'initialisation d'une seule variable a augmenté la taille des instructions de 30 %.
Personne ne dit que l'initialisation est gratuite en soi, mais on en aurait besoin de toute façon, donc je ne comprends pas vraiment la signification de vos mesures avec et sans initialisation.
Une autre chose est que le compilateur ne réinitialisera pas les variables :
Donc toute cette paranoïa sur le fait d'avoir peur de la pré-initialisation des variables est ridicule. On est en 2020, surtout si on parle de structures POD. Leur initialisation sera certainement optimisée par le compilateur.
L'absence de pré-initialisation n'est acceptable que lorsqu'il existe un contrôle du compilateur à 100% interdisant la lecture de variables non initialisées.
En C++, les structures et les classes sont une seule et même chose. Ainsi, tous vos arguments sur "l'expressivité du code" n'affectent pas l'essence des choses.Vous pouvez aussi bien définir n'importe quel autre mot expressif que struct ou class par le biais d'une define et cela ne changera pas (je parle du C++).
Quelle personne têtue !)), c'est la même chose pour vous, vous n'avez pas besoin de définir quoi que ce soit par un define, il y a déjà un mot - struct. Vous pouvez l'ignorer, mais ne soyez pas surpris que les bons codeurs vous considèrent comme un codeur de merde lorsqu'ils voient vos structures remplies de fonctions. C'était peut-être une erreur à l'aube des croix d'assimiler les structures et les classes, il aurait fallu laisser les structures comme en C.
C'est pourquoi nous devrions parler des structures uniquement du point de vue du C#. C'est de là que vient leur concept. Les structures sont des types de valeurs, elles sont donc beaucoup plus compactes que les classes, ne sont pas polymorphes et ne peuvent pas être référencées. Ce dernier point est particulièrement important.
Pensez-vous que votre Sharp est apparu dans un champ propre ? Enracinée dans le C, la structure est un conteneur muet sans sucre supplémentaire.
Une autre chose est que le compilateur ne réinitialisera pas les variables :
Toute cette paranoïa sur la peur de la pré-initialisation des variables est donc ridicule. On est en 2020, surtout si on parle de structures POD. Leur initialisation sera certainement optimisée par le compilateur.
Pensez-vous que votre Sharp est apparu dans un champ propre ? Enracinée dans le C, la structure est un conteneur muet sans sucre supplémentaire.
Eh bien, l'homme a évolué à partir d'un singe. Mais cela ne veut pas dire que l'homme est un singe débile "sans sucre supplémentaire", n'est-ce pas ? ) J'ai déjà expliqué qu'en fait les structures MQL = les structures C#, avec une petite différence : en C#, elles peuvent toujours implémenter des interfaces. interfaces, Carl ! )
Parce que c'est la chose la plus triviale et primitive que l'on ne peut même pas appeler optimisation. Je pense que tous les compilateurs le font par défaut, même en mode Debug. Qu'est-ce qui peut être plus facile ? Pendant l'analyse du code, vous devez suivre l'accès aux variables. S'il y a une opération d'écriture répétée et qu'il n'y a pas eu d'opération de lecture, il faut couper l'entrée précédente.
Vous pouvez l'ignorer, mais ne soyez pas surpris que les bons codeurs vous considèrent comme un codeur de merde lorsqu'ils verront vos structures remplies de fonctions .
Je qualifierais plutôt votre approche des opérations non initialisées de "codage de merde". Quelle est la principale qualité que doit posséder un programme informatique ? La stabilité. Avec les mêmes données d'entrée, il doit donner des résultats immuables. Et vous proposez de l'oublier. Quelque part, vous avez oublié d'initialiser une variable, quelque part, vous avez ajouté un nouveau champ à la structure qui est devenu non initialisé dans tout le programme, et le programme a continué. Le programme fonctionne de cette façon et de cette façon...
Le langage C a été créé dans un passé lointain où les capacités matérielles étaient très faibles, de sorte qu'une grande partie du travail d'optimisation était laissée au programmeur. Si cela vous démange tant, pourquoi vous référez-vous au C et non à l'Assembler par exemple ? Encodez les systèmes de trading en Assembler. Je suis sûr qu'ils seront les plus rapides, peut-être même en avance sur le marché ;)