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.
Il va aussi falloir que tu touche au système de build. Et si il y a bien un truc chiant, c'est bien les systèmes de build. Va falloir gérer correctement la cross-compilation (surtout pour un noyau) permettre de configurer le chemin vers lex/yacc, documenter tout ça ... Au final, ça fait bien plus de travail et plus de lignes ajoutées par rapport à une boucle while avec des strcmp().
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)
Le code généré par Lex sera gros, imbitable, chiant à déboguer (va comprendre le code assembleur généré) et générera des exécutables plus gros. Dans le cas d'un noyau, c'est ce qui compte, plus que les performances. Personne n'appellera ce code des milliers de fois par seconde, et même si c'était le cas, alors il serait simplement interdit de parser une chaîne dans ce code, et il aurai faudrai faire autrement pour passer des paramètres (netlink !!! ;) ). En plus des développeurs parlaient de le récrire.
Je n'ai rien inventé, les fichiers de configurations sont déjà là avec leur format
Donc tout ce que tu dit est totalement hors sujet. Si tu n'a pas le choix du langage que tu parse et que ton langage est complexe, j'ai aucune objection. Sauf qu'ici c'est celui qui à écrit le code qui à choisi la syntaxe de ses paramètres, et il à justement choisi des mots séparés par des virgules pour qu'il puisse faire son parseur simplement avec strtok et strcmp.
Et si tu à le choix du langage que tu parse et que tu sort autre chose que ça, c'est que tu adore te complexifier la vie pour rien.
[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
Posté par Batchyx . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... Évalué à 3.
Il va aussi falloir que tu touche au système de build. Et si il y a bien un truc chiant, c'est bien les systèmes de build. Va falloir gérer correctement la cross-compilation (surtout pour un noyau) permettre de configurer le chemin vers lex/yacc, documenter tout ça ... Au final, ça fait bien plus de travail et plus de lignes ajoutées par rapport à une boucle while avec des strcmp().
Le code généré par Lex sera gros, imbitable, chiant à déboguer (va comprendre le code assembleur généré) et générera des exécutables plus gros. Dans le cas d'un noyau, c'est ce qui compte, plus que les performances. Personne n'appellera ce code des milliers de fois par seconde, et même si c'était le cas, alors il serait simplement interdit de parser une chaîne dans ce code, et il aurai faudrai faire autrement pour passer des paramètres (netlink !!! ;) ). En plus des développeurs parlaient de le récrire.
Donc tout ce que tu dit est totalement hors sujet. Si tu n'a pas le choix du langage que tu parse et que ton langage est complexe, j'ai aucune objection. Sauf qu'ici c'est celui qui à écrit le code qui à choisi la syntaxe de ses paramètres, et il à justement choisi des mots séparés par des virgules pour qu'il puisse faire son parseur simplement avec strtok et strcmp.
Et si tu à le choix du langage que tu parse et que tu sort autre chose que ça, c'est que tu adore te complexifier la vie pour rien.