Erreurs, bugs, questions - page 2579

Nouveau commentaire
 
Vict:

Ecrire les lignes après memcpy() en parallèle au fichier, si µl est à blâmer (il y a une sorte de wrapper au dessus des appels avec copie des arguments), le fichier ne sera pas vide, je suppose.

HH : bien, juste au cas où - dans la bibliothèque µl, la fonction est déclarée avec une référence ? void fn(string & s) ?

Toutes les chaînes que j'affiche soit sur le graphique dans le commentaire, soit dans le terminal d'impression, lorsque la chaîne arrive elle est immédiatement visible, dans le commentaire vous pouvez voir si elle est tordue ou non.
Lorsqu'il y a de grands écarts de temps, la corde apparaît rarement sur le graphique, et il y a des trous dans l'impression.
Il n'y a plus de doute sur le fait qu'aucune chaîne n'arrive de la prise, les données arrivent à la vitesse de la milliseconde.
A partir de la socket, getData() a pris une variable pointeur, à partir de la variable pointeur je copie directement à mql, pas de wrappers.
Oui déclaré par le feng shui ;)

#import "ExampleDll.dll"
   void Func(string task, string & out);
#import
En général, il y a un problème avec la chaîne mql. J'ai essayé et testé de nombreuses variantes.
La chaîne de caractères provenant de la prise vient avec un terminal nul, et la fonction de contrôle la plus fiable
wcscpy(out, data);
или
wcsncpy(out, data, wcslen(data));  //wcslen(data)+1
montre le problème sur mql.

En général, je vais utiliser sizeof(wichar_t*) pour le moment et voir le comportement.
Mais probablement pour être à l'abri des changements de MQ, je vais vraiment écrire des chaînes sur des tableaux.
 
Mais je pense que pour être à l'abri des changements de MQ, je vais probablement écrire les chaînes de caractères sur des tableaux.

Bon point. Bien sûr, j'aimerais utiliser string, mais comme il n'y a pas de norme qui décrit son implémentation et/ou son comportement de transfert dans dll, c'est du pur ub. Et donc, la chaîne dans short[] et vous pouvez passer le tableau en toute sécurité ; la seule chose est l'overhead de la création et la copie d'un tableau.

PS. Pourtant, je pense que le problème n'est pas dans mql, mais dans votre code. Tous les tests sont passés normalement, et il n'y a rien de logiquement mauvais avec string, string est un wrapper trivial sur wchar_t *, ou plutôt sur wstring, qui pourrait le faire foirer.

 
Vladimir Simakov:

De bons mots. Bien sûr, nous aimerions utiliser string, mais comme il n'existe pas de norme décrivant son implémentation et/ou son comportement de transfert en dll, c'est du pur ub. Et donc, la chaîne dans short[] et vous pouvez passer le tableau en toute sécurité ; la seule chose est l'overhead de la création et la copie d'un tableau.

PS. Pourtant, je pense que le problème n'est pas dans mql, mais dans votre code. Tous les tests sont passés normalement, et il n'y a rien de logiquement mauvais avec string, string est un wrapper trivial sur wchar_t *, ou plutôt sur wstring, qui pourrait le faire foirer.

J'avais des doutes sur la librairie aussi, je n'exclus rien comme raison possible.
Mais j'ai converti la chaîne reçue du socket en codes ASCII, vous pouvez voir que la chaîne est correcte.
Vient ensuite une simple copie,
mql n'accepte pas correctement les pointeurs de chaîne.

Dossiers :
1.PNG  32 kb
 
Roman:

Toutes les lignes que j'affiche soit sur le graphique dans le commentaire, soit dans le terminal d'impression, quand la ligne arrive elle est immédiatement visible dans le commentaire montre qu'elle est tordue ou non.
Lorsqu'il y a de grands décalages temporels, la ligne apparaît rarement sur le graphique et présente des trous dans l'impression.
Le doute que la chaîne de la douille n'arrive pas, les données du tick arrivent à la vitesse de la milliseconde.
Depuis le socket, getData() est transféré dans une variable de type pointeur, puis copié immédiatement dans mql, sans wrapper.
Oui déclaré par le feng shui ;)

En général, il y a un problème avec la chaîne mql. J'ai essayé et testé de nombreuses variantes.
La chaîne de caractères provenant de la prise vient avec un terminal nul, et la fonction de contrôle la plus fiable
montre le problème sur mql.

En général, je vais utiliser sizeof(wichar_t*) pour le moment et voir le comportement.
Mais probablement pour être à l'abri des changements de MQ, je vais vraiment écrire des chaînes sur des tableaux.

Écriture dans le fichier - je voulais dire du côté de la dll, si le fichier est écrit, mais n'arrive pas dans le μl, c'est déjà un argument de poids avec une réclamation de bug, peut-être corrigé.

Et il y a un wrapper sans votre souhait, MQ cache les codes/adresses du monde extérieur, tout ne va pas directement.

 
Vict:

Écriture dans le fichier - je voulais dire du côté de la dll, si elle écrit dans le fichier, mais n'arrive pas à mql, alors c'est déjà un argument fort avec la revendication du bug, peut-être corrigé.

