si tu arrive avec ton code imbitable généré par lex et que par magie tu arrive à le faire accepter
Je n'arrive pas avec du code imbitable généré par lex. J'arrive avec un fichier lex lisible qui est compilé pendant la phase de compilation.
"Bonjour, j'ai ré-écrit le gros pathé de code imbitable en une série de strcmp(), J'ai économisé 3 Kio de taille de binaire en x86, et en plus j'enlève 50 lignes de code"
Il n'aura rien ré-écrit du tout car ce "pathé de code imbitable" n'est pas écrit. Encore une fois, c'est un fichier lex simple, très lisible (pour peu que l'on conaisse la syntaxe, comme tout format de fichiers) et sincèrement très compliqué à battre, tant en terme de performance que de consomation mémoire (bon, peut-être pas en consomation, mais c'est pas la mort non plus)
Inventer une soupe contextuelle et sortir ton lex/yacc en bloatant ton système de build est juste inacceptable.
Je n'ai rien inventé, les fichiers de configurations sont déjà là avec leur format, et quand j'ai à analyser cela, je crée un analiser lexical avec lex que je couble avec un petit switch. Tu as remarqué que dans mon post original, je prenais soin de mentionner que je ne couplais en aucun cas ça avec du yacc/bison.
Encore une fois, si j'ai 3 mots clés que je lis 2 fois chacuns, je ne le fais pas. Quand cela commence à gonfler, c'est le tas de if/else avec des comparaisons de chaines qui deviens du bloat.
Le plus simple restant encore de ne pas écrire de grammaire soi-même et d'utiliser des parseurs que d'autres ont écrits.
Une fois encore, je n'écris pas de grammaire !! juste un automate à état finis généré par lex que je couple avec un switch en C
Après si c'est lex qui te donne des boutons, tu n'as qu'à l'écrire à la main ton automate, mais tu seras moins bon que lui et quand ce que tu auras à parser change, il faudra le réécrire, c'est pas terrible.
[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
Posté par moi1392 . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... Évalué à 1. Dernière modification le 05 avril 2014 à 12:21.
Je n'arrive pas avec du code imbitable généré par lex. J'arrive avec un fichier lex lisible qui est compilé pendant la phase de compilation.
"Bonjour, j'ai ré-écrit le gros pathé de code imbitable en une série de strcmp(), J'ai économisé 3 Kio de taille de binaire en x86, et en plus j'enlève 50 lignes de code"
Il n'aura rien ré-écrit du tout car ce "pathé de code imbitable" n'est pas écrit. Encore une fois, c'est un fichier lex simple, très lisible (pour peu que l'on conaisse la syntaxe, comme tout format de fichiers) et sincèrement très compliqué à battre, tant en terme de performance que de consomation mémoire (bon, peut-être pas en consomation, mais c'est pas la mort non plus)
Je n'ai rien inventé, les fichiers de configurations sont déjà là avec leur format, et quand j'ai à analyser cela, je crée un analiser lexical avec lex que je couble avec un petit switch. Tu as remarqué que dans mon post original, je prenais soin de mentionner que je ne couplais en aucun cas ça avec du yacc/bison.
Encore une fois, si j'ai 3 mots clés que je lis 2 fois chacuns, je ne le fais pas. Quand cela commence à gonfler, c'est le tas de if/else avec des comparaisons de chaines qui deviens du bloat.
Une fois encore, je n'écris pas de grammaire !! juste un automate à état finis généré par lex que je couple avec un switch en C
Après si c'est lex qui te donne des boutons, tu n'as qu'à l'écrire à la main ton automate, mais tu seras moins bon que lui et quand ce que tu auras à parser change, il faudra le réécrire, c'est pas terrible.