Erreurs, bugs, questions - page 2709
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
Pourquoi en MQL vous ne pouvez pas appeler un constructeur protégé depuis votre méthode d'usine ?
Je n'ai pas deviné où cela pourrait être utile.
Je n'ai pas deviné où cela pourrait être utile.
Mise en œuvre classique du modèle Singleton.
Une implémentation classique du modèle Singleton.
Vous ne pouvez donc pas créer plus d'un certain nombre d'objets d'une classe donnée ?
De sorte que l'on ne puisse créer plus d'un certain nombre d'objets d'une classe donnée ?
Oui, pour qu'il y ait un seul point d'accès de toutes les parties du programme à une instance de la classe à état modifiable.
Voici un site sympa que j'ai trouvé aujourd'hui sur les motifs en images et en pseudocode: https://refactoring.guru/ru/design-patterns/singleton.
Oui, pour avoir un point d'accès unique de toutes les parties du programme à une instance de classe changeant d'état.
Voici un site sympa que j'ai trouvé aujourd'hui sur les motifs en images et en pseudocode: https://refactoring.guru/ru/design-patterns/singleton.
Je l'ai, merci. J'ai déjà utilisé une telle construction.
Le problème se situe au niveau de la valeur par défaut, si vous la supprimez, tout fonctionne comme il se doit :
Mais en C++, cela fonctionne aussi avec la valeur par défaut. Comment cela l'affecte-t-il ?
Quelqu'un a-t-il réussi à faire fonctionner CryptEncode(CRYPT_ARCH_ZIP, data[], key[] = {1,0,0,0}, result[]) basé sur MQL avec une compression deflate à partir d'un websocket ? Le serveur d'écho public (echo.websocket.org) ne semble pas supporter cette extension, je n'ai pas trouvé d'autre serveur d'écho et le node.js local donne l'erreur "zlib invalid distance too far back" en essayant de décrypter des données compressées. J'ai défini server_max_window_bits=15 ; client_max_window_bits=15 dans l'en-tête, mais cela ne semble pas être le cas car le serveur confirme ces paramètres. Du côté de MQL, je ne peux rien définir sauf la clé {1,0,0,0} ;-(.
Quelqu'un a-t-il réussi à faire fonctionner CryptEncode(CRYPT_ARCH_ZIP, data[], key[] = {1,0,0,0}, result[]) basé sur MQL avec une compression deflate à partir d'un websocket ? Le serveur d'écho public (echo.websocket.org) ne semble pas supporter cette extension, je n'ai pas trouvé d'autre serveur d'écho et le node.js local donne l'erreur "zlib invalid distance too far back" en essayant de décrypter des données compressées. J'ai défini server_max_window_bits=15 ; client_max_window_bits=15 dans l'en-tête, mais cela ne semble pas être le cas car le serveur confirme ces paramètres. Du côté de MQL, je ne peux rien définir sauf la clé {1,0,0,0} ;-(.
Si j'ai bien compris votre question, la compression GZIP est principalement utilisée dans les websockets pour le conditionnement des données.
La constante CRYPT_ARCH_ZIP est probablement liée à un ZIP normal.
Si vous savez comment emballer/déballer GZIP en utilisant mql5, je suis également intéressé.
Si je comprends bien la question, les websockets utilisent principalement la compression GZIP pour emballer les données.
La constante CRYPT_ARCH_ZIP est probablement liée à un ZIP normal.
Si vous savez comment emballer/déballer GZIP, en utilisant les outils mql5, je suis également intéressé.
Pour autant que je sache, le commutateur {1,0,0,0} supprime tous les emballages et ne laisse que des paquets compressés. Au moins le mot "Hello" apparaît sous forme compressée de la même manière dans la sortie CryptEncode et dans la sortie deflate. En conséquence, cela devrait également fonctionner dans l'autre sens. Cependant, MQL ne donne pas plus de paramètres et ne montre pas les paramètres "par défaut" de deflate qu'il utilise. Il est évident qu'ils sont différents, mais seuls max_window_bits et no_context_takeover peuvent être contrôlés dans le websocket - d'abord ils sont clairement inférieurs à ceux de l'algorithme deflate (qui est configuré sur le serveur), ensuite même ils ne peuvent pas être configurés dans CryptEncode/Decode.
Pour autant que je sache, la touche {1,0,0,0} supprime tous les encadrements et ne laisse que le paquet compressé. Au moins le mot "Hello" apparaît sous forme compressée de la même manière dans la sortie de CryptEncode et que deflate. En conséquence, cela devrait également fonctionner dans l'autre sens. Cependant, MQL ne donne pas plus de paramètres et ne montre pas les paramètres "par défaut" de deflate qu'il utilise. Il est évident qu'ils sont différents, mais seuls max_window_bits et no_context_takeover peuvent être contrôlés dans le websocket - d'abord ils sont clairement inférieurs à ceux de l'algorithme deflate (qui est configuré sur le serveur), ensuite même ils ne peuvent pas être configurés dans CryptEncode/Decode.
Ah, voilà, je n'ai pas creusé aussi profond, et je pensais que le paramètre clé était seulement pour les algorithmes de cryptage.
Mais je n'ai jamais pensé que la clé pouvait être appliquée à la méthode d'emballage, il doit s'agir d'un truc de bas niveau, nécessitant des connaissances approfondies.
Il est logique que les développeurs ajoutent une constante standard pour travailler avec gzip.