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
Analyse statique du code... L'exécution n'est pas nécessaire.
Je pensais à une autre option - l'analyse syntaxique du texte. En d'autres termes, l'analyse syntaxique de MQL et la création d'une structure de programme.
Mais je ne sais même pas par où commencer.
Pourquoi pas, si vous le souhaitez.
N'est-il pas évident que ce problème est insoluble ? De cette façon, nous pourrions éliminer les paires de crochets arithmétiques () [] et d'opérateurs {}, et les remplacer par un seul crochet ouvrant. C'est trop faible ?
;)
Pourquoi ?
Après tout, il existe aussi de nombreuses opérations unaires.
Le choix d'un mauvais moyen de mise en œuvre dénote un manque de professionnalisme.
Quelle différence cela fait-il de savoir en quoi vous programmez ? Ce qui compte dans toute entreprise, c'est la matrice de solutions.
Tout le reste n'est pas pertinent.
Analyse statique du code... L'exécution n'est pas nécessaire.
Le code est décomposé en fonctions (blocs), puis on analyse qui appelle qui.
J'ai la même idée en tête. Seulement, il faudrait décortiquer tout le programme pour séparer les montagnes des boutons...
Et il semble que le personnage principal n'en ait pas besoin, si je devine bien, il a besoin d'imprimer les appels sur le fait. Eh bien, comme si les conditions de l'appel avaient lieu.
Je pensais à une autre option - l'analyse du texte. En d'autres termes, l'analyse de MQL et la création d'une structure de programme.
Mais je ne sais même pas par où commencer pour sa mise en œuvre.
Qu'est-ce qu'une fonction ?
.
[ mot espace / il se peut que ce ne soit pas ] mot fonction nom parenthèse "(", quelque chose là, parenthèse fermant ")".
curly openers {
.
un peu de code
accolades {, }
.
fermeture en boucle }
.
La première partie du travail est faite.
:))
La tâche (si vous avez lu le premier article) est d'ajouter une seule fonction de service à chaque fonction du code source - juste après "{".
Mais de manière à obtenir tous les passages du code source et à construire un arbre d'appel.
Dans ce cas, ni les paramètres d'entrée des fonctions sources, ni leurs résultats ou leur code interne ne sont modifiés de quelque manière que ce soit.
Il ne s'agit pas de trace pure. Il s'agit juste de construire le graphique d'une fonction.
Voici un extrait du journal :
Pourquoi ?
Après tout, il n'y a pas que des opérations unaires.
Eh bien, cette opération n'est clairement pas unaire. L'"état d'emboîtement" dans l'analyse statique du texte est unaire. Dans le traçage dynamique, il est binaire. Il y a une entrée (INPUT) et une sortie (OUTPUT).
N'est-ce pas ?
J'ai la même idée en tête. Seulement, il faudrait décortiquer l'ensemble du programme pour séparer les montagnes des boutons...
Et il me semble que ce n'est pas ce dont le starter a besoin, si j'ai bien compris, il a besoin d'imprimer les appels sur le fait. Vous savez, si les conditions de l'appel sont remplies.
Lors de l'analyse syntaxique, les appels réels seront détectés par eux-mêmes. Qui est avec qui et d'où...
C'est donc la seule idée de solution complète jusqu'à présent.
.
D'ailleurs... Je vais ajouter :
.
- Le texte du programme est d'abord analysé par un "lexer".
Le lexeur bat le texte du programme en "tokens".
Dans notre cas, les jetons sont :
.
- les espaces blancs - espaces, tabulations, fins de ligne, etc. -
Comme nous n'écrivons pas le formateur, nous ignorons ces éléments.
- parenthèses ( / )
- parenthèses [ / ]
- parenthèses { / }
- opérateurs + - / *
- caractères de remplacement ;,
tous les autres sont essentiellement des identifiants
(les chiffres feront également partie de ce groupe - mais cela nous importe peu).
.
Lors de l'analyse lexicale, les structures du type
struct { typeToken, stringToken }
.
Pour le parsing, j'ai utilisé une pièce jointe de type
struct Tocken { typeToken, stringToken, list<Token> liste de tokens imbriqués }
Mais vous pouvez penser à un moyen plus simple ici.
.
Et ensuite faire le regroupement que j'ai mentionné ci-dessus - trivial.
.
En fait, la combinaison lexer + analyseur syntaxique est un classique du genre.
A propos de lex/flex/bison/ant-lr ne peut pas conseiller (je ne connais même pas le nom ;-D)-.
J'ai écrit exactement fait à la main.
OK. Merci à tous pour le débat.