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
Veuillez rétablir l'ancien style METAQUOTES ou au moins faire en sorte que les codes écrits sur une ligne ne soient pas formatés.
Exemple :
Veuillez revenir à l'ancien style METAQUOTES ou au moins faire en sorte que les codes écrits sur une ligne ne soient pas formatés.
utilisez le style Pico, il est très similaire à ce que vous recherchez
mais le style Pico divise l'instruction if - else sur deux lignes si vous utilisez { }
Votre code où vous utilisez { }
si pas d'utilisation { }
2133 Voici un gadget comme celui-ci
utilisez le style Pico, il est très similaire à ce que vous recherchez
mais le style Pico divise l'instruction if - else en 2 lignes si vous utilisez { }
Votre code où vous utilisez { }
si pas d'utilisation { }
Oui ! !! J'ai fait une analyse complète des styles disponibles et j'ai choisi PICO et RATLIFF.
PICO est le plus compact.
RATLIFF est le plus intelligent.
Mais il est absurde que METAQUOTES change un style utilisé depuis des années. Cela perturberait la vie de tous les utilisateurs. Un changement irresponsable. Il y a quelques mois, j'ai fait une erreur de style, je pensais que c'était une erreur de déménager malgré les petits changements, mais maintenant ils ont fait une erreur.
2133 uma piada
Oui ! !! nous savons que c'est une version bêta, mais si quelque chose était correct dans les anciennes versions et a maintenant changé dans la version bêta, c'est probablement avec ces changements. Il vaut mieux se plaindre maintenant pour s'assurer que tout se passe bien.
Dans ce cas, la documentation est obsolète.
Dans un souci d'efficacité, les chaînes de caractères sont désormais préallouées à une taille supérieure à celle demandée, car dans la grande majorité des cas, elles sont remplies par les opérations suivantes.
C'est clair maintenant.
Mais quelle que soit la façon dont je modifie la longueur de la chaîne, le résultat de StringBufferLen reste toujours égal à 260.
Dans ce cas, la documentation n'est pas à jour.
Pour des raisons d'efficacité, les chaînes de caractères sont maintenant pré-allouées plus grandes que celles demandées, puisque dans la grande majorité des cas, elles sont incrémentées par les opérations suivantes.
Est-il possible dans ce cas
s2 peut augmenter dans le futur ?
Résultat : 260
Attendu : 100 ou 0.
J'ai ajouté StringLen au test, et initialisé la chaîne différemment.
Dans la documentation, c'est une chose, mais en fait, elle se comporte différemment.
Et dans ce cas, la mémoire tampon affiche 0 au lieu de 260.
Donc, soit il y a un problème avec l'initialisation de la chaîne. Ou StringBufferLen échoue.