Brunni (./2769) :
Quel que soit le truc que tu cherches à résoudre tu dois savoir que c'est substituable. Par exemple si tu attends un entier comme opérande, tu ne peux pas lire ce qui vient ensuite et t'attendre à trouver un dièse : quel que soit ce que tu vas lire, ça doit passer la "moulinette" et prendre en compte la possibilité d'un commentaire, d'un espace, d'une macro etc.

Je suis bien d'accord sur le principe, ça permet de coder facilement, et même proprement. Mais ça nécessite déjà une abstraction, parce qu'à un moment, t'es bien obligé de lire ton source pour savoir ce qui y est écrit. Faut bien mettre les mains dans le cambouis pour la créer cette abstraction.

Mais en effet, dans le parsing d'une ligne de source (symbole: opcode.taille opérande1,opérande2 ; commentaire), je ne mets que des flags de parseur à jour, et des données qui seront utilisées par, euh, "l'analyseur" (?) qui dira "tel flag indique ue instruction, je lis son opcode ici. Puis telle taille. Telle opérande, sachant qu'il y en a deux, le mode d'adressage de la première opérande se range ici, sa valeur immédiate là, etc...".

C'est pas ce que je pensais faire au début, mais ça tombe sous le sens de s'y prendre comme ça en fait. Ne serait-ce que parce que quand tu lis un bout de code, taille ou opérande, t'es pas encore en possession de toutes les données qui te permettront d'en faire quelque chose d'utile.