Mon approche. Le noyau est le moteur. - page 83
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
Le moteur et le conseiller travaillent dans un flux de communication. Chaque cellule du tableau correspond à un nombre de simovalves. En plus de cela, il y a beaucoup d'autres éléments qui transmettent leurs valeurs, leurs états, et ainsi de suite. Vous devez échanger les rangs rapidement et ne pas surcharger la file d'attente des événements OnChartEvent().
Prenez SQL et ne vous creusez pas la tête :-)
Vous voulez dire que vous n'avez aucune idée de la manière de le faire avec les ressources et le syndicat ?
Après toi, Nikolaï.
Vous avez proposé l'option avec le syndicat, mais vous ne m'avez pas montré d'exemple. Puis vous êtes passé àCharArrayToString etStringToCharArray. Maintenant, vous parlez à nouveau d'un syndicat.
Alors, est-ce que la meilleure façon de résoudre le problème est de passer d'une chaîne de caractères à une chaîne de caractères et vice-versa, avec une division ultérieure des chaînes de caractères (les chaînes de caractères contiennent un ensemble de numéros de paramètres et leurs valeurs) ?
Après toi, Nikolaï.
Dites-moi, Peter, utilisez-vous aussi des chaînes pour passer des doubles, des longs et des int ?
Le cœur des paramètres est un tableau unique. Et il est de type string. Pour une raison : c'est un type universel. C'est très pratique. Vous pouvez écrire n'importe quelle valeur et la convertir ensuite dans le type requis.
Sinon, il serait nécessaire de créer de nombreux noyaux de paramètres. Chacun pour son propre type de valeur. En conséquence, nous aurions un fouillis d'attributs de paramètres, leur indexation, l'emplacement d'écriture et bien d'autres choses.
Ne soyons pas des trolls. Le mentorat n'est pas approprié. Je comprends mieux ce travail.
Nikolaï, je t'ai dit que j'allais essayer ta version). Alors je le ferai.
prenez SQL et ne vous inquiétez pas :-)
Comme pour faire suite à la phrase "ne pas se prendre la tête" :-)
Je suis gentil et pas du tout méchant aujourd'hui...
Peter, à propos de la "programmation visuelle" (pas seulement l'interface graphique), pour le développement, afin de ne pas avoir à construire un tableau sur un tableau,
Jetez un coup d'œil à Oracle, par exemple. L'un des leaders incontestés
Visual editor gratuit (avec la machine virtuelle) c'est ici ; https://apex.oracle.com/en/
Tout ce dont vous avez besoin pour commencer est un livre de "Les débuts de SQL pour les nuls" et quelques jours de temps libre.
Ne soyons pas des trolls. Le ton de mentorat est inapproprié. Je comprends mieux ce travail.
Je n'essaie pas de vous en dissuader.
Pourquoi devrais-je faire ce travail ingrat.Je n'ai pas eu ce ton. C'est juste que j'ai posté plusieurs fois du code pour vous qui était beaucoup plus rapide que le vôtre, dans l'espoir que vous l'appreniez et appliquiez des méthodes plus rapides, mais vous n'en avez jamais profité.
Le cœur des paramètres est un tableau unique. Et il est de type string. Pour une raison : c'est un type universel. C'est très pratique. Vous pouvez écrire n'importe quelle valeur et la convertir ensuite dans le type requis.
Sinon, il serait nécessaire de créer de nombreux noyaux de paramètres. Chacun pour son propre type de valeur. Il en résulterait un désordre au niveau de la propriété des paramètres, de l'indexation, de l'emplacement de l'écriture et de bien d'autres choses.
La polyvalence est souvent synonyme de lenteur, et encore plus avec les cordes.
Voici un exemple.
Une fois, j'ai analysé une chaîne obtenue d'une bourse de crypto-monnaies en utilisant WebRequest. Et je l'ai analysé en utilisant labibliothèque JSON portée parSergeyev depuis "high speed C++ library". Et j'ai remarqué que la vitesse est très insatisfaisante. Là-bas, tout se faisait par le biais de cordes "universelles".
J'ai compris que la raison de la faible vitesse était le stringing et j'ai voulu éviter d'utiliser des fonctions string et j'ai écrit une fonction qui analyse directement le tableau uchar. Le résultat m'a beaucoup surpris. Ma vitesse d'analyse était de.... (roulement de tambour) 800 fois plus rapide. Si l'analyse d'une chaîne entière dans JSON prenait 0,3 seconde, ma fonction l'a analysée en moins d'une demi-milliseconde.
Voici un exemple de mon analyse syntaxique via un tableau uchar.
La polyvalence est souvent synonyme de lenteur, et avec les cordes encore plus.
Voici un exemple.
Une fois, j'ai analysé une chaîne reçue d'une bourse de cryptage en utilisant WebRequest. Et je l'analysais avecla bibliothèque JSON de Sergeev, qu'il a portée depuis une "bibliothèque C++ à haut débit". Et j'ai remarqué que la vitesse est très insatisfaisante. Là-bas, tout était mis en œuvre via des chaînes "universelles".
Je voulais m'éloigner des chaînes de caractères et j'ai écrit une fonction qui analyse directement le tableau uchar. Le résultat a été surprenant. Ma vitesse d'analyse est de.... (roulement de tambour) 800 fois plus rapide.
Voici un exemple d'analyse d'un tableau d'uchar.
L'analyse syntaxique de json (et l'analyse syntaxique en général) est une autre histoire ;-)
J'ai eu des problèmes dans une très grande application de script monofilaire travaillant avec la cryptographie.
Les soupçons se sont portés sur l'endroit et la manière dont tout a été optimisé. Le problème semble provenir de l'analyseur de données json d'une tierce partie :-)
C'est parce que les bibliothèques "universelles" sont conçues pour être polyvalentes et travailler avec le json le plus délicat, mais dans notre domaine, il n'y en a tout simplement pas,
et tous les colis sont très courts.
Et oui, l'analyse du texte dans MQL est un vrai plaisir :-). Eh bien, il n'est pas conçu pour l'analyse de texte. Je veux dire, vous pouvez, mais c'est une douleur dans le cul.
Tableaux, commandes - c'est le domaine de MQL.