Et il y a un emballage sans votre souhait, les MQs cachent les codes/adresses du monde extérieur, tout ne va pas directement.

Écrit les chaînes de caractères reçues dans un fichier.
Comme la fonction socket renvoie un pointeur vers une chaîne de caractères, un pointeur vers la chaîne de caractères est écrit dans le fichier, puis ce pointeur est copié dans mql.
Utilisation de la fonction

wcscpy(out,  data);

La longueur de la chaîne résultante est de 164, le mql est alloué 200.

StringInit(out, 200, 32);

La chaîne copiée reçue dans mql est de longueur égale, cependant, il y a quelques lacunes dans la copie.
Dans le script mql, la boucle while est bouclée avec Sleep(1)

Dossiers :
458.PNG  71 kb
 
Et si vous utilisez la fonction
wcsncpy(out, data, wcslen(data));
Ensuite, il n'y a pas de trous, mais les lignes copiées ne sont pas droites, il y a des caractères supplémentaires en fin de ligne.
L'ajout dewcslen(data)+1 n'aide pas.

En résumé, de toutes les pages que j'écris ici.
mql string n'accepte pas correctement de la dll, copié pointeur vers string const wchar_t*
Dossiers :
w6b.PNG  74 kb
qjv2.PNG  73 kb
09i3.PNG  6 kb
 
Roman:

Correct, j'alloue un tampon pour la sortie de la chaîne, et je l'initialise avec des espaces.
Puis je passe cette chaîne (pointeur) à la dll.

Dans la dll, les données wchar_t* sont copiées dans out, c'est-à-dire qu'elles sont aussi un pointeur. Logiquement, il ne devrait y avoir aucun problème.
D'après ce que je comprends de l'aide, la fonction StringInit doit définir la longueur de la chaîne.
Mais j'ai encore quelques problèmes avecla fonction StringInit elle-même ; j'ai spécifié la longueur de la chaîne et j'ai eu des problèmes lorsque j'ai indiqué la taille du pointeur.
Je ne comprends pas à quel transfert manuel de longueur de corde vous faites allusion.

Et si vous utilisez sizeof(wchar_t) sans pointeur, la chaîne commence à flotter avec des caractères supplémentaires, ce qui pose des problèmes d'analyse et de fuite.
Pour passer des chaînes de caractères dans une dll, j'ai utilisé l'exemple de Renat, dans son article sur la façon d'écrire une dll.
Mais pour une raison quelconque, si je le passe sans le pointeur sizeof(wchar_t), la chaîne est flottante, alors qu'avec le pointeur sizeof(wchar_t*) il n'y a pas de problème.
Cela me semble logique, je copie une chaîne de caractères comme un pointeur, la taille devrait être passée au pointeur, pas le type.

Parfois, on fait bien les choses et ça ne marche pas.

Je m'y prends mal, mais ça a l'air de marcher.

Dans ce cas, vous devez faire les choses correctement et chercher une erreur ailleurs.

 
Roman:

Ecrit la chaîne de caractères résultante dans le fichier.
Comme la fonction socket renvoie un pointeur vers une chaîne de caractères, un pointeur vers la chaîne de caractères est écrit dans le fichier, puis ce pointeur est copié dans mql.
Utilisation de la fonction

La longueur de la chaîne résultante est de 164, le mql est alloué 200.

La chaîne copiée reçue dans mql est de longueur égale, cependant, il y a quelques lacunes dans la copie.
Dans le script mql, la boucle while est bouclée avec Sleep(1)

1. Dans MQL, une chaîne de caractères, et non un pointeur, est copiée.

2. Vous avez sélectionné une chaîne de 200 caractères dans MQL. Puis tu as copié 164 caractères dedans. Après cela, regardez la taille de la ligne dans MQL. Il est resté à 200.

 
Koldun Zloy:

Parfois, on fait bien les choses et ça ne marche pas.

Je m'y prends mal, mais ça a l'air de marcher.

Dans ce cas, vous devez faire ce qu'il faut et chercher l'erreur ailleurs.

Donc pour bien faire, j'ai abandonné memcpy, et utilisé wcscpy ou wcsncpy.
Résultat, poste ci-dessus.

 
Koldun Zloy:

1. Dans MQL, une chaîne de caractères, et non un pointeur, est copiée.

_DLLAPI void fnReplaceString(wchar_t * text, wchar_t *from, wchar_t * to)
{
   wchar_t * cp;
   
   //проверка параметров
   if(text==NULL || from==NULL || to==NULL) return;
   if(wcslen(from)!=wcslen(to))             return;
 
   //поищем подстроку
   if((cp=wcsstr(text,from))==NULL)         return;

   //заменим
   memcpy(cp,to,wcslen(to)*sizeof(wchar_t));
}
#import "MQL5DLLSamples.dll"
void fnReplaceString(string & text, string from, string to);
#import


Section 3.3

1...257225732574257525762577257825792580258125822583258425852586...3184
Nouveau commentaire