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
Lesrésultats de l'exécution montrent que le compilateur agit contrairement à la logique :
Pour une chaîne constante pure, la taille du tampon par StringBufferlen=0, ce qui signifie que la chaîne est constante :
Réaffecter une chaîne de caractères "prétendument" constante ne revient pas à travailler avec une constante, mais plutôt à créer exactement une variable dynamique avec une préaffectation de 260 caractères :
Pour une chaîne constante pure, la taille du tampon par StringBufferlen=0, ce qui signifie que la chaîne est constante :
Réallouer une chaîne "supposée" constante, ce n'est pas travailler avec une constante, c'est créer une variable dynamique avec une pré-allocation de 260 caractères :
il est temps d'introduire les allocateurs ;)))
Pour rappel, il y a un bug avec le tampon de chaîne :
La fonction de la DLL peut être n'importe quoi.Je suggère d'ajouter une version étendue de la fonctionStringToTime à MQL dans le formulaire :
Parce que dans la version actuelle, la fonction renvoie toujours une heure valide, même si la chaîne contient des déchets, et la date actuelle est renvoyée, ce qui est particulièrement étrange :
StringToTime("aaabbbccc") renvoie "2019.09.05 01:00:00" Est-ce normal ? Dans cette implémentation, la fonction est dangereuse pour la santé du tout. Par conséquent, une version avec des contrôles de correction est nécessaire.
Jusqu'à présent, nous avons analysé avec notre propre fonction,mais le problème est que l'heure peut être spécifiée dans différents formats.Et je n'ai pas vraiment envie de coder tous ces formats en réinventant la roue alors que le temps a déjà été implémenté dans MQL.
En principe, cela s'applique également aux autres fonctions de conversion de chaînes de caractères : StringToInteger, StringToDouble. Aucun contrôle de validité n'est prévu pour elles aussi.
p.s. Hmm, il s'avère queGetLastError() génère des erreurs dans ces cas. Je ne le savais pas. La documentation de ces fonctions ne dit rien de tel. Cela élimine le problème, bien que ce serait plus facile avec un bool.Je soutiens la suggestion d'Alexey, une manipulation sûre des chaînes de caractères est essentielle pour éviter les erreurs cachées.
erreur "la propriété existe déjà avec une valeur différente et sera ignorée".
Je l'ai utilisé pour la première fois. Aucun autre dossier ne l'a. Ne dépend pas de la valeur. Construire 2136.
S'il vous plaît, ramenez l'ancien style de styler.
Maintenant je n'arrive pas à comprendre ce qui est censé fonctionner ici :
Cette pièce ressemblait à ça avant :
erreur "la propriété existe déjà avec une valeur différente et sera ignorée".
Je l'ai utilisé pour la première fois. Aucun autre dossier ne l'a. Ne dépend pas de la valeur. Construire 2136.
Cette erreur se produit lors du travail avec des projets si la valeur de la propriété spécifiée dans le code source est en conflit avec la valeur dans les paramètres du projet.
Propriétés du projet
S'il vous plaît, ramenez l'ancien style de styler.
Maintenant je n'arrive pas à comprendre ce qui est censé fonctionner ici :
Cette pièce ressemblait à ça avant :
Les ifs multiples imbriqués ne peuvent être sauvegardés par aucun alignement. Nous devons modifier le code pour le rendre lisible.
Les ifs multiples imbriqués ne peuvent être sauvegardés par aucun alignement. Vous devez modifier le code pour le rendre lisible.
Il n'y a pas d'imbrication multiple - le niveau supérieur est if, puis if else.
Je demande l'ancien style de l'époque où tout le monde ressemblait à ça :
- était sur une seule ligne et il n'y avait pas de décalage du texte suivant vers la droite.
Voici un exemple tiré de l'aide sur lesinstructions conditionnelles if-else (l' ancien stylet)
et c'est ce que fait le nouveau styler :