Et donc tu utilises 2 outils et 2 langages pour faire quelques choses de très proche, avec tous les problèmes imaginables à l'interface.
oui.
C'est pas comme si on ne faisait pas déjà ça depuis toujours. flex, bison, moc en sont des exemple parmi d'autres !
J'ai déjà donné des exemples : inclure un binaire sans outils externe, pas de générateur de code externe, mais un générateur en library.
Mais ça, ça n'est pas un problème que tu as, mais une solution que tu proposes.
Et puis, c'est même pire que ça. Je parle de lire un fichier pour générer des API, et tu me parles "générateur de code"
C'est quoi la différence ? une API c'est du code. il existe déjà des tas d'outils qui transforment des graphes uml en code (api seulement)
tu imagines la différence de difficulté entre une bonne propagation de constante et un compilateur ?
Je pense oui, mais ça ne me dit toujours pas pourquoi tu as besoin de ces choses de façon constante dans ton language !
c++ fait des algos, et il le fait très bien, il sait déjà gérer une certaine forme de propagation de constantes, il en gère un peu plus maintenant, si tu veux un meta langage qui fasse autre chose, utilise un autre langage et voila !
[^] # Re: Plutôt beauté du design
Posté par moi1392 . En réponse au journal "beauté du code". Évalué à 2.
oui.
C'est pas comme si on ne faisait pas déjà ça depuis toujours. flex, bison, moc en sont des exemple parmi d'autres !
Mais ça, ça n'est pas un problème que tu as, mais une solution que tu proposes.
C'est quoi la différence ? une API c'est du code. il existe déjà des tas d'outils qui transforment des graphes uml en code (api seulement)
Je pense oui, mais ça ne me dit toujours pas pourquoi tu as besoin de ces choses de façon constante dans ton language !
c++ fait des algos, et il le fait très bien, il sait déjà gérer une certaine forme de propagation de constantes, il en gère un peu plus maintenant, si tu veux un meta langage qui fasse autre chose, utilise un autre langage et voila !